Create adminCLI docker container via CI/CD
Create an AdminCLI docker container via CI/CD
Proposed work:
Add a CI job, in it start with a docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY . This logs you into the GitLab registry associated with the right project, using permissions associated with whomever launched the pipeline.
The do your docker build -t $TAGNAME -f /path/to/Dockerfile extra-args… , however you need to get it working. You could cd first if that’s easier than using -f, and you may need other arguments from the environment. TAGNAME can be anything you want (that’s not a reserved or special variable name). It should be an image+tag format, like policy-cli:latest. Usually, I define a variable like that in the CI logic. [1] Now docker push $TAGNAME and it shows up in the GitLab container registry. All done.
[1] — I like to make two container images, like policy-cli-incremental and policy-cli. You can see an example of this in the release scripts project — here, I’m building 2 version of 3 different containers using variables and CI job templates. Your use case will likely be simpler. If the pipeline is running on a tag, I build policy-cli:v0.16.1 (or whatever the tag name is), then also link it to the latest by using docker tag policy-cli:v0.16.1 policy-cli:latest, then I docker push both.
If the pipeline is not on a tag, I build it as policy-cli-incremental:ad3ef03 (using the Git SHA). Similarly link this to policy-cli-incremental:latest). Now, when users want to run something, they can choose what to run:
- policy-cli-incremental:latest — The bleeding edge, never been tested, however the wind blows container. Only developers would be this insane.
- policy-cli-incremental:ad3ef03 — Test a specific SHA, for the cautious developer
- policy-cli:v0.16.1 — A specific stable version of the code, corresponding with a release. Typical usage
- policy-cli:latest — The latest released version. Not nearly as insane as using incremental:latest , for the more adventurous end user
Cleanup policies will automatically delete tags every night. By convention, it keeps latest, v*, and the most recent 5 tags. Everything else is deleted. Additionally, I periodically run a cleanup script that deletes images based on their container name. So, if you want your container image (the policy-cli bit) to be long living, I’ll need to add an exception for it. Let me know what you name it so I can do that.
[1].PS — Since your CLI is embedded in an otherwise active project’s repo, you may end up getting tons of containers building that are identical, since pipelines will run even if nothing changed in the CLI part. You may want to consider adding a changes rule to skip building the container if nothing’s changed on the CLI code. If that applies to your situation.. You could also consider making the CLI a separate project, with its own lifecycle.