When doing configuration-as-code and/or infrastructure-as-code, the problem often is that something being committed in the version control does not mean it is also applied on the environment. But there is a way to ensure it (except for very untimely network failures): push the intended changes in a branch and have the CD server apply the configuration and push it in master when it applies.
So I have found a way to set up the DevOps repository so that a pull-request can only be merged if a build succeeded (1). And such build is useful for validating the syntax and previewing the changes (tf plan, kubectl diff and similar).
But then I still need to actually complete the pull request from the build.
Ensuring the PR can't be completed in any other way can probably be done with the policy or permissions, and ensuring the pull request is otherwise ready (reviewed) can be done by replacing the review approvals with approvals in the pipeline.
CodePudding user response：
You can always have your pipeline run the merge :
- instead of running your tests on the HEAD commit of the branch,
- have your job switch to your target branch, run
git merge <commit>, and run your tests on that.
CodePudding user response：
But then I still need to actually complete the pull request from the build.
I assume you could achieve that by using the API, however, my recommendation is to set the branch policy to require a build policy (or external status policy) and then just use the Auto-Complete functionality in the PR. As soon as the build/status posts success the PR will complete immediately, assuming all other required checks have been met.
Notes:
- Even if the Build or Status Policy is set to "Optional" instead of "Required", a PR set to auto-complete will wait until the build completes, and will only auto-complete if the build succeeds. In the case when an "optional" build fails, it will block auto-complete, but you can still go and press the Complete button yourself. If the build is "Required" instead of "Optional", you cannot complete the PR unless the build succeeds, or else you have the security permission to Bypass branch policies. It sounds like in your case you would make the build required to achieve your goal.
- Build and Status Policies have an optional path filter. This allows you to only require the build succeed if the PR is modifying specific files or folders. This is great so you don't have to trigger unnecessary builds when only unrelated files are modified in a PR.
Tip: If your developers start using Auto-Complete, I suggest also setting "Check for comment resolution" to "Required". In this way when a code reviewer makes a comment on the PR with a suggestion, the PR won't auto complete without the developer seeing that comment and possibly making changes.