Tagged commit triggers two builds

Enterprise
1

We are using Travis Enterprise together with GitHub Enterprise.

I have a .travis.yml with two deploy providers configured.

  • s3: to upload the JAR to S3
  • releases: to create a GitHub Release with the JAR

I was really confused when I was looking at the build log because I could see in the log “Skipping a deployment with the releases provider because this is not a tagged commit”. I was sure the commit was tagged. And then I realized that in fact it was actually creating a github release. How that can be?

I then realized that there are two builds in the Build History for that commit one for “master” and one for “v0.0.7” (my tag) both are building commit 6916c2a.

It seems wasteful that the same thing is build twice and even I can imaging that can be a race condition with the s3 provider trying to upload the same jar to the same location at the same time.

Is there a way to prevent this and trigger just the build for the tag in this case? Or it’s always going to build “master” and the tag as seperate thing even if they point to the same commit?

2

Hello, there.

First, one thing to notice is that the tags are associated with commits, not branches. You can, in fact, tag a commit that is not on any branch and push that tag to initiate a build. They may look similar when you see two builds on the same commit, but they are conceptually very different.

It is easy to prevent non-tag builds to not trigger deployments:

deploy:
  - provider: s3
    on:
      tags: true
    ⋮
  - provider: releases
    on:
      tags: true

See https://docs.travis-ci.com/user/deployment/#conditional-releases-with-on

3

I already have tags: true to skip the deploy for non tagged commits that why I’m getting the “Skipping a deployment with the releases provider because this is not a tagged commit”.

And I want to build/test every commit in master.

First, one thing to notice is that the tags are associated with commits, not branches
I was hoping that Travis could see that hey, I already built commit “6916c2a” when I was building tag v0.0.6. But fair enough, travis builds each branch and each tag independently so if I understood right , I can have 3 regular branches pointing to the same commit and it will also be build 3 times. I see the logic in that.

But, Is there a way to get a conditional build that says build every commit in master except those commits where there is a tag pointing to it (since I know those are going to be built in branch “tagname”)?

I guess the answer is no, and it’s ok. It’s not that big of a deal to have an extra build for the releases , they don’t happen that often. It’s just that I was trying travis and the build log messages confused me, I couldn’t understand why I was getting “because this is not a tagged commit”. Now I understand that I will never see a “tagged commit” in master ever. It will show up as if was building another branch called tagname.

Thanks for the help.

5

Hi, I’m afraid that this cannot be dealt with. The thing is that if you do git push, it only pushes commits not tags. You have to do a separate git push --tags. What this means it, that when the built is triggered, the tag doesn’t have to uploaded yet. Hence, it will built no matter what. The only workaround (apart from implementing the check, if the commit was already built) would be to push tags first and then the rest.