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

[dependabot]

Bumps the actions group with 3 updates in the / directory: vmactions/freebsd-vm, vmactions/netbsd-vm and vmactions/solaris-vm.

Updates vmactions/freebsd-vm from 1.5.5 to 1.5.7

Release notes

Sourced from vmactions/freebsd-vm's releases.

v1.5.7

FreeBSD 10.4 and 11.4, and a fix for "Unsupported OS: freebsd"

New releases

FreeBSD 10.4 and 11.4 on x86_64, from image builder 2.2.8. The action now offers 15 releases; the default is still 15.1.

• uses: vmactions/freebsd-vm@v1 with: release: "10.4"

The leading-part form works too: release: "10" and release: "11" pick the newest matching release, so the action now ships 10, 11, 12, 13, 14 and 15.

pkg.FreeBSD.org dropped its FreeBSD 10, 11 and 12 repositories long ago, so these images take their packages from the preserved SGGS mirror (https://mirror.sg.gs/freebsd-pkg/), which keeps FreeBSD's original repository signatures; pkg verifies them against the fingerprint shipped in the base system. Two things the VM runtime had to learn to run them: 10.x and 11.x boot via SeaBIOS, since their images have no EFI system partition, and 10.4 runs on QEMU's qemu64 CPU model, because FreeBSD 10's signal delivery panics when -cpu host exposes modern XSAVE features.

12.4 x86_64 gains rsync and sshfs

The same mirror reaches 12.4 x86_64: the image now ships rsync and fusefs-sshfs, so all five sync methods work there instead of nfs, scp and tar only. 12.4 aarch64 stays base-only; no aarch64 packages exist for FreeBSD 12.

Fixed: a lost network probe no longer fails as "Unsupported OS"

#163: a job with release: '14.0' failed after three minutes with

Error: Unsupported OS: freebsd. Builder repository anyvm-org/freebsd-builder not found.

although the image exists. A single failed probe of the release download URL sent the run down the GitHub REST API. The action never passed a token, so that request was unauthenticated and shared the 60/hour per-IP limit with every other job on the runner IP; the 403 was retried for three minutes and then reported as an unsupported OS. Two changes close this:

... (truncated)

Commits

• 4469451 Update vmactions/freebsd-vm from base-vm
• a1432a5 Generated from base-vm
• 95e5c02 Update vmactions/freebsd-vm from base-vm
• 7c33c64 Generated from base-vm
• 92f7fa4 Bump versions from upstream releases
• c0e53c3 Update vmactions/freebsd-vm from base-vm
• 11feb8f Generated from base-vm
• 224f1ac Update version to v1.5.6
• e978178 Update vmactions/freebsd-vm from base-vm
• 2e17369 Generated from base-vm
• Additional commits viewable in compare view

Updates vmactions/netbsd-vm from 1.4.9 to 1.5.0

Release notes

Sourced from vmactions/netbsd-vm's releases.

v1.5.0

add 9.5

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

Commits

• 20ee93a Update vmactions/netbsd-vm from base-vm
• 74dcc69 Generated from base-vm
• 2a8c76a Update vmactions/netbsd-vm from base-vm
• 7ebe4d4 Generated from base-vm
• a031b05 minor
• 2e1d6ef Update version to v1.4.9
• 0794073 Bump versions from upstream releases
• dae01dc Update vmactions/netbsd-vm from base-vm
• 2b17136 Generated from base-vm
• fa16db4 Update vmactions/netbsd-vm from base-vm
• Additional commits viewable in compare view

Updates vmactions/solaris-vm from 1.3.9 to 1.4.0

Release notes

Sourced from vmactions/solaris-vm's releases.

v1.4.0

Boot with 2 GB of memory

A job with mem: 2048 could time out at "Starting VM" while the same job vmactions/solaris-vm#63 crashing: its console showed svc.startd: Couldn't fork ... Cannot allocate memory and /tmp: File system full, swap space limit exceeded, and sshd was killed before it ever listened. The cause was in the image, not the runner: svc:/application/man-index rebuilt the man page index with catman on every boot of the snapshot image, peaking at 564 MB for about 50 seconds, on top of a kernel that already takes close to 1 GB at 2 GB. Whether sshd came up first was a race, which is why the failure looked host-dependent.

solaris-builder v2.0.8 ships images with man-index and the other services a CI guest never uses disabled: sstore, the Solaris Web UI (five httpd), the hal/dbus/rmvolmgr removable-media stack, fault notification, the extra virtual terminals, smb, InfiniBand, FCoE, iSCSI, sendmail-client and the compliance guide generator. rad, fmd, auditd and the nfs/autofs pieces stay.

Measured on one host with mem: 2048 and the production CPU flags, ::memstat about a minute after boot:

image	boot-to-ssh	Kernel	User/Anon	Free	daemons RSS
v2.0.7 (as shipped)	timeout	-	-	-	587 MB
v2.0.7, man-index/webui off	26 s	1.45 GB	354 MB	13 MB	~480 MB
v2.0.8	33 s	1.31 GB	252 MB	203 MB	317 MB

The daemons RSS column is the summed resident size of every process after boot; the v2.0.7 figure was taken at 4 GB since that image never reached ssh at 2 GB. 2 GB now boots, but with about 200 MB to spare; give a real build 4 GB or more.

Under the hood

The runtime moves to anyvm v0.6.9 (from v0.6.5). Nothing in that range touches this guest's launch.

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

Commits

• a11f407 Update vmactions/solaris-vm from base-vm
• 0ff57b2 Generated from base-vm
• 3c90528 Update version to v1.3.9
• 52b1df2 remove
• be40c6b Update vmactions/solaris-vm from base-vm
• 5dce673 Generated from base-vm
• 1add24f Bump versions from upstream releases
• 7a1e636 Update version to v1.3.9
• 0c0b01b Update vmactions/solaris-vm from base-vm
• bb43872 Generated from base-vm
• Additional commits viewable in compare view