How to deploy only on PR merged to master

Travis CI Discussions & Feedback
1

How do I configure my .travis.yaml to deploy only on a successful PR merge to master?

This is my current .travis.yaml:

language: node_js
node_js:
  - 14
cache:
  yarn: true
  directories:
    - node_modules
    - .next/cache
jobs:
  include :
    - stage: "Build 🛠️"
      script: yarn cp-env:qa && yarn build
    - stage: "Deploy 🚀"
      if: branch = master
      script : yarn deploy-qa

But every time I open a new PR on a branch → master, both the “Build :hammer_and_wrench:” and “Deploy :rocket:” stages run. I want only the “Build :hammer_and_wrench:” to run on a new PR, and then to have the “Deploy :rocket:” stage run once the PR’s been merged to master.

How can I accomplish this?

2

You could have a tag created when a successful merge into master is completed, then when a tag is created on master, have another build start running a deploy only.

What you’re likely looking for here is a ‘Conditional Job’. Using the example here: Build Stages: Matrix expansion - Travis CI

2 Likes
3

Yup… I ended up solving this in this way:

jobs:
  include :
    - stage: build
      name: "PR Build 🛠️"
      before_script : echo "build_branch => $TRAVIS_BRANCH" && yarn cp-env:qa && yarn lint && yarn prettier-check
      script: yarn build
      if : type = pull_request

    - stage: deploy
      name: "Build & Deploy to QA 🚀"
      before_script : export NODE_ENV=production && yarn cp-env:qa && yarn lint && yarn prettier-check && yarn build && firebase functions:config:set api.root_url='https://qa.web.app' && firebase functions:config:set algolia.app_id=$ALGOLIA_QA_APP_ID algolia.api_key=$ALGOLIA_QA_API_KEY
      script : travis_wait firebase --token $FIREBASE_TOKEN --non-interactive deploy --only functions,hosting:app-qa
      if : branch = master AND type = push

Unfortunately, I couldn’t find a way to just reuse the previous build result, so had to mash both the build steps and the deploy into one job :confused:

4

I’m glad my solution/work around worked for you @RavenHursT. I’ll bring this up internally and see if there’s something that can be done.

The thought process being (in this hypothetical), let’s say if you are using AWS, there’s not a great reason why you need a PR to accomplish this. In any event, the deployment is going to require say for this example of using AWS, at least S3 credentials somewhere, and allowing any PR to do it (or say in your script) is going to incur a security risk.

Let me look into this further and see if I can get a better solution than my workaround solution.

Montana Mendy
Travis CI Staff

2 Likes