Automate docker image build for deployments
We currently have scripts that builds docker images out of git tags. This then
docker push) them in the swh gitlab registry.
Another human intervention is required to update the swh-charts repositories to reference the new image versions to use (a yaml file ). Those actions are manual. We need to switch to automation for this part , e.g. script(s) called from within jenkins jobs.
There exists 2 workflows:
- New release of a swh package (we have somewhat control over it). It should be packaged with its dependencies updated. Other packages depending on it should be rebuilt too.
- Release of external packages (which we don't control).
That could be implemented with 2 jobs:
- One job about release of a new component version (and its impacts. e.g. swh.core)
- Another job triggered daily to keep up-to-date external dependencies
Release update job:
- React on git tag push (on development repositories), which triggers
- swh-apps!11 (merged): A script to generate list of impacted images to rebuild (starting with the first repository/application at step 1.).
- Rebuild said impacted images in proper order (from first application 1.) and release new image versions in the gitlab registry
- swh-apps!13 (merged): Another script to update the staging values-swh-application-versions.yaml  (commit and push)
- argocd then triggers the deployment first in staging
- If all is good , argocd triggers deployment on production (merge staging branch into production and push)
- Otherwise, this reverts the commit from step 5 (git revert and push that commit in staging branch)
Daily update job:
- Triggered by a cron
- List all apps and triggers a rebuild
- The end checks stays the same as the previous job
build-docker-images (list impacted images, then in // -trigger-> build-docker-image, then opens MR) 
swh/infra/ci-cd/swh-jenkins-jobs!181 (merged): incoming-tag -triggers-> build-docker-images
 https://jenkins.softwareheritage.org/job/swh-apps/job/build-docker-images/  The current implementation would be scripts triggered within a jenkins job
 It'd be a manual check by the sysadm reviewing the mr