Eliminating duplicate CI builds on pushes with tags

GitLab CI/CD
1

I’m trying to set up Gitlab CI with a big gnarly old C++ project.

We want tag pushes to initiate release builds and any push of commits to initiate CI builds (we can use CI_BUILD_TAG to differentiate and set a different version string). The problem I’m having is that when I push some commits and a tag together, Gitlab CI starts a build pipeline for both the tag, and the same commit on master. The branch pipeline starts first and blocks the tag pipeline for 40 minutes. Is there a way to get Gitlab CI only do one build in this case?

1 Like
2

You can make use of the only and except parameters to ensure that a particular job is only run for tags.

Does this help?

3

It is a better approach to only push your tag once the pertinent commit has passed through the pipeline successfully.

4

I have a similar issue here.

@markglenfletcher For me that won’t work. Since I have several jobs that need to be run on all branches and tags (= when releasing). There only is one additional job for tags. Not sure how that could be achieved with the mentioned page.

@sanmai-NL When I want to build I usually just add one more commit that updates the version number and the changelog. So I’m 100% certain that the new commit wil succeed.

5

@markglenfletcher, I have the same problem as the previous posters.

If I create a new commit, tag it and push it two builds will start: first the untagged, then the tagged.
As the untagged and the tagged have the same git hash there’s no difference between the two runs.

Is it possible to have Gitlab CI avoid running multiple builds that have the same git hash?

6

Huh, I never followed up to my original query. I ‘solved’ my problem by configuring to allow parallel builds. Inefficient, but we get the final tagged build soon enough, which is the important thing for us.

@runejuhl, in general GitLab cannot do this automatically, because builds may vary depending on tags or other info not contained in the built commit. I ran into this with Mosh on GitHub+Travis, where the build extracts a version number using git describe --dirty– that does something different for tagged vs. untagged.

7

@cgull, thanks for taking you time to get back to me. I’ve enabled parallel build myself, so I guess I could consider it as “solved” too :slight_smile:

Good point about CI-time changes. Having the option available would be nice though, even if it’s not always applicable. I’ll probably create an issue for it and see what the Gitlab team says.

Have a great day!

8

I added an issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/28979

If you have anything more to add (or have a way with words that makes it more plain what the goal is), please feel free to add comments.

9

Seems to be an old thread, nonetheless:

  • I modify the version number, commit, tag and only push the tag and afterwards reset my workspace to origin/master
  • Benefit: master is not changed, so it does not build.
  • Simple.version only updates with useless commit messages “update version to 1.2.3” do not spoil master.