Travis-ci.com pointlessly builds tags

Travis CI Discussions & Feedback
1

See https://travis-ci.com/github/doublep/eldev/builds

Builds 91 and 92 are exactly the same: they are from master branch after the same commit. Build 92 was triggered probably because Travis considered tag 0.3.1 to be a new branch.

This is not, strictly speaking, a bug, because it doesn’t break anything. However, it does waste some resources by unnecessarily duplicating some builds.

2

For the record, as far as I remeber, on travis-ci.org there was no such issue.

3

on travis-ci.org it works the same way.

Well, tag build and commit build are generally two different builds. Because in the .travis-ci.yml it can be configured to do some extra stuff like deployment if it is a tagged build, while untagged build can do some other stuff, so I guess this is why it does both builds, because it is not possible to easily tell that those two builds re the same or not.

But I think it would be handy if there was a per-repo or global setting to switch off simple commit build if there is a tagged build from same commit.

4

Well, as I said, it is not really a problem. It is just that Travis seems to do the very same thing twice, wasting some computation power on this. But maybe it is not really easy to e.g. automatically figure out from .travis.yml if the second build can be safely skipped or not. I just noticed this — but if you feel it’s not worthwile or too hard to optimize here, I don’t mind.

on travis-ci.org it works the same way.

Indeed, I see from the history now. I guess I never noticed because of some timing differences and assumed the notifications I received about tags came from the “simple” build when Travis noticed that commit had a tag on it.

But I think it would be handy if there was a per-repo or global setting to switch off simple commit build if there is a tagged build from same commit.

I feel nobody would use it, because it wouldn’t give anything to users, only to Travis backend by saving some CPU. Unless you can do it automatically, it’s probably not worth it to bother at all.

5

I would use it. It would give me faster builds, since number of simultaneous runners is limited on travis-ci.

6

Building tags is not pointless in the general case:

  • A tag is not obliged to be on any specific branch, or be equal to any specific branch. E.g.
    • You can create a branch, tag a commit on it, delete it, and push.
    • Or tag a commit, make more commits to the branch, then push.
  • Tag provides additional input to the build. E.g. you can extract version information from the tag, deploy only on tags (this is a very common practice since tags usually mark releases), do some custom things depending on tag value (e.g. deploy to different environments) etc.

If you wish to not build tags for your project, exclude them with a build condition:

if: tag IS blank