Proposal: Consider using Gitlab deployement feature for ci_template.yml
Sope
As of today, when we need to update gst-ci with a new docker, we first push a MR that picks from developer registry, wait for the new docker to be in the main registry and finally push another MR that fixes it.
The reason for this is because as soon as the first MR is merge, all the other projects starts using it. This makes the update process really tricky and error prone.
Proposal
Build Pipeline:
- Build required docker images (or all of them)
- Trigger the pipeline again in "Test and Deploy" mode
Note: all the new docker image SHA are passed ass trigger parameters
Test and Deploy Pipeline:
- Run all sort of builds using the new dockers
- Compile and Deploy the ci_template.yml to be used by the other component.
The idea is to allow some delay between merging a gst-ci branch and the resulting ci_template.yml being used by the rest of the GStreamer repository. Giving the CI a chance to actually build and test the new image before letting the rest of the system use it. It is also giving us the ability to roll-back, sleep on it, fix it later.
The reason I believe we need two pipelines with a trigger is because I didn't find any ways to pass variables between stages. Let me know if that's possible, again, this a proposal, nothing if this has been proven to work. The default ci_template.yml could look like:
In ci_template.yml we'd have:
job1:
extends: .job
image: ${JOB1_REGISTRY_IMAGE}
job2:
extends: .job
image: ${JOB2_REGISTRY_IMAGE}
Where JOB1_REGISTRY_IMAGE and friends are the variables we would pass with the trigger. This "unique" token in the ci_template_yml can easily be replaced to "burn" the deployed docker SHA into the ci_template.yml. In this proposal, using SHA for docker image tagging is kept, it's even key for the automation. This new proposal does not change the way the docker are tagged.