New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a new environment variable which has the same value as `TRAVIS_BRANCH` or `TRAVIS_PULL_REQUEST_BRANCH` depending on the context #6652

Open
breerly opened this Issue Sep 29, 2016 · 19 comments

Comments

Projects
None yet
@breerly
Copy link

breerly commented Sep 29, 2016

The addition of $TRAVIS_PULL_REQUEST_BRANCH from #1633 is nice, but it is still a bit difficult to get the name of the current branch name from both PUSH and PR builds.

The current workaround I have is this, which is not great:

export BRANCH=$(if [ "$TRAVIS_PULL_REQUEST" == "false" ]; then echo $TRAVIS_BRANCH; else echo $TRAVIS_PULL_REQUEST_BRANCH; fi)

Instead of having users script this, I suggest adding an environment variable $TRAVIS_CURRENT_BRANCH.

@BanzaiMan

This comment has been minimized.

Copy link
Member

BanzaiMan commented Sep 29, 2016

What does "current" mean?

@breerly

This comment has been minimized.

@BanzaiMan

This comment has been minimized.

Copy link
Member

BanzaiMan commented Sep 30, 2016

Ah, I see. You want one environment variable that has different values depending on a push build or a PR build.

May I ask for the use case here?

@breerly

This comment has been minimized.

Copy link

breerly commented Sep 30, 2016

We're using this value to push containers to Docker Hub after success:

https://github.com/yarpc/yarpc-go/blob/dev/.travis.yml#L89

Currently we have the above workaround in place in about 10 repos.

Previously we were making requests to Github to resolve the current repo name:

yarpc/yarpc-go@cec5008#diff-354f30a63fb0907d4ad57269548329e3L95

@BanzaiMan BanzaiMan changed the title Env to get current branch name from push and pr build Add a new environment variable which has the same value as `TRAVIS_BRANCH` or `TRAVIS_PULL_REQUEST_BRANCH` Sep 30, 2016

@BanzaiMan BanzaiMan changed the title Add a new environment variable which has the same value as `TRAVIS_BRANCH` or `TRAVIS_PULL_REQUEST_BRANCH` Add a new environment variable which has the same value as `TRAVIS_BRANCH` or `TRAVIS_PULL_REQUEST_BRANCH` depending on the context Sep 30, 2016

@BanzaiMan

This comment has been minimized.

Copy link
Member

BanzaiMan commented Oct 3, 2016

You can get to the value you want without if statement:

${TRAVIS_PULL_REQUEST_BRANCH:-TRAVIS_BRANCH}

This is ${TRAVIS_PULL_REQUEST_BRANCH} if ${TRAVIS_PULL_REQUEST_BRANCH} is nonempty (when the current job is a PR build) and ${TRAVIS_BRANCH} if ${TRAVIS_PULL_REQUEST_BRANCH} is empty.

@breerly

This comment has been minimized.

Copy link

breerly commented Oct 3, 2016

That's still not great - I need the value multiple times, so it's either store that in a variable or duplicate it. This is something that should just be available without bash wizardry on the users behalf.

@tomaszguzialek

This comment has been minimized.

Copy link

tomaszguzialek commented Oct 23, 2016

For all those wondering why this line doesn't work for them (as it did not work for me). One dollar sign is missing. The correct version:

${TRAVIS_PULL_REQUEST_BRANCH:-$TRAVIS_BRANCH}

Thanks for that trick, @BanzaiMan

@mirague

This comment has been minimized.

Copy link

mirague commented Jan 27, 2017

It seems this was solved the way OP proposed in OndraM/ci-detector#17, what's your take on this @travis-ci?

l2fprod added a commit to IBM-Cloud/openwhisk-darkvisionapp that referenced this issue Feb 15, 2017

@derek-j

This comment has been minimized.

Copy link

derek-j commented Mar 9, 2017

In building our Travis CI/CD system, I pushed from a feature branch not master. This also fails when PUSHing can that be fixed. A Single variable specifying the branch being built should be used ie TRAVIS_BRANCH i don't see the purpose of ever giving it the tag name, when that can easily be retrieved.

@AronNovak AronNovak referenced this issue Mar 31, 2017

Closed

Video recording for WDIO [8h] #83

2 of 3 tasks complete
@mikerott

This comment has been minimized.

Copy link

mikerott commented May 27, 2017

My solution:

if [[ "${TRAVIS_EVENT_TYPE}" == "pull_request" ]]; then
    # We have to do some shinanigans to figure out what the source
    # branch is for this pull request.  Travis is not kindly giving
    # us an env var when it's a push to an already existing PR.
    echo "Running pull request build on Travis"
    repo_url=$(git config --get remote.origin.url)
    latestPRCommit=(${TRAVIS_COMMIT_RANGE//\.\.\./ })
    latestPRCommit=${latestPRCommit[1]}
    git clone ${repo_url} ${latestPRCommit}
    cd ${latestPRCommit}
    SOURCE_BRANCH=($(git branch -r --contains ${latestPRCommit}))
    export SOURCE_BRANCH=${SOURCE_BRANCH/origin\//}
    cd -
fi

The result is that $SOURCE_BRANCH now has the branch name of the branch that triggered the PR build when I pushed more commits to it. My product depends on branch name, so my CI build needs to know it, and that's how I got it. Yuck.

@breerly LOL at "bash wizardry".

@sanket4373

This comment has been minimized.

Copy link

sanket4373 commented Sep 8, 2017

@breerly @BanzaiMan : I followed your way of getting the name of the current PR branch still facing problems though. posting my question here.

I want to get the name of the created PR in the travis logs. I want to use this PR name to build containers for my service every single time the PR is created or updated . In this case I am updating my PR.

Posting the snippet of the travis build logs:

$ export BRANCH=$(if [ ${TRAVIS_PULL_REQUEST} = "false" ]; then echo $TRAVIS_BRANCH; else echo $TRAVIS_PULL_REQUEST_BRANCH; fi)

The command "export BRANCH=$(if [ ${TRAVIS_PULL_REQUEST} = "false" ]; then echo $TRAVIS_BRANCH; else echo $TRAVIS_PULL_REQUEST_BRANCH; fi)" exited with 0.
0.01s$ echo "TRAVIS_BRANCH=$TRAVIS_BRANCH", "BRANCH=$BRANCH", "TRAVIS_PULL_REQUEST_BRANCH=$TRAVIS_PULL_REQUEST_BRANCH";
TRAVIS_BRANCH=develop, BRANCH=, TRAVIS_PULL_REQUEST_BRANCH=

As you can seeTRAVIS_PULL_REQUEST_BRANCH shows empty output and TRAVIS_BRANCHshows the name of my base branch.

The variables are not behaving as expected, basically this should have happened as shown below:

   # You open a PR with base `master`, and PR branch `foo`
    # During a PR build:
    #     TRAVIS_BRANCH=master
    #     TRAVIS_PULL_REQUEST_BRANCH=foo
    # During a push build:
    #     TRAVIS_BRANCH=foo
    #     TRAVIS_PULL_REQUEST_BRANCH=

Can someone kindly help me point out If I am missing something in the way I am executing the command?

@sanket4373

This comment has been minimized.

Copy link

sanket4373 commented Sep 14, 2017

Had to do a workaround on this to get the HEAD of the branch since even git branch was not helping to give the name of the origin branch.

git fetch origin refs/pull/"$TRAVIS_PULL_REQUEST"/head:"$TRAVIS_PULL_REQUEST"
git checkout "$TRAVIS_PULL_REQUEST"

This way got the HEAD of the branch and used it to build my container.

@StoneCypher

This comment has been minimized.

Copy link

StoneCypher commented Sep 28, 2017

@BanzaiMan - okay, so, this gets us the branch name

What about the repo name? If I make a PR from my fork, the branch doesn't exist on master. It needs to ask for accountname:branchname, rather than just branchname

ajmazurie added a commit to starlingtrust/docker-probe that referenced this issue Dec 10, 2017

ajmazurie added a commit to starlingtrust/docker-probe that referenced this issue Dec 10, 2017

ajmazurie added a commit to starlingtrust/docker-probe that referenced this issue Dec 10, 2017

@stale

This comment has been minimized.

Copy link

stale bot commented Apr 13, 2018

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

@stale stale bot added the stale label Apr 13, 2018

@stale stale bot closed this Apr 16, 2018

@StoneCypher

This comment has been minimized.

Copy link

StoneCypher commented Apr 17, 2018

@BanzaiMan - I don't know if I feel safe at Travis if you've decided to throw away your backlog without fixing it

Timple added a commit to tue-robotics/tue-env that referenced this issue Apr 25, 2018

Fix ci in case of PR
TRAVIS_BRANCH implies target branch instead of source branch causing CI
to fail if dependencies changed.

Solution found in this thread:
travis-ci/travis-ci#6652
@mraible

This comment has been minimized.

Copy link

mraible commented Apr 27, 2018

I'm using this in my .travis.yml.

  - export BRANCH=$(if [ "$TRAVIS_PULL_REQUEST" == "false" ]; then echo $TRAVIS_BRANCH; else echo $TRAVIS_PULL_REQUEST_BRANCH; fi)
  - echo "TRAVIS_BRANCH=$TRAVIS_BRANCH, PR=$TRAVIS_PULL_REQUEST, BRANCH=$BRANCH"

It worked great until I did a release.

export IONIC4J_REPO=https://github.com/oktadeveloper/generator-jhipster-ionic.git
export IONIC4J_BRANCH=$BRANCH
...
git clone $IONIC4J_REPO generator-jhipster-ionic
Cloning into 'generator-jhipster-ionic'...
remote: Counting objects: 859, done.
remote: Compressing objects: 100% (49/49), done.
remote: Total 859 (delta 16), reused 51 (delta 12), pack-reused 793
Receiving objects: 100% (859/859), 358.18 KiB | 3.94 MiB/s, done.
Resolving deltas: 100% (338/338), done.
cd generator-jhipster-ionic
if [ "$IONIC4J_BRANCH" == "latest" ]; then
    LATEST=$(git describe --abbrev=0)
    git checkout -b $LATEST $LATEST
elif [ "$IONIC4J_BRANCH" != "master" ]; then
    git checkout -b $IONIC4J_BRANCH origin/$IONIC4J_BRANCH
fi
fatal: 'origin/v3.2.0' is not a commit and a branch 'v3.2.0' cannot be created from it

Sorry for commenting on a closed ticket, but how do I adjust the script so this failure doesn't happen?

@BanzaiMan BanzaiMan reopened this Apr 27, 2018

@stale stale bot removed the stale label Apr 27, 2018

@StoneCypher

This comment has been minimized.

Copy link

StoneCypher commented Apr 27, 2018

@BanzaiMan - quite a few other valid tickets were also closed by this bot

lmakarov added a commit to docksal/docksal that referenced this issue May 15, 2018

achekulaev added a commit to docksal/docksal that referenced this issue May 15, 2018

fin 1.56.0. persistent volume for $HOME for run-cli (#532)
* fin 1.56.0. persistent volume for $HOME for run-cli

1. [BREAKING] Image and debug are now options for run-cli (--image=..., --debug)
2. [BREAKING] Persistent $HOME directory by default

* Tests fix

* Fix TravisCI tests for PRs

See travis-ci/travis-ci#6652

nelsonic added a commit to nelsonic/hello-world-node-http-server that referenced this issue May 28, 2018

@lmakarov lmakarov referenced this issue May 31, 2018

Merged

Release 1.9.0 #575

@BenCoffeed

This comment has been minimized.

Copy link

BenCoffeed commented Jul 2, 2018

I'm using an after_success command to call my AWX cluster to build code and ship the artifact to s3. I've used @mikerott 's workaround solution. However, it would be REALLY handy for scenarios such as this to have an origin slug / fork name and an origin branch name for PR's. Especially for changes pushed to existing PR's.

ksens added a commit to Paradigm4/revealgenomics-docs that referenced this issue Jul 5, 2018

ksens added a commit to Paradigm4/revealgenomics that referenced this issue Jul 5, 2018

ksens added a commit to Paradigm4/revealgenomics that referenced this issue Jul 26, 2018

ksens added a commit to Paradigm4/revealgenomics-docs that referenced this issue Jul 26, 2018

ben-farnham added a commit to quasar-team/CanModule that referenced this issue Jul 31, 2018

ben-farnham added a commit to quasar-team/CanModule that referenced this issue Jul 31, 2018

Fix travis build v2 (#10)
* Added yml file for travis, plus boost toolchain file (uses system boost)

* link against socketcan shared library

because we're building the implementation lib with -fPIC, however, the system static library is not built with -fPIC (and therefore fails to link on travis CI build node).

* fix the build for PRs (was always using master)

See comments on this travis-ci ticket
travis-ci/travis-ci#6652
@augsteyer

This comment has been minimized.

Copy link

augsteyer commented Sep 13, 2018

Sorry for commenting on a closed ticket, but how do I adjust the script so this failure doesn't happen?

@mraible I think the solutions mentioned are forgetting that there is also another name a $TRAVIS_BRANCH can have.
From the docs:

TRAVIS_BRANCH:
for push builds, or builds not triggered by a pull request, this is the name of the branch.
for builds triggered by a pull request this is the name of the branch targeted by the pull request.
for builds triggered by a tag, this is the same as the name of the tag (TRAVIS_TAG).

So you are hitting the $TRAVIS_TAG issue where you tagging a repo produces a build. The solution above will also need to include this in the calculation, logically it will looks like this (psudo code):

if ($TRAVIS_EVENT_TYPE === 'pull_request') {
 $branch = $TRAVIS_PULL_REQUEST_BRANCH;
} elseif ($TRAVIS_TAG) {
  $tag = $TRAVIS_BRANCH; //handle tag commits
} else {
 $branch =  $TRAVIS_BRANCH;
}

Then you can just checkout the tag git checkout tags/$tag -b $tag

zabrador added a commit to scat-chat/scat-chat-api that referenced this issue Nov 11, 2018

Add continuous deployment to Travis configuration
This requires a bit more work than you'd think. We first need to first
add gigalixir as a remote to our CI environment, which accesses keys
that need to be defined in Travis.

Travis also exposes the branch name in a bit of an indirect way. The
short version is that we need to use `TRAVIS_PULL_REQUEST_BRANCH` by
default, and fall back to `TRAVIS_BRANCH` if it's not defined. See here
for more details:

travis-ci/travis-ci#6652

Lastly we run our tests as usual, immediately followed by a deploy if
we have determined that we're on `master`.

zabrador added a commit to scat-chat/scat-chat-api that referenced this issue Nov 11, 2018

Add continuous deployment to Travis configuration
This requires a bit more work than you'd think. We first need to first
add gigalixir as a remote to our CI environment, which accesses keys
that need to be defined in Travis.

Travis also exposes the branch name in a bit of an indirect way. The
short version is that we need to use `TRAVIS_PULL_REQUEST_BRANCH` by
default, and fall back to `TRAVIS_BRANCH` if it's not defined. See here
for more details:

travis-ci/travis-ci#6652

Lastly we run our tests as usual, immediately followed by a deploy if
we have determined that we're on `master`.

papandreou added a commit to unexpectedjs/unexpected that referenced this issue Jan 6, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment