Automate generation of Docker images and testing via GitHub actions

[lobis]

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_ID

For example the fedora action would produce: 6.26.02-fedora35. The OS version ID is only applied to Fedora, Ubuntu, and CentOS

The 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_TOKEN that contains a token with write permission to packages

Also currently the Gentoo Dockerfile 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.

[lobis]

Hi @lobis , thank you very much for your continuous help with this, much appreciated!

As you see GitHub can't figure out how to rebase this branch on master, can you please do it manually and fix the conflicts?

Other than that the PR looks great, I will try to find the time to play with the workflows a little bit and then merge it.

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!)

[eguiraud]

Yeah totally, I would play with this in my fork! GitHub is still unhappy:

[lobis]

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:

git remote -v

origin  [email protected]:lobis/root-docker.git (fetch)
origin  [email protected]:lobis/root-docker.git (push)
upstream        https://github.com/root-project/root-docker.git (fetch)
upstream        https://github.com/root-project/root-docker.git (push)

I had previously done a git merge upstream/master and then I did a git rebase upstream/master and it seems fine, not sure how to fix it. I will give it another try.

[eguiraud]

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 :)

[lobis]

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 👍🏻