chore(deps): update vmactions/solaris-vm action to v1.4.0

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
vmactions/solaris-vm	action	minor	v1.3.8 → v1.4.0

---

Release Notes

vmactions/solaris-vm (vmactions/solaris-vm)

v1.4.0

Compare Source

Boot with 2 GB of memory

A job with mem: 2048 could time out at "Starting VM" while the same job
passed on the next runner (#​63). The guest was not
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

v1.3.9

Compare Source

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

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.