ci: bump the actions group across 1 directory with 13 updates

[dependabot]

Bumps the actions group with 13 updates in the / directory:

Package	From	To
vmactions/freebsd-vm	1.5.3	1.5.5
vmactions/openbsd-vm	1.4.5	1.4.7
vmactions/netbsd-vm	1.4.6	1.4.9
vmactions/dragonflybsd-vm	1.3.1	1.3.3
vmactions/haiku-vm	1.1.3	1.1.5
vmactions/hurd-vm	1.0.0	1.0.1
vmactions/solaris-vm	1.3.8	1.3.9
vmactions/omnios-vm	1.3.4	1.3.6
vmactions/openindiana-vm	1.1.5	1.1.6
vmactions/tribblix-vm	1.0.3	1.0.5
vmactions/ghostbsd-vm	1.0.2	1.0.3
vmactions/openeuler-vm	1.0.0	1.0.2
vmactions/blissos-vm	1.0.1	1.0.2

Updates vmactions/freebsd-vm from 1.5.3 to 1.5.5

Release notes

Sourced from vmactions/freebsd-vm's releases.

v1.5.5

The runtime moves to anyvm v0.6.5 (from v0.6.4), keeping the whole fleet on one version. This action's surface is unchanged -- same images, same sync methods, same defaults. The bump carries one runtime change of note: on hosts whose nested AMD virtualization corrupts AVX512 XSAVE state, the CPU-feature mask now drops the whole AVX512 family instead of only avx512f.

Full Changelog: vmactions/freebsd-vm@v1.5.4...v1.5.5

v1.5.4

sync: tar

A fourth way to share the workspace, available on every architecture including riscv64 and powerpc64, where rsync and sshfs do not exist:

The workspace is streamed in as a ustar archive over the ssh connection the action already opens, and streamed back the same way when the run finishes. Nothing is installed in the guest and no filesystem support is needed on either side, unlike sshfs and nfs. Verified before shipping: 300 files plus a 1 MB binary blob pushed into a 15.1 guest, a file written inside it, the whole tree pulled back and compared by content hash.

rsync remains the default. Reach for tar when the guest lacks rsync, or when a mount-based method is more machinery than the job needs.

Under the hood

The image builder moves to freebsd-builder v2.2.6 and the runtime to anyvm v0.6.4, nine releases on from what v1.5.3 shipped. Most of that is other guests, but two fixes reach every action:

A failed folder sync used to be a warning. The run continued with the guest missing the files it was about to use, which surfaced much later as a confusing error or a job that sat until its timeout. It is now fatal, and says so.

The workspace push no longer carries the runner's own harness directories into the guest.

Also

The shell note no longer mentions usesh, which has not been needed for some time.

Full Changelog: vmactions/freebsd-vm@v1.5.3...v1.5.4

Commits

• f0552d3 Update vmactions/freebsd-vm from base-vm
• 5595fc6 Generated from base-vm
• 0206b2a Sync from base-builder
• 2ed1747 Update vmactions/freebsd-vm from base-vm
• be1c6e8 Generated from base-vm
• bddcfce Update vmactions/freebsd-vm from base-vm
• 139a2cb Generated from base-vm
• 0a1a391 Update version to v1.5.4
• 759dd0c Update vmactions/freebsd-vm from base-vm
• b5370dd Generated from base-vm
• Additional commits viewable in compare view

Updates vmactions/openbsd-vm from 1.4.5 to 1.4.7

Release notes

Sourced from vmactions/openbsd-vm's releases.

v1.4.7

sync: tar

A new way to share the workspace, available on every architecture: the tree is streamed in as a ustar archive over the ssh connection the action already opens, and streamed back the same way when the run finishes. Nothing is installed in the guest and no filesystem support is needed on either side, unlike sshfs and nfs. openbsd-builder v2.1.0 declares it for every release, and it was verified on this guest before the declaration went in: 300 files plus a 1 MB binary blob pushed, a file written inside the VM, the whole tree pulled back and compared by content hash.

rsync remains the default.

Under the hood

openbsd-builder v2.1.0 is also the first openbsd build to publish releases.json, the machine-readable index this action bakes its configuration from -- which is why the pre-tar method list survived until now.

The runtime moves to anyvm v0.6.5, ten releases on from the v0.5.5 that v1.4.6 shipped. Two of its fixes reach every job: a failed folder sync is now fatal instead of a warning that left the guest running without the files it was about to use, and the workspace push no longer carries the runner's own harness directories into the guest.

Full Changelog: vmactions/openbsd-vm@v1.4.6...v1.4.7

v1.4.6

support major release.

Full Changelog: vmactions/openbsd-vm@v1.4.5...v1.4.6

Commits

• 86cdc08 Update vmactions/openbsd-vm from base-vm
• 4d73785 Generated from base-vm
• e327e92 Sync from base-builder
• 533018c Update vmactions/openbsd-vm from base-vm
• 222bcdb Generated from base-vm
• 73697f6 Update vmactions/openbsd-vm from base-vm
• e334303 Generated from base-vm
• a824726 Update version to v1.4.6
• 8ddee6b Update vmactions/openbsd-vm from base-vm
• 3c73357 Generated from base-vm
• Additional commits viewable in compare view

Updates vmactions/netbsd-vm from 1.4.6 to 1.4.9

Release notes

Sourced from vmactions/netbsd-vm's releases.

v1.4.9

support "11.0-microvm", which boots in 7 seconds. fix pkgsrc.

Full Changelog: vmactions/netbsd-vm@v1.4.8...v1.4.9

v1.4.8

Package mirrors: probe first, then trust

On 2026-08-30 the NetBSD.org package hosts went down together -- cdn.NetBSD.org and ftp.NetBSD.org are the same infrastructure behind a CDN, not independent mirrors -- and every pkg_add in every job spent minutes per package in TLS timeouts before dying.

The VM now probes the package mirrors at startup and points pkg_add at the ones that actually answer: cdn.NetBSD.org, ftp.NetBSD.org, the official French mirror ftp.fr.NetBSD.org, ftp.jaist.ac.jp and ftp.allbsd.org, in that order, keeping only the live ones. Dead hosts are dropped entirely rather than kept as fallbacks, because pkg_add walks the whole list for every package it installs, and each dead https entry costs minutes per package. If nothing answers, the configuration is left untouched.

This also retires a long-standing trap in the image's default configuration: its PKG_PATH ended with a NetBSD 9.0 fallback, so a package missing from the preferred hosts was silently installed from the 9.0 set, linked against libraries the running release does not ship. All entries are now same-release only.

The probe runs on every VM start, including boots from a cache-after-prepare image, so the mirror list is always from the current run, never frozen into a cache. Verified during the outage itself: with both NetBSD.org hosts dead, prepare installed its packages from the French mirror on the first try.

Under the hood

The runtime moves to anyvm v0.6.6. Changes under hooks/ now retrigger the project generation, so a hook fix is picked up by the test matrix without waiting for the daily rebuild.

Full Changelog: vmactions/netbsd-vm@v1.4.7...v1.4.8

v1.4.7

sync: tar

A new way to share the workspace: the tree is streamed in as a ustar archive over the ssh connection the action already opens, and streamed back the same way when the run finishes. Nothing is installed in the guest and no filesystem support is needed on either side, unlike sshfs

... (truncated)

Commits

• 7f23a49 Update vmactions/netbsd-vm from base-vm
• 9739cfd Generated from base-vm
• dab02a1 fix pkgsrc
• ddaf0eb Update vmactions/netbsd-vm from base-vm
• 2875417 Generated from base-vm
• 191d005 Sync from base-builder
• 5499895 Update vmactions/netbsd-vm from base-vm
• fd079b8 Generated from base-vm
• f79ac1d Update version to v1.4.8
• b017ed6 Update vmactions/netbsd-vm from base-vm
• Additional commits viewable in compare view

Updates vmactions/dragonflybsd-vm from 1.3.1 to 1.3.3

Release notes

Sourced from vmactions/dragonflybsd-vm's releases.

v1.3.3

sync: tar

A new way to share the workspace: the tree is streamed in as a ustar archive over the ssh connection the action already opens, and streamed back the same way when the run finishes. Nothing is installed in the guest and no filesystem support is needed on either side, unlike sshfs and nfs. dragonflybsd-builder v2.0.7 declares it for every release, and it was verified on this guest before the declaration went in: 300 files plus a 1 MB binary blob pushed, a file written inside the VM, the whole tree pulled back and compared by content hash.

rsync remains the default.

Under the hood

The runtime moves to anyvm v0.6.5 (from v0.6.3), the version the rest of the fleet pins. Of its changes, the one that can reach a VM job here: on hosts whose nested AMD virtualization corrupts AVX512 XSAVE state, the CPU-feature mask now drops the whole AVX512 family instead of only avx512f.

Full Changelog: vmactions/dragonflybsd-vm@v1.3.2...v1.3.3

v1.3.2

support major version

Full Changelog: vmactions/dragonflybsd-vm@v1.3.1...v1.3.2

Commits

• 7cd7c9b Update vmactions/dragonflybsd-vm from base-vm
• 55b702a Generated from base-vm
• 09ebd7a Sync from base-builder
• 5651db6 Update vmactions/dragonflybsd-vm from base-vm
• 1b52adb Generated from base-vm
• c65ec32 Update vmactions/dragonflybsd-vm from base-vm
• c03b1e5 Generated from base-vm
• 988300e Update version to v1.3.2
• 2437328 Update vmactions/dragonflybsd-vm from base-vm
• 503fc4a Generated from base-vm
• Additional commits viewable in compare view

Updates vmactions/haiku-vm from 1.1.3 to 1.1.5

Release notes

Sourced from vmactions/haiku-vm's releases.

v1.1.5

Haiku R1/beta6, and three more sync methods

The default guest release is now R1/beta6. A workflow that does not set a release input gets it from this version on.

Folder sync grows from two backends to five

R1/beta6 offers rsync, scp, nfs, sshfs and tar. Before this, only
rsync and scp were available. Choose one with
sync: "nfs"

All five pass in this action's own CI against a beta6 guest, along

with the cache-after-prepare and custom-shell paths.

Why beta6 matters beyond the version number

On R1/beta5, installing packages from inside the VM had stopped
working. Upstream retired the HaikuPorts branch repository for
that release -- its package index answers with an empty 2-byte
file -- so pkgman had nothing to resolve against. The beta5 image
kept working only because the builder baked its packages in from a
pinned snapshot, and that covered just what the builder installed,
not what a workflow asks for.
On R1/beta6 the repository is live again, a 2.4 MB index, and the

image is built the ordinary way with no pinned packages anywhere.

A prepare step can run pkgman install again.

R1/beta5 is still selectable

    release: "r1beta5"
It is unchanged -- rsync and scp only, from haiku-builder v2.0.2 --

and it is no longer part of this action's test matrix.

Under the hood

The beta6 image comes from haiku-builder v2.0.3, and the runtime
moves to anyvm v0.6.6.

Full Changelog: vmactions/haiku-vm@v1.1.4...v1.1.5

v1.1.4

Under the hood

The runtime moves to anyvm v0.6.5, fifteen releases on from the v0.5.0 that v1.1.3 shipped -- most of that span is other guests' work. What reaches this action: a failed folder sync is now fatal instead of a

... (truncated)

Commits

• 6a07e02 Update vmactions/haiku-vm from base-vm
• ec62478 Generated from base-vm
• fd350c6 Bump versions from upstream releases
• bea6723 Update vmactions/haiku-vm from base-vm
• f7ad86f Generated from base-vm
• 18f07f6 remove r1beta5
• 3c8964f Update version to v1.1.4
• f67acb5 Update vmactions/haiku-vm from base-vm
• 9d2267c Generated from base-vm
• cda4b76 r1beta6
• Additional commits viewable in compare view

Updates vmactions/hurd-vm from 1.0.0 to 1.0.1

Release notes

Sourced from vmactions/hurd-vm's releases.

v1.0.1

sync: tar

A new way to share the workspace: the tree is streamed in as a ustar archive over the ssh connection the action already opens, and streamed back the same way when the run finishes. Nothing is installed in the guest and no filesystem support is needed on either side, unlike nfs. hurd-builder v2.0.1 declares it for every release, and it was verified on this guest before the declaration went in: 300 files plus a 1 MB binary blob pushed, a file written inside the VM, the whole tree pulled back and compared by content hash.

rsync remains the default.

Under the hood

hurd-builder v2.0.1 is also the first hurd build to publish releases.json, the machine-readable index this action bakes its configuration from -- which is why the pre-tar method list survived until now.

The runtime moves to anyvm v0.6.5, thirteen releases on from the v0.5.2 that v1.0.0 shipped. Two of its fixes reach every job: a failed folder sync is now fatal instead of a warning that left the guest running without the files it was about to use, and the workspace push no longer carries the runner's own harness directories into the guest.

Full Changelog: vmactions/hurd-vm@v1.0.0...v1.0.1

Commits

• a116077 Update vmactions/hurd-vm from base-vm
• 6fc5681 Generated from base-vm
• 19f0506 Sync from base-builder
• 7eddd0a Update vmactions/hurd-vm from base-vm
• ce77be3 Generated from base-vm
• 4a64d1d Update vmactions/hurd-vm from base-vm
• e4a9fd0 Generated from base-vm
• ed0e2c0 Update version to v1.0.0
• 646a69e Update vmactions/hurd-vm from base-vm
• fc0a6e0 Generated from base-vm
• Additional commits viewable in compare view

Updates vmactions/solaris-vm from 1.3.8 to 1.3.9

Release notes

Sourced from vmactions/solaris-vm's releases.

v1.3.9

sync: tar

A new way to share the workspace: the tree is streamed in as a ustar archive over the ssh connection the action already opens, and streamed back the same way when the run finishes. Nothing is installed in the guest and no filesystem support is needed on either side, unlike nfs. solaris-builder v2.0.7 declares it for every release, and it was verified on this guest before the declaration went in: 300 files plus a 1 MB binary blob pushed, a file written inside the VM, the whole tree pulled back and compared by content hash.

rsync remains the default.

Under the hood

solaris-builder v2.0.7 is also the first solaris build to publish releases.json, the machine-readable index this action bakes its configuration from -- which is why the pre-tar method list survived until now.

The runtime moves to anyvm v0.6.5, fifteen releases on from the v0.5.0 that v1.3.8 shipped. Two of its fixes reach every job: a failed folder sync is now fatal instead of a warning that left the guest running without the files it was about to use, and the workspace push no longer carries the runner's own harness directories into the guest.

Full Changelog: vmactions/solaris-vm@v1.3.8...v1.3.9

Commits

• 96d8d97 Update vmactions/solaris-vm from base-vm
• f13d129 Generated from base-vm
• f841832 Sync from base-builder
• cb8e2d9 Update vmactions/solaris-vm from base-vm
• 2627719 Generated from base-vm
• 31fc30b Update vmactions/solaris-vm from base-vm
• 8a05dca Generated from base-vm
• a5f8cf8 Update version to v1.3.8
• d45c57a Update vmactions/solaris-vm from base-vm
• a0ddca6 Generated from base-vm
• Additional commits viewable in compare view

Updates vmactions/omnios-vm from 1.3.4 to 1.3.6

Release notes

Sourced from vmactions/omnios-vm's releases.

v1.3.6

The runtime moves to anyvm v0.6.5 (from v0.6.4), keeping the whole fleet on one version. This action's surface is unchanged -- same images, same sync methods, same defaults. The bump carries one runtime change of note: on hosts whose nested AMD virtualization corrupts AVX512 XSAVE state, the CPU-feature mask now drops the whole AVX512 family instead of only avx512f.

Full Changelog: vmactions/omnios-vm@v1.3.5...v1.3.6

v1.3.5

support tar.

Full Changelog: vmactions/omnios-vm@v1.3.4...v1.3.5

Commits

• 317e4f8 Update vmactions/omnios-vm from base-vm
• c62e66c Generated from base-vm
• c20f351 Sync from base-builder
• c678b4c Update vmactions/omnios-vm from base-vm
• ca9f264 Generated from base-vm
• 996b881 Update version to v1.3.5
• ca3ef77 Update vmactions/omnios-vm from base-vm
• bec7f49 Generated from base-vm
• cb523b3 Bump versions from upstream releases
• fd93d8d Update version to v1.3.5
• Additional commits viewable in compare view

Updates vmactions/openindiana-vm from 1.1.5 to 1.1.6

Release notes

Sourced from vmactions/openindiana-vm's releases.

v1.1.6

sync: tar

A new way to share the workspace: the tree is streamed in as a ustar archive over the ssh connection the action already opens, and streamed back the same way when the run finishes. Nothing is installed in the guest and no filesystem support is needed on either side, unlike sshfs and nfs. openindiana-builder v2.1.2 declares it for every release, and it was verified on this guest before the declaration went in: 300 files plus a 1 MB binary blob pushed, a file written inside the VM, the whole tree pulled back and compared by content hash.

rsync remains the default.

Under the hood

openindiana-builder v2.1.2 is also the first openindiana build to publish releases.json, the machine-readable index this action bakes its configuration from -- which is why the pre-tar method list survived until now.

The runtime moves to anyvm v0.6.5, twelve releases on from the v0.5.3 that v1.1.5 shipped. Two of its fixes reach every job: a failed folder sync is now fatal instead of a warning that left the guest running without the files it was about to use, and the workspace push no longer carries the runner's own harness directories into the guest.

Full Changelog: vmactions/openindiana-vm@v1.1.5...v1.1.6

Commits

• 21e57a4 Update vmactions/openindiana-vm from base-vm
• 88fa269 Generated from base-vm
• 0ad38a3 Sync from base-builder
• 204c5fe Update vmactions/openindiana-vm from base-vm
• 9bb164b Generated from base-vm
• 48f9a41 Update version to v1.1.5
• 3c5d83c Update vmactions/openindiana-vm from base-vm
• 35bbf60 Generated from base-vm
• 5bf2381 Bump versions from upstream releases
• 9e4c654 Update vmactions/openindiana-vm from base-vm
• Additional commits viewable in compare view

Updates vmactions/tribblix-vm from 1.0.3 to 1.0.5

Release notes

Sourced from vmactions/tribblix-vm's releases.

v1.0.5

The runtime moves to anyvm v0.6.5 (from v0.6.4), keeping the whole fleet on one version. This action's surface is unchanged -- same images, same sync methods, same defaults. The bump carries one runtime change of note: on hosts whose nested AMD virtualization corrupts AVX512 XSAVE state, the CPU-feature mask now drops the whole AVX512 family instead of only avx512f.

Full Changelog: vmactions/tribblix-vm@v1.0.4...v1.0.5

v1.0.4

update

Full Changelog: vmactions/tribblix-vm@v1.0.3...v1.0.4

Commits

• 238d918 Update vmactions/tribblix-vm from base-vm
• e01975f Generated from base-vm
• fc387aa Sync from base-builder
• fb2f200 Update vmactions/tribblix-vm from base-vm
• 485bc5c Generated from base-vm
• eca32fe Update vmactions/tribblix-vm from base-vm
• 9fda6b7 Generated from base-vm
• 5be5d8d Update version to v1.0.4
• e0282bf Update vmactions/tribblix-vm from base-vm
• f0fdcdf Generated from base-vm
• Additional commits viewable in compare view

Updates vmactions/ghostbsd-vm from 1.0.2 to 1.0.3

Release notes

Sourced from vmactions/ghostbsd-vm's releases.

v1.0.3

sync: tar

A new way to share the workspace: the tree is streamed in as a ustar archive over the ssh connection the action already opens, and streamed back the same way when the run finishes. Nothing is installed in the guest and no filesystem support is needed on either side, unlike sshfs and nfs. ghostbsd-builder v2.0.8 declares it for every release, and it was verified on this guest before the declaration went in: 300 files plus a 1 MB binary blob pushed, a file written inside the VM, the whole tree pulled back and compared by content hash.

rsync remains the default.

Under the hood

The image builder moves to ghostbsd-builder v2.0.8, two releases on: the nested-WHPX boot wedge is fixed, the disk is cleaned before export, and the builder now publishes releases.json, the machine-readable index this action bakes its configuration from.

The runtime moves to anyvm v0.6.5, fifteen releases on from the v0.5.0 that v1.0.2 shipped. Two of its fixes reach every job: a failed folder sync is now fatal instead of a warning that left the guest running without the files it was about to use, and the workspace push no longer carries the runner's own harness directories into the guest.

Full Changelog: vmactions/ghostbsd-vm@v1.0.2...v1.0.3

Commits

• 47d491c Update vmactions/ghostbsd-vm from base-vm
• acfb33d Generated from base-vm
• 23aa1be Sync from base-builder
• f720aaf Update vmactions/ghostbsd-vm from base-vm
• 47f1779 Generated from base-vm
• 9c4937a Update vmactions/ghostbsd-vm from base-vm
• 499c9c7 Generated from base-vm
• 6bf400a Update version to v1.0.2
• f0cad1d Update vmactions/ghostbsd-vm from base-vm
• de9da92 Generated from base-vm
• Additional commits viewable in compare view

Updates vmactions/openeuler-vm from 1.0.0 to 1.0.2

Release notes

Sourced from vmactions/openeuler-vm's releases.

v1.0.2

fix vm

Full Changelog: vmactions/openeuler-vm@v1.0.1...v1.0.2

v1.0.1

sync: tar

A new way to share the workspace, available on every architecture including riscv64 and loongarch64: the tree is streamed in as a ustar archive over the ssh connection the action already opens, and streamed back the same way when the run finishes. Nothing is installed in the guest and no filesystem support is needed on either side, unlike sshfs and nfs. openeuler-builder v2.0.2 declares it for every release, and it was verified on this guest before the declaration went in: 300 files plus a 1 MB binary blob pushed, a file written inside the VM, the whole tree pulled back and compared by content hash.

rsync remains the default.

Under the hood

The runtime moves to anyvm v0.6.5, twelve releases on from the v0.5.3 that v1.0.0 shipped. Two of its fixes reach every job: a failed folder sync is now fatal instead of a warning that left the guest running without the files it was about to use, and the workspace push no longer carries the runner's own harness directories into the guest.

Full Changelog: vmactions/openeuler-vm@v1.0.0...v1.0.1

Commits

• 5a34950 Update vmactions/openeuler-vm from base-vm
• 9d4ec95 Generated from base-vm
• cc48766 Bump versions from upstream releases
• 9cbaa1b Update version to v1.0.1
• 507b2e6 Update vmactions/openeuler-vm from base-vm
• 58727f1 Generated from base-vm
• 6b13c27 Bump versions from upstream releases
• 0505c77 Update vmactions/openeuler-vm from base-vm
• 93de571 Generated from base-vm
• b507643 Bump versions from upstream releases
• Additional commits viewable in compare view

Updates vmactions/blissos-vm from 1.0.1 to 1.0.2

Release notes

Sourced from vmactions/blissos-vm's releases.

v1.0.2

sync: tar

A second way to move the workspace. Android ships no rsync, no sshfs and no NFS client, so scp was the only option until now; sync: tar streams the tree as a ustar archive over the same connection and is the faster of the two on a large tree. Nothing is installed in the guest. Verified on this guest before the declaration went in: 300 files plus a 1 MB binary blob pushed, a file written inside the VM, the whole tree pulled back and compared by content hash.

scp remains the default.

Under the hood

The image builder moves to blissos-builder v2.0.3 and the runtime to anyvm v0.6.5, fifteen releases on from the v0.5.0 that v1.0.1 shipped. The builder now mirrors its dropbear source tarball at a pinned version -- an upstream download hiccup used to produce an image missing its ssh server instead of a red build -- and publishes releases.json, the machine-readable index this action bakes its configuration from.

Two runtime fixes reach every job: a failed folder sync is now fatal instead of a warning that left the guest running without the files it was about to use, and the workspace push no longer carries the runner's own harness directories into the guest.

Full Changelog: vmactions/blissos-vm@v1.0.1...v1.0.2

Commits

• e4a4ae2 Update vmactions/blissos-vm from base-vm
• a590410 Generated from base-vm
• 9356464 Sync from base-builder
• fc6590d Update vmactions/blissos-vm from base-vm
• d892f05 Generated from base-vm
• 17af3d1 Update vmactions/blissos-vm from base-vm
• a8baad1 Generated from base-vm
• 0afd8e1 Update version to v1.0.1
• f7df17f Update vmactions/blissos-vm from base-vm
• bfd9bc9 Generated from base-vm
• Additional commits viewable in compare view