Automate generation of Docker images and testing via GitHub actions #44
Conversation
No problem! I think now it should be good to go 🤞🏻 I am not sure how you can play with the workflows without merging to be honest. Most likely you will need to fork this branch into a new repository, since even merging this branch into a separate branch instead of master won't work as the GitHub packages are shared accross branches I think. (if you don't mind about this then its OK I think) Remember that you will need to create a github token with write permission for packages (and another one in your fork if you want to test it there!) |
|
Yeah totally, I would play with this in my fork! GitHub is still unhappy:
|
I am not sure if I did it properly but what I did is the following:
I had previously done a |
|
I see. It's likely the presence of that merge commit (master into feature branch) that confuses GitHub. Worst case scenario I'll fix this manually, do not spend too much time on it :) |
Okay, I think I cannot fix it, hopefully you can do it in much less time 👍🏻 |
This should close #40 and close #36.
After this PR the images should appear as a GitHub package as in https://github.com/lobis/root-docker/pkgs/container/root.
This PR creates GitHub actions to build most of the Dockerfiles. It builds all the "from binaries" images and also Ubuntu from source.
There is one action for each Dockerfile.
The actions take no parameters, they just build the images with the default configuration.
The actions can be triggered manually (individually) or via the aux action called "Trigger Build and Publish All Images", which just sends a trigger for all other actions (excluding "from source", since they take a long time). They are also triggered whenever there is a change to the corresponding directory (e.g. fedora action is triggered whenever something changes in the
fedora/*directory).Running the action will upload the image to the GitHub package repository with the corresponding tag. The tag is generated after building the image, so the root version will always be correct (taken directly from
root-config --version. The tagging schema is the following:$ROOT_VERSION_MAJOR.$ROOT_VERSION_MINOR.$ROOT_VERSION_PATCH-$OS_NAME$OS_VERSION_IDFor example the fedora action would produce:
6.26.02-fedora35. The OS version ID is only applied to Fedora, Ubuntu, and CentOSThe version of root / OS depends exclusively on the default parameters of the Dockerfile. Updating the contents of this file should automatically trigger the action and produce a newer image.
In order to work after merge, we need to add a secret to the repository under the name
GHCR_WRITE_TOKENthat contains a token with write permission to packagesAlso currently the
GentooDockerfile doesn't seem to work. The Ubuntu from source also doesn't seem to work, I don't understand why, but the corresponding acitons are fine.