CODEWITHSUNDEEP
travis-ci
setevoy
setevoy

Reputation: 4662

Travis: different `script` for different branch?

I'd like to setup deployment based on branches using Travis-CI and Github.

I.e. - if we made build from develop - then exec /deploy.rb with DEV env hostname, if master - then ./deploy.rb with PROD hostname and so on.

Only one idea I found - is to check $TRAVIS_BRANC variable and then execute script, like:

language: php
install:
  - true
script:
  - test $TRAVIS_BRANCH = "develop" && ./ci/deploy.rb envdev.tld 
  - test $TRAVIS_BRANCH = "master" && ./ci/deploy.rb envprod.tld

But this solution looks a bit weird as for me. Any other possibilities to realize that?

Any tips/links appreciated.

Upvotes: 26

Views: 8798

Answers (3)

xji
xji

Reputation: 8237

Seems that the best solution now is to use stages. You can have something like:

stages:
  - name: deploy
    # require the branch name to be master (note for PRs this is the base branch name)
    if: branch = master

See Travis documentation for more detail regarding stages.

Upvotes: 2

George43g
George43g

Reputation: 623

I think this is a much better solution because it's so simple.

Let's say you have a dedicated production branch (master) and a staging/testing branch (dev).

In your TravisCI account, you can set environment variables. You can choose to have certain variables only available for specified branches.

So, for example, in your .travis.yml, you write: firebase deploy --project "$DEPLOY_TARGET"

And set DEPLOY_TARGET (no dollar sign preceding var needed in the web config area!) as a different environment variable for each branch. Although that specific example works for firebase hosting, you could generalise the example with a script to act based on the branch env vars.

So you could set $BRANCH_SPECIFIC_VAR as an environment variable and specify each branch that you need, and then access that variable from your config file.

I hope this helps.

Upvotes: 0

Holger Just
Holger Just

Reputation: 55718

Travis-CI always creates builds based on the .travis.yml in the branch you are pushing. As a solution, you could thus maintain different .travis.yml files in the different branches.

If you regularly merge between the branches, this could however lead to inadvertent changes between the branches (if you merge the changes of the .travis.yml of one branch over to the other). If this is a concern, your solution is probably safer.

To ensure that only specific branches (e.g. develop and master) are built, you can whitelist the branches in your .travis.yml.

When using your existing solution, you could simplify your travis.yml script though. It probably makes sense to move the logic for selecting the correct deploy target into your ci/deploy.rb script (or even add a separate wrapper script which you call from the .travis.yml). That way, you have only one script line in your .travis.yml which don't even needs to change if you change deployment targets.

Alternatively, to ensure you have no failing tests with your existing structure, you could even use something like this:

script:
  - if [ "$TRAVIS_BRANCH" = "develop" ]; then ./ci/deploy.rb envdev.tld; fi
  - if [ "$TRAVIS_BRANCH" = "master" ]; then ./ci/deploy.rb envprod.tld; fi

Upvotes: 26

Related Questions