Is it possible to use specific OSs with specific branches in Travis CI?
I would like to configure Travis to build master using OSX and Linux, and to build other branches just using Linux.
The reason being that queue times for OSX are quite long (> 20m), which impacts the feedback loop when fixing bugs in the projects I work on.
Any help would be appreciated. Thank you.
This is my current yml config file:
language: node_js
node_js:
- 6
before_install:
npm run uninstall && npm cache clean --force
install:
npm install
branches:
only:
- master
- develop
- travis-ci
os:
- linux
- osx
You probably want to look into Build stages, in particular its capability to define conditions on things like branch name.
This is an example of how to achieve this, with (arguably) the added benefit that the macos stage will not even run if the test stage does not finish successfully:
language: node_js
node_js: 6
before_install:
npm run uninstall && npm cache clean --force
install:
npm install
branches:
only:
- master
- develop
- travis-ci
stages:
- test
- macos
jobs:
include:
- stage: test
- stage: macos
if: branch = master
os: osx
Related
I'm trying to set up a pipeline in Bitbucket with a daily schedule for two branches.
develop : There a scheduled daily deployment running + when I push to this branch the pipeline runs again
master : This is the tricky one. I want to have a daily deployment because the page need to be rebuild daily, but I would like to have a security that if anyone pushes to this branch by mistake or the code is bad, it only runs the deployment after a manual trigger.
So my question is that is it possible to set up a rule to track if there was a push and in this case let the admin manually start the pipeline ?
pipelines:
branches:
develop:
- step:
name: Deploy staging
deployment: staging
caches:
- node
script:
- npm run staging:auto
- npm install firebase
- npm install firebase-functions
- npm install -g firebase-tools
- firebase deploy --token=$FIREBASE_TOKEN --project $FIREBASE_PROJECT_STAGING --only functions,hosting
artifacts:
- build/**
master:
- step:
name: Deploy to production
deployment: production
caches:
- node
script:
- npm run deploy:auto
- npm install firebase
- npm install firebase-functions
- npm install -g firebase-tools
- firebase deploy --token=$FIREBASE_TOKEN_STAGING --project $FIREBASE_PROJECT_PRODUCTION --only functions,hosting
artifacts:
- build/** ```
I'd suggest to schedule a different custom pipeline other than the one that runs on pushes to the production branch. The same steps definition can be reused with a yaml anchor and you can replace the trigger in one of them.
E.g:
definitions:
# write whatever is meaningful to you,
# just avoid "caches" or "services" or
# anything bitbucket-pipelines could expect
yaml-anchors:
- &deploy-pro-step
name: Deploy production
trigger: manual
deployment: production
script:
- do your thing
pipelines:
custom:
deploy-pro-scheduled:
- step:
<<: *deploy-pro-step
trigger: automatic
branches:
release/production:
- step: *deploy-pro-step
Sorry if I make some yaml mistakes, but this should be the general idea. The branch where the scheduled custom pipeline will run is configured in the web interface when the schedule is set up.
If I:
run a build in travis, and
tests pass correctly, but
there is some problem uploading coverage results to codecov,
...Travis goes ahead and deploys anyway. How can I stop travis from deploying in this case?
The deploy-regardless-of-upload-failure:
.
Here's my .travis.yml:
dist: trusty
language: python
python:
- '3.6'
# Install tox and codecov
install:
- pip install tox-travis
- pip install codecov
# Use tox to run tests in the matrix of environments
script:
- tox -r
# Push the results back to codecov
after_success:
- codecov --commit=$TRAVIS_COMMIT"
# Deploy updates on master to pypi, which will only succeed if there's been a version bump
deploy:
provider: pypi
skip_cleanup: true
skip_existing: true
user: me
password:
secure: "stuff"
on:
branch: master
According to this https://bitbucket.org/ned/coveragepy/issues/139/easy-check-for-a-certain-coverage-in-tests, if you add the --fail-under switch to the coverage report command, it will exit with a non-zero exit code (which travis will see as a failure) if the code coverage is below the given percentage.
That would make the script section of your .travis.yml file look like:
script
- coverage run --source="mytestmodule" setup.py test
- coverage report --fail-under=80
Of course you could replace 80 with whatever percentage you'd like.
I'm trying to create two different actions within travis.ci. The first action is to execute a script on every push on every branch. This is currently working as desired. The second is to trigger a different script only when git push origin --tags. In short:
Execute script1 always (currently working)
Execute script2 when tags are pushed
Here is what I'm trying:
language: python
python:
- 3.7
matrix:
include:
- python: 3.7
sudo: true
install:
- pip install -r requirements.txt
script: # Always want this to happen
- invoke package
branches:
only:
- master
- /^x\/.*/
deploy: # Want this to occur on git push origin --tags
provider: script
script: invoke release
on:
tags: true
The deploy section is not being triggered, and I can find no evidence of the invoke release script being invoked.
Update:
It may be due to the way I'm pushing tags..? I'm seeing this log in travis now:
Skipping a deployment with the script provider because this is not a tagged commit
Solved it from this github issue. Changed the deploy section to this:
deploy:
provider: script
script: invoke release
on:
tags: true
all_branches: true
but had to remove the branches section. Deployment script was invoked, nonetheless.
We are wondering whether there is any way to add filters to Travis matrix items. In our particular case, we wish to run certain jobs only on specific branches.
The following example would be an ideal way for configuring this scenario, however it doesn't seem to work:
matrix:
include:
- env: BUILD_TYPE=release
branches:
only:
- master
- env: BUILD_TYPE=ci
branches:
only:
- develop
As a workaround, we can exit from the build script immediately by checking the appropriate env vars (TRAVIS_BRANCH), but it is very far from ideal as launching the slave machine and cloning the repo takes a considerable amount of time.
You can now achieve this with the beta feature Conditional Build Stages
jobs:
include:
- stage: release
if: branch = master
env: BUILD_TYPE=release
- stage: ci
if: branch = develop
env: BUILD_TYPE=ci
I test on three different Node versions (mainly to alert me to any compatibility issues that might arise if I was forced to switch to another version in production):
sudo: false
language: node_js
node_js:
- iojs
- '0.12'
- '0.10'
deploy:
skip_cleanup: true
provider: script
script: ./deploy.sh
on:
branch: master
matrix:
allow_failures:
- node_js: iojs
But that means my ./deploy.sh script is run three times, from three different containers! I obviously only want one of the successful builds to be deployed. The other builds are just for catching Node issues.
Is there a way to configure it so it only runs my deploy script after one of the jobs? Maybe another setting under on:?
The docs for script provider don't cover this.
What about setting a node: '0.10' option under on:? Like so:
deploy:
skip_cleanup: true
provider: script
script: ./deploy.sh
on:
branch: master
node: '0.10'
This should run the deploy job only on the node: '0.10' target.
From the Travis Deployment official docs:
jdk, node, perl, php, python, ruby, scala, go: For language runtimes
that support multiple versions, you can limit the deployment to happen
only on the job that matches the desired version.
You could try using a conditional release.