v1.12.0

[webknjaz]

⚡️ Why Should You Update?

This is a minor version bump, but it does not add any new user-facing interfaces. Still, I felt like it should not be a patch-release: this update brings significant changes to the action invocation and internal release process.

Previously, each invocation of pypi-publish required building a container image in the invoking CI job. This was inefficient and added about 30 seconds to the publishing jobs at their startup just to build the container.

I wanted to improve this for over three years (#58) and a little over half a year ago @br3ndonland💰 stepped up and offered a very comprehensive solution to the limitation I was hoping to overcome: #230.

Going forward, I'm going to pre-build per-version containers prior to cutting each release. And the action invocations will just pull the image from GitHub Container registry.

Caution

Known quirks:

• This seems to not work on self-hosted runners without a python executable: After this update, my github actions are broken with below logs #289. The workaround could be installing it prior to running the action.
• Pinning to commit hashes does not work: Unable to find image 'ghcr.io/pypa/gh-action-pypi-publish:61da13deb5f5124fb1536194f82ed3d9bbc7e8f3' #290. Workaround: postpone updating until it's fixed or switch to Git tags for now. Subscribe to that issue to follow the progress. UPD: This was an issue during the first 12 hours post release and it has been addressed upstream by publishing a commit SHA-tagged image for the release on Nov 12, 2024 at 10:27 UTC+1.
• Calling pypi-publish from another nested repo-local composite action might be breaking file paths: No Such File or Directory #291. Workaround: postpone updating until it's fixed. Subscribe to that issue to follow the progress.
• Running within GitHub Enterprise fails on the action repo clone: Unable to use v1.12.0 on Github Enterprise #292. Workaround: postpone updating until it's fixed. Subscribe to that issue to follow the progress.

🪞 Full Diff: v1.11.0...v1.12.0

🧔‍♂️ Release Manager: @webknjaz 🇺🇦

---

This discussion was created from the release v1.12.0.

[kimdwkimdw]

After this update, my github actions are broken with below logs

/usr/bin/git sparse-checkout disable
/usr/bin/git config --local --unset-all extensions.worktreeConfig
Checking out the ref
/usr/bin/git log -1 --format=%H
61da13deb5f5124fb15361[94](https://github.com/my-repo/actions/runs/11699412134/job/32581371498#step:4:105)f82ed3d9bbc7e8f3
Run # Create Docker container action
/mnt/data/action-runner/_work/_temp/3b[95](https://github.com/my-repo/actions/runs/11699412134/job/32581371498#step:4:106)2215-1ada-40f7-8021-896c7e395c22.sh: line 2: python: command not found

[webknjaz]

Let's continue this in #289, which requires extra details.

[cpswan]

Looks like this breaks if you pin your actions to SHAs rather than using tags as it tries to find a docker image with the tag of the SHA. #290

Two workarounds come to mind:

1. Tag the container images with the git SHA for the corresponding release.
2. For people following the convention of having a comment with the version tag after the SHA it should be possible to extract to spot that a SHA is being used and extract the version from the comment.

[cpswan]

I think (1) could be done manually (for this release) to get any folk using SHA pinning back in action whilst a more permanent approach is resolved. But falling back to a local build if an image isn't found sounds like a pragmatic safety net.

[webknjaz]

The thing is that it's published from CI, so it needs some effort to make sure that a thing built locally is equivalent. I'm processing the regression reports and will try to do something about this soon. So far, this one sounds like it'd affect most people, and the others might be niche. But I want to see the full picture first.

[webknjaz]

@cpswan I realized that I can invoke the container publishing workflow with the commit hash too, so no need for local builds. It should be live now. Could you restart your job to see if that helped?

[cpswan]

Thanks @webknjaz that seems to have fixed it :)

[webknjaz]

Wonderful! And I see that the attestations also didn't break: https://github.com/atsign-foundation/at_python/actions/runs/11696852234/job/32585556158#step:3:237.

Thanks for verifying! This reduces the immediate pressure on me to work on the regressions right now.