jaap-jan 205f946450 Give the nightly's publisher a curl to publish with ...

The android job builds its APK in a glibc container and then does the publishing
on the host, and the host is Alpine — busybox wget, and no curl anywhere on it.
So the step that talks to the forge six times died on the first of those calls
not written to tolerate a failure, with `curl: command not found` and exit 127,
after the whole build had already been paid for.

It took until the fourth call to say so, and that is the part worth reading. The
lookup for an existing release and the tag delete before it both end in `|| true`
with stderr discarded, which is exactly right for "there is no nightly yet" and
indistinguishable from "there is no curl on this machine". Installing it is what
makes those two different again. Dropping the `|| true` instead would fail the
step on the first run of a channel that has never published, which is the one
state that shape is there to handle.

Not busybox wget in curl's place. The asset upload is a multipart -F, which
busybox wget cannot send — so that reading ends in a release created with no APK
on it, which is the failure the verification at the end of the step exists to
catch, arrived at on purpose this time.

Conditioned exactly like the step it serves, main only, because nothing else in
this job wants curl and a pull request should not pay for a package it will not
use. That is a coupling rather than a tidiness, and it is in the comment: the two
conditions have to move together, and loosening the publish on its own puts the
job back at exit 127 several minutes in.

Unproven until the next main build, since the install path only runs there. What
is checked is that the workflow still parses, that the script is valid under sh
as well as bash like the ensure steps beside it, and that the two conditions read
identically once parsed.

2026-08-05 21:39:58 +02:00

..

ci.yml

Give the nightly's publisher a curl to publish with

2026-08-05 21:39:58 +02:00