0

I have a Gitlab and configured CI/CD processes. One job runs building process and after build it sending to test group. The problem is that some developers simply push commits from one of their remote branches to another of their remote branches. This is faster than creating and processing a merge request every time, but it creates a conflict due to the fact that one commit starts its process twice, because it was pushed into two different branches.

I would like the job to be started for one commit once, no matter how much it is pushed. One solution is to simply write all the SHA-processed commits to a file and run a repeat check, but it seems to me there should be a cleaner way. How can I do this through .yml file?

Mr. Don't know
  • 101
  • 1
  • A common practice is to introduce [protected branches](https://stackoverflow.com/questions/66450444/what-is-the-purpose-of-protected-branches-in-gitlab-when-you-can-bypass-the-prot) with push and force-push disabled. This way you must do a merge request. To put a commit from one branch to another one can use [cherry-pick](https://stackoverflow.com/questions/9339429/what-does-cherry-picking-a-commit-with-git-mean) in case of a hot-fix or similar. – Peter Krebs Jan 23 '23 at 12:28
  • I think changing the usual developing process for a lot of people is much more difficult than changing the CI/CD configuration. – Mr. Don't know Jan 23 '23 at 12:45
  • Sure but a CI/CD configuration that discourages a behavior also changes the developing process. The same change pushed to another branch [can have a different hash](https://stackoverflow.com/questions/16239051/why-do-i-have-the-same-commits-in-two-branches-with-different-hashes). You would not have to compare unique SHA hashes but the changes themselves. A changed commit date or a white-space changed would already break this. – Peter Krebs Jan 23 '23 at 13:08

0 Answers0