The early stop compared the offered version with the installed one for
equality. Started from a release newer than the channel holds, the test
went on to the updater with nothing to install. It now asks pacman's
vercmp and stops when the offer is the same or older.
The picture of a reboot that stuck was inside the condition that wants
both the before and the after picture, so it was left out exactly when
there was no after to show. It now has its own condition.
Run against rc, the test stopped at a password prompt and then at a
question, each until its 30 minute limit.
sudo asked for a password although the test had written a rule that
lets it through: sudo takes the last rule that matches and reads its
folder in name order, and the rule's name sorted before the install's
own. The release's updater also runs "sudo -v", which asks unless every
rule for the user lets it through. The rule now sorts last, turns the
question off for the user, and the test checks both before going on.
rc holds what stable holds today. The release's updater, run with
nothing to do, ends at a prompt nobody answers. The test now asks the
channel what it offers before it starts, and with nothing newer on offer
it stops in seconds and says so.
The comment shows the two pictures only when both exist.
A channel that holds the version the machine already has upgrades
nothing, and every other check passes on a machine that was only
rebooted: rc is in that state today. A twelfth check requires the
Omarchy package to have changed.
Two runs on different branches both push pictures to one branch. The
second to push was refused and its comment never written. The push is
now tried again on top of whatever got there first; each run's folder is
its own, so there is nothing to merge.
The workflow no longer runs for pull requests. It is started by hand,
and still posts to the pull request of the branch it was started on.
The fork fallback and the fork guard go with the trigger.
Two checks could pass without the thing they named being true:
The wallpaper check asked only whether the file the link points at
exists, so an update that swapped the user's picture for another would
pass. It now compares before and after: the same picture, whatever
format it is kept in, and present.
The failed-units check read an empty answer as nothing failed, which is
also what a service manager that cannot be asked gives. A query that
fails is now recorded as that, and fails the check.
Every test so far installs fresh. Nothing took a machine on the last
release and updated it, which is what most users of a new release do.
test/upgrade-test takes an installed system, moves it to edge or rc with
omarchy-channel-set in a login shell, as a user would, reboots it
through the firmware so the new kernel is the one that starts, and
checks eleven things: the update's exit status, skipped migrations, that
the reboot comes back by itself, into a new boot and an installed
kernel, the channel, the system's state, failed units, the desktop, the
wallpaper the user had, and the boot menu. It writes a report and takes
a picture of the unlocked desktop before and after. A reboot that only
comes back after a key press is a failure, and is said to be that.
The Upgrade test workflow installs a release from its signed ISO with
the install test, then runs it. It is started by hand, and runs for a
pull request that changes the test. A second job, the only one that can
write, commits the pictures to the upgrade-test-screenshots branch and
posts the report as one comment on the branch's pull request, updated in
place on later runs.
Run by hand from 4.0.4 to today's edge it found two things: the
wallpaper link left pointing at a file the update renamed
(omacom/omarchy#14596), and one reboot in three stuck on a black screen
until a key was pressed (omacom/omarchy#14771).
Emir Beganovic