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.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:
if: branch = master OR tag IS present
Please also read: Customizing the Build - Travis CI
- provider: script
script: npm run deploy:dev
- provider: script
script: npm run deploy:prod
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?
Let me look at some of this more in-depth in our logs and see if where the hiccup is.