-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.github/workflows: Publish the Arch Linux image at quay.io/toolbx/... #1308
.github/workflows: Publish the Arch Linux image at quay.io/toolbx/... #1308
Conversation
Until now, the Arch Linux image was being published at quay.io/toolbx-images/archlinux-toolbox:latest. This renames the image to arch-toolbox [1] to match the os-release(5) ID on Arch, and changes the location to quay.io/toolbx/arch-toolbox:latest. Build and push when there are changes in the 'images/arch' directory or in the GitHub workflow itself, as well as every other week (7th and 21st days of a month to be precise). [1] Commit 2568528 containers#861 containers#1308
4aac4b0
to
f13d2a5
Compare
I noticed that we are not using |
This reflects the value of the 'maintainer' LABELs of the images. containers#1308
Build succeeded. ✔️ unit-test SUCCESS in 10m 48s |
Note that this is missing the PR workflow, like the ubuntu one, which lets us validate change to the images on PRs while making sure that the images are not pushed. |
Yes, I was trying to limit my copy-paste cargo cult to the minimum. :) For example, I was a bit suspicious that the actual Did you see my question about Anyway, let me try to add a PR workflow. |
About For the cron syntax, you can use https://crontab.guru/ (linked in https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule) to validate your config |
I had added it as a precaution. Not sure how much that matters here. |
Okay. I will leave it alone since it seems to be working as is.
Thanks, https://crontab.guru/ is amazing. I think my understanding of the schedule above was correct. |
Until now, the Arch Linux image was being published at quay.io/toolbx-images/archlinux-toolbox:latest. This renames the image to arch-toolbox [1] to match the os-release(5) ID on Arch, and changes the location to quay.io/toolbx/arch-toolbox:latest. Build and push when there are changes in the 'images/arch' directory or in the GitHub workflow itself, as well as at 00:00 every Monday. [1] Commit 2568528 containers#861 containers#1308
... when there are changes in the 'images/arch' directory or in the GitHub workflow itself. containers#1308
This reflects the value of the 'maintainer' LABELs of the images. containers#1308
448ad63
to
2b114a2
Compare
Done. |
... when there are changes in the 'images/arch' directory or in the GitHub workflow itself. containers#1308
This reflects the value of the 'maintainer' LABELs of the images. containers#1308
2b114a2
to
28dc704
Compare
Build succeeded. ✔️ unit-test SUCCESS in 8m 23s |
At least the workflow for PRs seems to keep failing with:
... and I am getting lost in the documentation about whether this is meant to be a valid syntax or not:
At this point, I want to ditch the variables and keep it simple, and leave it to somebody more knowledgeable to parametrize things. |
Until now, the Arch Linux image was being published at quay.io/toolbx-images/archlinux-toolbox:latest. This renames the image to arch-toolbox [1] to match the os-release(5) ID on Arch, and changes the location to quay.io/toolbx/arch-toolbox:latest. Build and push when there are changes in the 'images/arch' directory or in the GitHub workflow itself, as well as at 00:00 every Monday. [1] Commit 2568528 containers#861 containers#1308
... when there are changes in the 'images/arch' directory or in the GitHub workflow itself. containers#1308
This reflects the value of the 'maintainer' LABELs of the images. containers#1308
28dc704
to
c23ec5b
Compare
Until now, the Arch Linux image was being published at quay.io/toolbx-images/archlinux-toolbox:latest. This renames the image to arch-toolbox [1] to match the os-release(5) ID on Arch, and changes the location to quay.io/toolbx/arch-toolbox:latest. Build and push when there are changes in the 'images/arch' directory or in the GitHub workflow itself, as well as at 00:00 every Monday. [1] Commit 2568528 containers#861 containers#1308
... when there are changes in the 'images/arch' directory or in the GitHub workflow itself. containers#1308
This reflects the value of the 'maintainer' LABELs of the images. containers#1308
c23ec5b
to
28913fa
Compare
Build succeeded. ✔️ unit-test SUCCESS in 9m 07s |
Let's hope the |
The VERSION_ID field in os-release(5) is optional [1]. It's absent on Arch Linux, which follows a rolling-release model and uses the BUILD_ID field instead: BUILD_ID=rolling A subsequent commit will add built-in support for Arch Linux. Hence, the code to get the default release from the host operating system can no longer assume the presence of the VERSION_ID field in os-release(5). Note that the arch-toolbox image is tagged with 'latest', in accordance with OCI conventions, not 'rolling' [2,3], which is the os-release(5) BUILD_ID. Therefore, it will be wise to use 'latest' as the default release on Arch Linux, to simplify how the default release matches with the default image's tag. This means that a os-release(5) field can't be used for the default release on Arch. [1] https://www.freedesktop.org/software/systemd/man/os-release.html [2] Commit 2568528 containers#861 [3] Commit a4e5861 containers#1308 containers#1303
Until now, the Arch Linux image was being published at quay.io/toolbx-images/archlinux-toolbox:latest. This renames the image to arch-toolbox [1] to match the os-release(5) ID on Arch, and changes the location to quay.io/toolbx/arch-toolbox:latest.
Build and push when there are changes in the 'images/arch' directory or in the GitHub workflow itself, as well as every other week (7th and 21st days of a month to be precise).
[1] Commit 2568528
#861