rakitin
rakitin

Reputation: 2185

Travis CI: How to conditionally run provider deployment jobs?

I have a travis script deploying to different S3 buckets based on 2 conditions: 1. the branch name 2. the $TRAVIS_BRANCH env variable

... travis stuff
deploy:
  - provider: s3
    ... other config
    bucket: my-staging-bucket
    on:
      repo: MyOrg/my-repo
      branch: staging
      condition: $TRAVIS_BRANCH = staging
  - provider: s3
    ... other config
    bucket: my-prod-bucket
    on:
      repo: MyOrg/my-repo
      branch: production
      condition: $TRAVIS_BRANCH = production

It's working as expected: When I deploy to staging, the first config successfully builds and deploys and I'm given appropriate messaging in Travis' job log.

It also tries to deploy to production and is stopped by the on: conditions, again providing messaging that indicates as much. The resulting log messages look like so, the first two lines indicating successful depoyment to staging and no deployment to production.

-Preparing deploy
-Deploying application
-Skipping a deployment with the s3 provider because a custom condition was not met

This is consistent when the situation is reversed:

-Skipping a deployment with the s3 provider because this branch is not permitted: production
-Skipping a deployment with the s3 provider because a custom condition was not met
...
-Preparing deploy
-Deploying application

This has lead to some confusion amonst the team as the messaging appears to be a false negative, indicating the deployment failed when it's actually functioning as intended. What I would like do is set up Travis so that it only runs the deployment script approprite for that branch and env variable combo.
Is there a way to do that? I was under the impression this was the method for conditional deployment.

If there's no way to prevent both deploy jobs from running, is there a way to at suppress the messaging in the job log?

Upvotes: 0

Views: 2289

Answers (1)

Danny Smith
Danny Smith

Reputation: 1046

The best way to do this would be to use Travis' stages and jobs features. Stages are groups of jobs. Jobs inside stages run in parallel. Stages run in sequence, one after the other. Entire stages can be conditional, and stages can also contain conditional jobs. Jobs in a stage can be deploy jobs too (i.e. the entire deploy: in your travis.yml can be nested inside a conditional stage. Most importantly for your goals, conditional stages and their included jobs are silently skipped if the condition is not met.

This is very different to the standard deploy: matrix that you already have. i.e. your current deploy step contains 2 deployments and so you get the message that it is skipping a deployment.

Instead, you can change that into separate deploy stages with conditional jobs.

The downside to using stages like this is that each stage runs in its own VM and so you can't share data from one stage to the next. (i.e build artifacts from previous stages do not propagate to subsequent stages). You can get around this by sharing the build results of a lengthy compile stage via S3, for example.

More information can be found here: https://docs.travis-ci.com/user/build-stages

I have a working example here in my github: https://github.com/brianonn/travis-test

jobs:
  include:
    - stage: compile
      script: bash scripts/compile.sh

    - stage: test
      script: bash scripts/test.sh

    - stage: deploy-staging
      if: branch = staging
      name: "Deploy to staging S3"
      script: skip
      deploy:
        provider: script
        script: bash scripts/deploy.sh staging
        on:
          branch: staging
          condition: $TRAVIS_BRANCH = staging

    - stage: deploy-prod
      if: branch = production
      name: "Deploy to production S3"
      script: skip
      deploy:
        provider: script
        script: bash scripts/deploy.sh production
        on:
          branch: production
          condition: $TRAVIS_BRANCH = production

This produces a Travis job log that is specific to each one of staging and production:

push to staging branch push to production branch

Upvotes: 5

Related Questions