.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
debarshiray
force-pushed
the
wip/rishi/arch-publish-images
branch
from
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 |
|
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions 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
debarshiray
force-pushed
the
wip/rishi/arch-publish-images
branch
from
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
debarshiray
force-pushed
the
wip/rishi/arch-publish-images
branch
from
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
debarshiray
force-pushed
the
wip/rishi/arch-publish-images
branch
from
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
debarshiray
force-pushed
the
wip/rishi/arch-publish-images
branch
from
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
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 run the CI on 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. A similar change was made to toolbox(1) in commits 2ee82af and d14fd7b. [1] https://www.freedesktop.org/software/systemd/man/os-release.html [2] Commit 2568528 containers@2568528cb7f52663 containers#861 [3] Commit a4e5861 containers@a4e5861ae5c93625 containers#1308 containers#1438
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 run the CI on 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. A similar change was made to toolbox(1) in commits 2ee82af and d14fd7b. [1] https://www.freedesktop.org/software/systemd/man/os-release.html [2] Commit 2568528 containers@2568528cb7f52663 containers#861 [3] Commit a4e5861 containers@a4e5861ae5c93625 containers#1308 containers#1438
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 run the CI on 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. A similar change was made to toolbox(1) in commits 2ee82af and d14fd7b. [1] https://www.freedesktop.org/software/systemd/man/os-release.html [2] Commit 2568528 containers@2568528cb7f52663 containers#861 [3] Commit a4e5861 containers@a4e5861ae5c93625 containers#1308 containers#1438 containers#1535
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 run the CI on 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. A similar change was made to toolbox(1) in commits 2ee82af and d14fd7b. [1] https://www.freedesktop.org/software/systemd/man/os-release.html [2] Commit 2568528 containers@2568528cb7f52663 containers#861 [3] Commit a4e5861 containers@a4e5861ae5c93625 containers#1308 containers#1438 containers#1535
3 participants
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