Hi all
- Imagine we have a monorepo with two projects “ProjectA” and “ProjectB”
- I create a feature branch to make some changes to both projects and create an MR
- An MR pipeline is executed and all jobs are done without problem
- I accept the MR and a new pipeline is executed on main, but due to some error in some part of the code or in the .gitlab-ci.yml or in a migration script for whatever, some jobs fail and the pipeline is broken
- so, I have the code already merged, neither of my two projects was deployed in production
- Suppose the error was a badly assigned variable in the .gitlab-ci.yml (workflow/rules/when main), then I create a new MR, correct the error and merge again to main
- in this case no job is executed because there was no change in any application
…And the question remains… what happened to the merge that failed? what is the best way to redeploy projects without having to make dummy changes?
I know there are merge results pipes that help prevent this scenario, but for those of us who haven’t used it yet, what would be the correct way to handle this situation?
I really appreciate your help
Regards!!
1 Like
I think this is only an issue if you have rules to run the deployment jobs conditional on certain files being changed (source code for projects A and B respectively). In that case, it should be sufficient to add .gitlab-ci.yml to the list of files that trigger a new deployment, in addition to the source directories.
Maybe you could also define rules so that running a pipeline manually, with a particular variable set, would run the deployment jobs regardless of changes. This would allow you to force a redeployment in exceptional cases.
We have a different setup because we have a single package repository but we encountered a similar issue recently. We publish the package, docs and container image when a commit is tagged with a string that looks like a version. There was a bug in our CI file that prevented one of the artifacts being published. We didn’t want to modify the git tag (we treat them as immutable) so we fixed the issue and then tagged a post-release as per Python versioning conventions. So we ended up with an incomplete version 2.1.7 followed by a fixed 2.1.7.post0. pip, the Python package installer, knows what the version means so it does the job even if our users don’t necessarily understand why it’s numbered a bit differently.