Using corporate Travis for private github repos, we use tags to trigger builds to certain environments.
For example, let’s say we have commits on master triggering a deploy to a dev environment, and certain tags trigger deploy to staging environment, etc.
However, recently a number of times we’ve seen that Travis hasn’t picked up tags. Builds aren’t started for the tags, hence no deploy is made to the corresponding environment.
Let’s say I’ve done a npm version patch and pushed that to origin. Travis picks up the new commit on master and makes a build for that (which is deployed to dev), and usually also makes a build for the tag, e.g. v1.3.12 which is deployed to staging. However, sometimes the tag build just isn’t triggered.
Today when this happened I tried using “trigger custom build”, and I then noticed that in the branch selector, my new tag is not even available. Older tags such as v1.3.10 and v1.3.11 are shown though. So it’s like Travis isn’t even aware about there being a new tag on the repo.
Is this a known issue?
My workaround is usually to create yet another version tag, but it’s less than reliable that we can’t trust Travis to always deploy what we tag, and sometimes we’ve even missed the fact that a deploy was never made for a few days.
So from Git’s point of view when using a tag it’s kind of like a branch. So let’s say you have something like the branches: only:, this would (from my understanding) apply to the tags as well.
Without seeing a .travis.yml it’s hard for me to speculate, but It’ll likely be more convenient to use a compound build condition instead of `branches, so for example:
deploy:
- provider: script
script: npm run deploy:dev
skip_cleanup: true
on:
branch: master
- provider: script
script: npm run deploy:prod
skip_cleanup: true
on:
tags: true
Thing is, this has worked for 5+ years, and still works - 99%-ish of the time! But that 1% can be fatal, and it started happening just recently.
This morning it happened again, and just like last time, when I try to trigger a manual build, the tag v1.3.15 is not recognized by Travis CI, although that tag is pushed upstream and can be seen as a release also in GitHub. Only by making yet another tag v1.3.16 am I able to get Travis CI to pick up the build. Note that after making a second tag, Travis CI’s “trigger manual build” is now aware of v1.3.16 but still not about v1.3.15.
Do you see any reason why using a compund build condition instead of my current setup would resolve a problem where tags are generally picked up OK but sometimes not? Personally I’d think the problem is more likely to be due to some bug in Travis, missing a hook call from GitHub hence not knowing about the tag existing, and then not syncing/fetching tags manually at any time either to pick up on hook calls that may have been lost.
Because a) the tag does exist in the git repo b) it works most of the time but fails only occasionally - why would using another syntax for the build condition fix such an intermittent problem?
The required parameter tag_name is derived from $TRAVIS_TAG (or git describe --tags --exact-match if this is undefined). At least, this is the design. If you managed to override it, then it might be a bug. I’ve put in a note internally, have you tried doing:
- provider: script
script: npm run deploy:prod
skip_cleanup: true
on:
all_branches: true
tags: true
If so, I will add this to my config and see if it helps.
However, I found something interesting today. I went back to one of my repos that had this problem a few months ago, and noticed that v1.3.15 which had been ignored had then been built 14 days after v1.3.16 (which was created simply to force-trigger a build due to v1.3.15 not being picked up). So, build #556 was built on June 4 for v1.3.16, and then #567 was built on June 18 for v1.3.15. Both jobs took 4 minutes, so it was not that it started but never finished or anything like that - the job for the older tag was started 2 weeks after the tag was created, and after several consecutive tags had been built immediately. So to me this indicates that something triggered Travis 2 weeks later to pick up a tag that had previously been overlooked?
The above advice did not work, and in fact, today I encountered this problem happening not only for a tagged build but for an ordinary commit to master.
The PR was merged, the commit is on master in GitHub but 1.5 hours later there’s no trace of any job in Travis for that commit.
Is there any attention on this bug, as it’s really deceptive, only happening sometimes, but with severe consequences - it seems we simply cannot rely on Travis as we used to?
