v0.3.0 was released without a container image, because the bill of materials could not be uploaded #251

New issue

Closed

opened 2026-09-16 17:28:50 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-09-16 17:28:50 +00:00

Owner

The release itself went out correctly on 2026-09-16: the tag, the sdist, the wheel and the
changelog as its notes. The container image did not, and nothing said so — docker pull source.tiagoagueda.com/postulo/postulo:0.3.0 has nothing to answer with, and neither do
:0.3 or :latest.

What happened

image.yml had its steps in this order: build locally, scan, write the scan to the summary,
upload the bill of materials, then build for amd64 and arm64 and push.

The upload step is actions/upload-artifact@v4. This Forgejo answers the artifact API as a
GitHub Enterprise Server that does not implement v2 of it, so the step ends with

@actions/artifact v2.0.0+, upload-artifact@v4+ and download-artifact@v4+ are not
currently supported on GHES.

It carried if: always() but not continue-on-error, so it failed the job — and the push,
which was the next step, never ran. Everything before it had succeeded: the image built, both
scanners ran, the verdict was clean.

This is the mirror image of the fault fixed in the plugin repositories the same day, where
upload-artifact@v3 was disabled server-side and the fix was to move to v4. On this instance
v4 is the one that does not work. Both versions failing means no artifact upload works here
at all, which is worth knowing before anything else depends on one.

Fixed, and what is left

The push now runs before the upload, and the upload is continue-on-error: true. A release
where the bill of materials cannot be stored still publishes an image; one where the image
cannot be built still fails, which is the way round it should be.

Left open deliberately:

The bill of materials is not stored anywhere. The step will keep warning. Its own
comment says why it exists — somebody self-hosting can scan the release later against a
database that does not exist yet — and that argument still holds, so it wants a home the
server will accept: attached to the release beside the sdist and the wheel, which
scripts/release_tools.py publish already knows how to do.
Nothing notices an image that was never pushed. The release workflow and the image
workflow are separate by design (#81), so a green release says nothing about the image. A
check that the tags exist in the registry afterwards would have caught this in a minute
rather than by somebody trying to pull.
postulo-firefox was changed from v3 to v4 on 2026-09-16 on the assumption that v4
works here. It does not; that repository's artifact upload is now failing the other way and
wants the same treatment.

The release itself went out correctly on 2026-09-16: the tag, the sdist, the wheel and the changelog as its notes. The container image did not, and nothing said so — `docker pull source.tiagoagueda.com/postulo/postulo:0.3.0` has nothing to answer with, and neither do `:0.3` or `:latest`. ## What happened `image.yml` had its steps in this order: build locally, scan, write the scan to the summary, **upload the bill of materials**, then build for amd64 and arm64 and push. The upload step is `actions/upload-artifact@v4`. This Forgejo answers the artifact API as a GitHub Enterprise Server that does not implement v2 of it, so the step ends with @actions/artifact v2.0.0+, upload-artifact@v4+ and download-artifact@v4+ are not currently supported on GHES. It carried `if: always()` but not `continue-on-error`, so it failed the job — and the push, which was the next step, never ran. Everything before it had succeeded: the image built, both scanners ran, the verdict was clean. This is the mirror image of the fault fixed in the plugin repositories the same day, where `upload-artifact@v3` was disabled server-side and the fix was to move to v4. On this instance v4 is the one that does not work. Both versions failing means **no artifact upload works here at all**, which is worth knowing before anything else depends on one. ## Fixed, and what is left The push now runs before the upload, and the upload is `continue-on-error: true`. A release where the bill of materials cannot be stored still publishes an image; one where the image cannot be built still fails, which is the way round it should be. Left open deliberately: - **The bill of materials is not stored anywhere.** The step will keep warning. Its own comment says why it exists — somebody self-hosting can scan the release later against a database that does not exist yet — and that argument still holds, so it wants a home the server will accept: attached to the release beside the sdist and the wheel, which `scripts/release_tools.py publish` already knows how to do. - **Nothing notices an image that was never pushed.** The release workflow and the image workflow are separate by design (#81), so a green release says nothing about the image. A check that the tags exist in the registry afterwards would have caught this in a minute rather than by somebody trying to pull. - **`postulo-firefox` was changed from v3 to v4 on 2026-09-16** on the assumption that v4 works here. It does not; that repository's artifact upload is now failing the other way and wants the same treatment.

tiagoagueda added this to the 0.4.0 milestone

2026-09-16 17:28:50 +00:00

tiagoagueda added the

bug

label

2026-09-16 17:28:50 +00:00

tiagoagueda referenced this issue from a commit

2026-09-16 17:29:19 +00:00

Publish the image before the bill of materials, not after

tiagoagueda referenced this issue

2026-09-17 22:03:14 +00:00

Nothing proves a built-in carries the core version, and nothing tells an instance it is behind #272