Esgn/clean docker build

[esgn]

I've closed the former pull request. I'm reopening a draft one after having changed approach.
I've spent a bit of time on this and I think I have a slightly better understanding of github workflows now. All in all, and if I'm not mistaken, GitHub is not opensource and feature requests for many useful small features for CI/CD are still pending (ex : here or there). I'm still astonished by the fact the registry must be cleaned from a workflow (using an action which, at the end of the day, is nothing more than a client of the REST and GraphQL GitHub APIs).

Here is what we are aiming at for the Docker workflow.

Event	Build docker image	Push to registry	Clean untagged from registry	Clean deleted branch image
Push	X	X	X
Create branch	X	X	X
Delete branch				X
Pull request	X

In order to do all of this, my current solution is to use a docker.yml workflow which calls all the necessary workflows (workflow_call). I'm not sure it will please everyone but it opens the possibility to reuse the workflow files and keeps things clear, at least for me.

To try and summarize :

• On push : We pass the registry name, branch name (github.ref_name) and image name to docker-build-push.yml and it builds and pushes the Docker image using these inputs. I'm finally using docker/metadata-action only for generating automatic labels. I'm building the tag name using a shell command : We will need the tag name for the delete branch image workflow. This delete branch image workflow will run on the default branch (see here) and we cannot tell metadata-action where to get the branch name from. Keeping the tag generation out of metadata-action makes things easier. At the end of docker-build-push.yml we're calling docker-registry-cleanup.yml to remove the untagged image we've created.
• On create branch : In most cases Github does not trigger a push event on branch creation. We catch the create branch event in docker.yml and call docker-build-push.yml with the correct branch name (this time it's github.event.ref). Frankly it's not vital to create image on branch creation, but while I was as it I wanted to see how this could be done.
• On pull request : easy, we're building the docker image without tags or label and we're not pushing it to the registry.
• On branch delete : We're calling docker-delete-branch-image.yml with branch_name (github.event.ref) as input. This workflow will generate a tag in the same fashion that docker-build-push.yml and we're using an action to delete the tag name from the registry.

Remarks

• It's not possible to put the docker-*.yml in a directory and call them from it => over there
• I could put the tag name command in yet another separate file to prevent code duplication
• It's possible to add a schedule (cron like) to trigger the untagged image removal regularly
• I definitely and maybe we should try and use https://github.com/nektos/act to test these kind of things faster locally if it works
• I still have to find a way to grab the labels from the Dockerfile. For now automatic labels will do.

[naulan-chrzaszcz]

[esgn]

Bien vu !

On peut aussi se poser des questions sur l'autorisation totale donnée par défaut aux workflows dans l'organisation IGNF (voir settings > actions)

[esgn]

@naulan-chrzaszcz les problèmes de permissions et de nommage fou du repo devraient être réglés. Je te laisse trouver comment le casser à nouveau.

[zhak5388]

Suggested change

	name: Build Docker image for checkcing purposes
	name: Build Docker image for checking purposes

Non?

[zhak5388]

Je découvre, mais j'imagine que c'est normal? (Si le tag est pas valide pourquoi il est fait?)

Error: buildx failed with: ERROR: invalid tag "ghcr.io/zhak5388/temp_breakstuff:hello-y45é_-l": invalid reference format

[esgn]

Je continue de creuser alors qu'il ne faudrait pas ;)

Tag docker

• La définition de ce à quoi doit ressembler un tag docker est en fait ici https://pkg.go.dev/github.com/distribution/reference et est donc [\w][\w.-]{0,127} version Golang. A noter qu'en Go \w ne matche pas les caractères ASCII étendus. Bref un é ne passera pas à la différence d'un [a-z] en sed avec la locale par défaut sur les distribs classiques (avec LC_ALL=C on se rapproche du comportement de \w). Bref, on a la règle de validation du tag pour une image docker.

Branch name

• Côté git on peut s'appuyer là dessus pour valider le nom d'une branche https://git-scm.com/docs/git-check-ref-format . En pratique cela fait pas mal de règles différentes à respecter et c'est somme toute assez permissif. On peut avoir une branche nommée % ou %20 sans que cela pose de problème.
• GitHub semble suivre la ligne définie par Git (encore heureux). En passant par l'interface web, les caractères interdits (genre *) sont automatiquement supprimés du nom de la branche. Bref, on peut visiblement s'en tenir à la règle de nommage git.

On résume

• On peut facilement créer des noms de branches qui ne valideront pas [\w][\w.-]{0,127}. On peut tenter de remplacer dans le nom de la branche les caractères hors [\w.-] par un autre caractère mais celui-ci devrait matcher [\w] si on veut être tout à fait rigoureux => Une seule possibilité, remplacer par des _
• Ce remplacement n'empêchera pas les collisions entre tags ou la production de tags assez moches. Typiquement l'exemple de @zhak5388 y45é_+l deviendrait y45___l. On doit même pouvoir se lancer dans le one line ascii art en étant joueur.
• Bref, tout ca ressemble de plus en plus à de la geekerie pathologique. Ce qui serait éventuellement plus intéressant serait de pouvoir définir une regexp pour imposer une règle de nommage de branche sur un dépot. Si je continue de m'énerver sur le sujet je vais aller voir du côté des git hook.

J'ai poussé une nouvelle version de la désinfection des chaines de caractères au passage.

[esgn]

Solution 1 pour restreindre le nom des branches directement côté GitHub :

Dans settings

On créé une nouvelle rulesets qu'on applique à toutes les branches

On définit une restriction des noms de branches

En passant par l'interface web en utilisant un nom de branche non autorisé

En passant par la ligne de commande