The perfect place to leave feedback and comments on newly released Beta Features.
Earlier this year we dark shipped a new feature for running scheduled builds for repositories, which we called Crons.
This feature was developed with the help from some amazing students at HPI University in Potsdam, Germany.
You can find current, and up to date docs for Crons here: https://docs.travis-ci.com/user/cron-jobs/
This feature is going into General Availability on the 6th of December.
Please leave all feedback related to this feature here as comments.
UPDATE: 2017-01-20
I wanted to give a quick update that I'll being going through all the feedback shortly and provide some information on when this will come out of Beta and what improvements we have lined up.
Thank you everyone for your feedback!
UPDATE: 2017-02-02
Thanks a lot for your feedback everyone!
I am adding each of the suggested changes below for votes.
Once we have gathered votes over a few weeks, we will decide which of these can be implemented earliest to be able to get Crons out of Beta.
UPDATE: 2017-03-02
We have started working on fixing and improving some things to move Crons out of Beta, details here.
Hello!
This isn’t the place for feature requests or bug reports. If that’s what you’ve come here for, please either visit our public bug tracker or send us an email at [email protected].
Otherwise, go ahead and delete this text 😬
Hello!
This isn’t the place for feature requests or bug reports. If that’s what you’ve come here for, please either visit our public bug tracker or send us an email at [email protected].
Otherwise, go ahead and delete this text 😬
When @lislis joined, we started planning an updated UI which would help users focus on the Repositories which they care most about.
This is especially useful for teams which have a growing number of Repositories testing on Travis. Additionally, it brings consistency to our UI when viewing Builds across various screen sizes.
We have further iterations of this feature in planning, but we want to hear from you on what works well, what needs improvement, and what could be removed.
This feature will be available for users to opt-in to from the 28th of February.
Please leave all feedback related to this feature here as comments.
I can understand how build stage is current designed. It's just not intuitive. the structure suggests that one stage can only contain one script, and if you want more than one scripts in one stage, you need to define a new script following current stage, whilst it should be defined within the stage, isn't it?
would below configuration makes more sense?
job:
stage:
- name: stage1
jobs:
- script 1
- script 2
- name: stage2
jobs:
- script 3
- script 4Not so much a bug or feature request as more something for discussion. I noticed after switching to multiple jobs. When I look at the build history. The time seemed rather excessive. I thought it was making the builds take longer. Instead its showing a total of all build times combined. Which I guess makes sense as to total build time. But I think it makes more sense for like an average, or to display the max time from any one. Given that they all run together, the actual time is really no longer than the time of the longest one. Or the time to run all stages, which still seems less than time of all combined.
Example history, pretty easy to see without any other information other than build times when I switched to multiple jobs.
https://travis-ci.org/Obsidian-StudiosInc/entrance/builds
I have no preference really either way just feedback. At first I thought something might be off.
Hello!
This isn’t the place for feature requests or bug reports. If that’s what you’ve come here for, please either visit the Travis CI community forum or send us an email at [email protected].
Otherwise, go ahead and delete this text 😬
Thank you!
This is about the beta feature Conditional Builds, Stages, and Jobs.
I have conditional jobs setup in my build matrix like (travis.yml)
matrix:
include:
- os: linux
env: BUILDTYPE=Debug
- os: linux
env: BUILDTYPE=Release
if: (branch = master AND NOT type = pull_request) OR tag IS present
That works fine with what I try to accomplish:
Release type builds for
master branch (but not for PR's against master!)Problem is that I want to prevent Debug builds for tags in return.
I tried with what the documentation gives me, but it did not work.
All of this if: statements still created a Debug job:
- os: linux
env: BUILDTYPE=Debug
if: tag IS blank
- os: linux
env: BUILDTYPE=Debug
if: tag IS NOT present
- os: linux
env: BUILDTYPE=Debug
if: tag NOT present
Also, using env(TRAVIS_TAG) instead tag didn't help.
Any suggestions? Did I run into an issue/bug?
It's confusing because tag IS present seems to work for my configuration for Release as shown above.
Hello!
This isn’t the place for feature requests or bug reports. If that’s what you’ve come here for, please either visit the Travis CI community forum or send us an email at [email protected].
Otherwise, go ahead and delete this text 😬
Thank you!
Hello!
This isn’t the place for feature requests or bug reports. If that’s what you’ve come here for, please either visit our public bug tracker or send us an email at [email protected].
Otherwise, go ahead and delete this text 😬
Hi
The doc states the following :
jobs:
include:
- script: ./test 1 # uses the default stage name "test"
- script: ./test 2
- stage: deploy
script: ./deploy target-1
- script: ./deploy target-2
When applying this to my case it was not working. See travis-ci/travis-ci#7846
The error came from a matrix.include usage. The configuration section should mention what are the constraints.
Many of our front-end Capybara tests fail randomly but will pass upon retry builds.
Although we will work to improve our tests so this doesn't happen, it would be great if we could have a way to request auto-retry builds n number of times.
#So I am running Travis-CI with the beta stages feature and its been working well except recently. I made a change to add in that the job that runs our deploys can also work when we run a cron job once a week since it deploys our site which should always be ready to deploy.
So I made the following change (and a follow-up commit just to fix the spacing of course):
acceptbitcoincash/acceptbitcoincash@0d4bf19#diff-354f30a63fb0907d4ad57269548329e3L41
It worked well when I had set up my cron job and I was happy to get the 4-25-2018 tagged docker container that appeared here: https://hub.docker.com/r/acceptbitcoincash/acceptbitcoincash/tags/
Today I went to tag the repository, which under normal circumstances will force a build of the docker container and then a tag of the current date, and deploy to docker hub.
The tag build started but then failed to identify that variable should change. Okay, my fault I thought. So I went ahead and fixed it to force it to go into the path I wanted.
Well, that did not work. Instead, I got the following message with my build:
https://travis-ci.org/acceptbitcoincash/acceptbitcoincash/jobs/373285943#L704
What is not permitted about? My only condition for that deploy to go is that its got that variable changed. That was most certainly the case on my four attempts where I got variations of that message.
From simple deployment pipelines, to complex testing groups, the world is your CI and CD oyster with Build Stages.
Build Stages allows you and your team to compose groups of Jobs which are only started once the previous Stage has finished.
You can mix Linux and Mac VMs together, or split them into different Stages. Since each Stage is configurable, there are endless Build pipeline possibilities!
This feature will be available for general beta testing soon... watch this space 😄
We love to hear feedback, it's the best way for us to improve and shape Travis CI. Please leave all thoughts/comments/ideas related to this feature here.
Happy Testing!
The issue (#11) this links to was just locked 🤔
So please fix my logs with that or Courier/Courier New.
Is would be interesting if we could star other people's repositories in order to follow builds of repositories I care about on a single Dashboard, instead of having to navigate to other people's pages
When using Build Stages, given the following config:
sudo: false
language: python
python:
- 2.7
- 3.4
- 3.5
- 3.6
- pypy
- pypy3
install:
- pip install awscli
- pip install -r requires/testing.txt
- python setup.py develop
stages:
- test
- name: upload_coverage
if: branch = master
- name: deploy
if: tag IS present
script: nosetests
jobs:
include:
- stage: test
services:
- postgres
script: nosetestsFor the test stage there are 2 jobs created for Python 2.7. So for stage "Test" I will see:
You can see this in two different projects:
i can forsee scalability issues if one has say 10,000+ repos while making the /hooks api-call. maybe something like
https://api.travis-ci.org/hooks?limit=100&offset=9000
would alleviate this problem?
Hello!
This isn’t the place for feature requests or bug reports. If that’s what you’ve come here for, please either visit our public bug tracker or send us an email at [email protected].
Otherwise, go ahead and delete this text 😬
Hello!
This isn’t the place for feature requests or bug reports. If that’s what you’ve come here for, please either visit our public bug tracker or send us an email at [email protected].
Otherwise, go ahead and delete this text 😬
There was mention of a beta feature in the readme of a project that addressed travis-ci/travis-ci#964 - https://github.com/grosser/travis_dedup/blob/master/Readme.md
Is that still true and if so are there any docs on the feature (in beta)?
How do I configure a staged build so that some jobs are Allowed Failures and, if they're not the last stage, won't prevent the next one from starting? The usual approach e.g. https://github.com/Pr0methean/BetterRandom/blob/47ede77295f9d4c094218d9dc9f05759cae312b8/.travis.yml doesn't seem to work (at least, no jobs are displayed under an Allowed Failures heading, even though each job has one).
Hello!
This isn’t the place for feature requests or bug reports. If that’s what you’ve come here for, please either visit our public bug tracker or send us an email at [email protected].
Otherwise, go ahead and delete this text 😬
Folks who took a close look at our docs may have already discovered the Trigger Build API.
It has already been present in our previous v2 API and is of course also present in the current v3 API.
Now we have the this functionality also available in our web client.
Read our blog post for more information.
If you have any feedback for us please let us know in this ticket!
I've been testing out stages and overall, it's a fantastic addition to the platform. That being said, the new boolean language for specifying stage conditions feels a bit awkward. I've been battling the syntax and banging my head for a few hours just to implement simple conditional statements.
For example:
With environment variables, do I use env(VAR) or env.global(VAR) or "$VAR"??? How do I test if an environment variable is unset? Compare it with "", use "IS present"? Do something else?
What regex syntax is supported? Is it Perl5?
It might be easier to just allow bash/shell statements in conditions the same way you can with the on: tag https://docs.travis-ci.com/user/deployment#Conditional-Releases-with-on%3A.
Regardless, it feels inconsistent having two ways to define conditions in .travis.yml.
Hi,
at the moment i have a "hanging", but faild stage build since ca 11h, look
it is ok that the Development Stage faild, because some test faild, 34.1 and 34.2 !
The next Stage (#34.3) was skipped ... like the Stage Build shout work, but the Last stage 34.4 are are executed ... i thinking that is a Error.
the build are not cancelled after #37 runned.
the bug has no impact for me ... all other builds run fine !!!
thanks for the nice Service !
this can not see any thing,and my .travis.yml is succeed in http://lint.travis-ci.org/,I don't know what happend. Here is my cofig:
language: android
sudo: false
notifications:
email: false
jdk:
- oraclejdk8
android:
components:
-build-tools-25.0.2
-android-25
- extra-android-m2repository
- extra-android-support
- platform-tools
- tools
- add-on
- extra
before_install:
- chmod +x gradlew
script:
- ./gradlew assembleRelease
It appears that if I have a config as such using build stages:
sudo: false
language: python
python:
- 2.7
- 3.4
- 3.5
- 3.6
- pypy
- pypy3
stages:
- test
- name: upload_coverage
if: branch = master
- name: deploy
if: tag IS present
jobs:
include:
- stage: test
install:
- pip install awscli
- pip install -r requires/testing.txt
- python setup.py develop
services:
- postgres
script: nosetests
after_success:
- aws s3 cp ...
- stage: upload coverage
python: 3.6
install:
- pip install awscli coverage codecov
script:
- echo "Hello"
after_success: codecov
- stage: deploy
python: 3.6
deploy:
distributions: sdist bdist_wheelThat no action will be taken as part of the install, script, or after_success steps unless the top-level install`, script, and after_success`` stanzas are defined.
My expectation was that by defining them under the job stanzas it would work but my guess is there's per-job munging that occurs between the top level value and the values in the list and if there is no top level entry for that stanza it is ignored.
After many months of amazing work by the entire Travis team, we're super excited to announce the release of the Travis CI API Version 3!
Central to this release is an improved and modernized API experience, with faster response times, and a dramatically cleaner code base.
As our UI is based on Ember, and as such is a rich javascript codebase, so a great API is even more important to us!
Some of the topics we focused on during development were:
We could go on for pages about why we love this API so much, but why not try it out for yourself! You can head over to our documentation for more information, or read our Blog post announcement which has more information about our API explorer.
Please leave all feedback as comments here, or if you run into a bug, please report it to our support team.
Please excuse if I am off here or have something misconfigured. I recently switched an overlay to using jobs/stages. All was going well till a new stage, or separate group of stages. The previous apt installed packages were no longer present or the prepared env. Despite having cache: apt: true
You can see the resulting build output here. It failed on the Coverity stage as pip was not installed. I had installed that via the new beta apt integration.
I assumed since I had cache: apt: true, that it would retain anything installed via apt for all jobs/stages. That maybe just keeping apt package cache up to date, vs syncing for each stage not sure. I ended up reverting to old means to install stuff via install.
I noticed another essentially duplicating the packages install section for other job groups. Which I find to be less than ideal. It requires duplication and if you change a package in one and forget or miss the other issues. The legacy install approach uses the same section for all. Though I believe it does install more than once stuff, so is less efficient.
Hello!
Is that right place to tell you about user experience?
After pagination you introduce in Account page, it's hard to find needed project to enable it build. I have a lot of repositories (200+) and for me it's very inconvenient
Before, my flow was next: I just synced repositories with my github account and using command+F was able to quickly find target repo and toggling ON/OFF button, but now is not possible. Right now I see only one useful way to do that: type manually repository travis uri: /$account-name/$repository-name and activate build here
I'm trying to improve CI performance by pruning jobs.
Consider a situation where I have 30 jobs (5 php versions, 6 modules that need testing).
Based on the project setup I'm sure that if changes are limited to 1 module there is no need to test the other 5 modules.
I can easily identify what changes have been made (git diff --name-only ...).
I'd like to be able to run a prune stage that executes my code, then based on the outcome (re)evaluates job conditions.
My pruning stages could for example set environment variables, but the issue is that at that point the jobs have already been created / scheduled.
Currently the only solution is to do this check before each job, which is a small optimization but still requires Travis to prep VMs and clone the repository for each job...
Hi,
I have the following stage:
language:
java
jdk:
jobs:
include:
- stage: test
script: ./runmvnprofile.sh gw4e-eclipse-plugin-tests
script: ./runmvnprofile.sh gw4e-eclipse-plugin-ui-tests
script: ./runmvnprofile.sh gw4e-eclipse-studio-tests
script: ./runmvnprofile.sh gw4e-eclipse-studio-ui-tests
The runmvnprofile.sh is as follows
#!/bin/bash
if [ "$1" != "" ]; then
mvn clean install -P$1
else
echo "Profile parameter is missing"
fi
Unfortunately the stages are not taken into account. The shell script is not called instead mvn command are executed mvn test -B
I dont know where these commands came from.
Any idea of how can I launch shell in parallel ?
Thanks.
This branch:
https://github.com/wtanaka/ansible-role-oracle-java/tree/dev
is not showing up in "Cron Jobs" in:
https://travis-ci.org/wtanaka/ansible-role-oracle-java/settings
and I would have expected it to.
Hello!
This isn’t the place for feature requests or bug reports. If that’s what you’ve come here for, please either visit our public bug tracker or send us an email at [email protected].
Otherwise, go ahead and delete this text 😬
I would like to do something like the following where the prepare stage runs with default setting, and the test stage runs with a matrix of explicitly specified configurations. this doesn't work, but i'm not sure how to achieve what i'm looking for. thanks.
include:
- stage: prepare
script:
- echo "prepare"
- stage: test
matrix:
include:
- os: linux
compiler: gcc
- os: linux
env: DOCKER_IMAGE=centos:7
- os: linux
env: DOCKER_IMAGE=fedora:25
- os: linux
env: DOCKER_IMAGE=fedora:24
script:
- echo "test with ${DOCKER_IMAGE}"
It's not uncommon to have your waiting builds queue grow, especially if your team is pushing new code to GitHub every few minutes.
With Auto Cancellation, you can enable Travis to cancel waiting and outdated builds when new builds flow in from GitHub.
This setting can be enabled for Branch and Pull Request builds separately.
Builds will only be canceled if they are waiting to run, allowing for any running jobs to finish.
You can find this new setting on the Repository settings page.
This feature was released for beta testing soon on the 22nd of March. You can find the blog post announcement here: https://blog.travis-ci.com/2017-03-22-introducing-auto-cancellation
Please Note: We are looking at adding the ability to also cancel running jobs. If this is of interest to you and your team, please add the 🎉 emoji to this issue 😄
I'm having difficulties with using build stages with secured variable
https://travis-ci.org/nodejs/docker-node/jobs/362173107#L460
https://github.com/nodejs/docker-node/blob/build-test2/.travis.yml#L48-L49
Am I doing something wrong?
We have shipped iteration 2 for the Build Stages feature.
Along with a lot of bug fixes and small improvements this includes:
Find out more about this on our blog, and documentation here and here.
We would love to hear your feedback. Please leave all thoughts, comments, ideas related to this feature here.
Happy Testing!
We are adding this list of feature requests (with a rough indication of how likely we are going to prioritize it) so you don't have to ask about these again :)
script etc. on the new stages section, so they can be shared across all jobs in one stage. (Yes, but not before [1])allow_failure: true per job on jobs.include. (Probably yes, but not before [1].)stage key on the deploy section. Turn this into a stage and a job. (Not quite sure, not before [1].)skip: all, so one does not have to overwrite before_install, install, and script. (Sounds like a good idea? Not before [1])jobs.include.env: [FOO=foo, BAR=bar]. (Not quite sure).travis.yml editor/web tool. (Yes, based on the specification produced in [1])[2])running tab, consider grouping jobs per build (and possibly stage). (Interesting thought. We are working on improving this UI, and might consider this in a later iteration.)Other improvements:
[1] A strict travis-yml parser has been shipped.[2] The GitHub commit status API has the known limitation that new updates are being rejected after the 1000th update. They are working on improving this, and providing a way for us to post more updates. Until this is unblocked we are unlikely to make any changes to our commit status updates.I've decided to write this bug here as this is beta feature issue:
I try to build my project under php versions 7.0 and 7.1 but this how build looks like
So it's running tests for 7.0 twice but never doing build for php 7.1
My .travis.yml
sudo: true
language: php
php:
- '7.0'
- '7.1'
before_script:
- sudo add-apt-repository ppa:ondrej/php -y
- sudo apt-get update -yy
- sudo apt-get install -y php-bcmath
- composer install -o -q
jobs:
include:
- stage: build
install:
- composer require edgedesign/phpqa --update-no-dev --no-progress -q
script:
- ./vendor/bin/phpqa --analyzedDirs src --report --buildDir ./docs --tools phpcs:0,phpmd,phpcpd:0,phpmetrics:0,phploc,pdepend
- stage: test
script:
- phpunitI use one of my cronjobs for reinstalling a CMS demo from a master branch each day - it would be awesome to build the demo every hour. Other people may need this to refresh a dev or stage environment.
is it possbile to control it via yml?
I am trying to export travis.yml to see what the web UI added as the daily cron job. Though I used the web UI to enable the cron job, we use travis.yml because its easier to manage. Additionally, other can use the travis.yml we supply with the project (in contrast to my web UI settings , which no one gets to see or utilize).
Appveyor had a similar request at Export YML from project configuration. It was well received by the devs, and it serves the community well. Additionally, Appveyor allows one to validate the YML file before committing changes to it.
My apologies if the feature is already present. I'm in the repo's settings, and I only see four headings (General, Auto Cancellation, Environment Variables, Cron Jobs). I also don't see a discussion of the YML in Cron Jobs.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.