We’re hitting a problem on the AMP project, where Travis jobs in multiple stages appear to be using the same merge commit (and same commit log) even though origin/master has moved forward.
Would it be possible to expose the commit SHA of origin/master at the start of the first stage of a Travis build via an environment variable, so that it can be used by subsequent stages to establish which files have changed by a pull request? This will allow us to not have to rely on the real origin/master , which is a moving target.
I don’t see what the problem is. What are you trying to achieve?
origin/master is a live repository, nothing prevents it from being altered at any moment – including between the times different jobs run. Travis makes sure as best it can that the same commit is being checked out at every job of the same build – that’s all that matters for the purpose of building stuff.
If you wish to use origin/master commit to label the build or something – too bad for you, that’s not a guarantee you can get. Find a better indicator – like the current commit (available as $TRAVIS_COMMIT) for example which is the standard way to mark non-tag builds for Git-based projects.
In fact, since origin/master lives its own life from the current commit, it’s completely useless as a label. There’s no telling where it will be by the time a build runs and how it will be related to the current commit by that time.
In the screenshot above (from this build), I’m looking for a way to determine that 247d7e2 is the latest commit merged to master that is part of the PR build. If origin/master moves forward by the time a subsequent stage begins, I still want to be able to figure out that 247d7e2 was the latest merged commit that’s part of the Travis build. (We use this info to determine which files were changed by the pull request, and therefore, which tests need to be run during the Travis build)
