travis-ci / travis-ci

Free continuous integration platform for GitHub projects.

✋ Do not open new issues here! ✋

Travis CI

Travis CI is a hosted continuous integration and deployment system. You can now test and deploy open source and private projects on travis-ci.com! You can read more about this change here.

Move to Forum

We are moving to our new community forum: Travis CI Community! As part of this move, we’ll be able to better follow and reply to threads, along with making it easier for you to find solutions and answers. We’ll be making our best efforts to answer currently existing threads, or directing them to the new community forum.

Link to the Community Forum: https://travis-ci.community

For current outages and incidents such as slow network connections, subscribe to https://www.traviscistatus.com.

Other support issues may be directed to [email protected] where our support team will be glad to assist.

This repository contains the central issue tracker for the Travis CI project.

Documentation

Documentation for the Travis CI project can be found at https://docs.travis-ci.com.

Other repositories

Travis CI consists of many different sub-projects. The main ones are:

travis-api

travis-api is the Sinatra app that's responsible for serving our API. It responds to different HTTP endpoints and runs services in travis-core. Very little logic is in this repository.

travis-build

travis-build creates the build script for each job. It takes the configuration from the .travis.yml file and creates a bash script that is then run in the build environment by travis-worker. This repository also hosts the source for language-specific scripts.

travis-cookbooks

travis-cookbooks holds the Chef cookbooks that are used to provision the build environments.

travis-hub

travis-hub collects events from other apps and notifies other apps about the events. For example, it notifies travis-tasks about builds starting and finishing so notifications can be sent out.

travis-hub is also responsible for enqueueing jobs that have been created and enforcing the Quality of Service restrictions, such as the number of concurrent builds per user.

travis-listener

travis-listener receives notifications from GitHub whenever commits are pushed or pull requests are opened. They are then pushed onto RabbitMQ for other apps to process.

travis-logs

travis-logs receives log updates from travis-worker, saves them to the database and pushes them to the web client. When a job is finished, travis-logs is responsible for pushing the log to Amazon S3 for archiving.

travis-support

travis-support holds shared logic for the different Travis CI apps. It is different from travis-core in that it holds more generic things, like how to run an async job or how to handle exceptions.

travis-tasks

travis-tasks receives notifications from travis-hub and sends out notifications to the different notification providers as needed.

travis-web

travis-web is our main Web client. It is written using Ember and communicates with travis-api to get information and gets live updates from travis-hub and travis-logs through Pusher.

travis-worker

travis-worker is responsible for running the build scripts in a clean environment. It streams the log output to travis-logs and pushes state updates (build starting/finishing) to travis-hub.

travis-ci's Issues

Allow email address to be configured

It'd be nice to be able to configure where build notification emails get sent. The .travis.yml seems like the natural place. I imagine that most projects will only have one email, but it would be nice if it supported multiple as well.

GitHub login failure

omniauth throws the following error:

OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed

I believe that's about this GitHub issue: http://support.github.com/discussions/site/3398-your-oauth-implementation-is-broken-but-heres-a-fix

P.S. We can rescue from OpenSSL::SSL::SSLError with redirect_to root but it will be only a dirty fix to hide '500 Something went wrong' error.

pre- and post-build hooks

Currently my build script is a series of 3 or 4 setup commands, bin/rspec spec, then a command to push the built file up to s3. Right now it's all just anded together, but it might be cleaner if you could do as such:

before:
  - rake db:setup_thing
  - rake env:something_else
  - rake mongo:clean

script: bin/rspec spec

after:
  - rake send_to_s3

An added benefit would also be that you could fold the output of the pre- and post- commands to keep things tidy. A non-zero return in any command would be a failed test run. Does this seem like something that would be useful to travis-ci?

Automate deployment for Heroku and workers

Since we now have a staging env it would make sense to automate deployment to Heroku and the respective worker per environment.

Shall we use Capistrano? Something else?

Intstall pg on a worker box

Currently, travis builds fail.

No need to install mongo, couch, redis, etc. now however, it would be cool to make builds green again.

Buildable: only run bundle install if a Gemfile is present

We currently try to run bundle install even if no Gemfile is present. That gives an ugly error message even though for repositories without any dependencies this is quite a valid thing to do.

configure args to pass to the rvm and bundle commands

When I run bundle install in my dev environment I run it with the --binstubs flag. I'd like a means of configuring travis to do the same. Something like the following in a config file:

bundler_args: "--binstubs"

This could be applied to rvm as well, though I'm not certain what command line args anybody would want to use.

build is passing, but graphic says it's failing

http://travis-ci.org/#!/rspec/rspec-core shows the last build is passing, but http://travis-ci.org/rspec/rspec-core.png is the failing graphic.

Make unit tests use a Redis mock

We currently just skip tests that involve Redis. We should be able to use one of these:

• https://github.com/guilleiguaran/fakeredis
• https://github.com/jayferd/mock_redis

Store the github payload per build

Should be useful for debugging, but also re-building the build, e.g. from the desktop client or even web ui.

Buildable: make the build fail if bundle install failed

We currently run both bundle install and execute the build command even though "rvm non-existant-ruby && bundle install" already failed. The build should fail right after bundle install failed.

psych support

My code uses Psych when running on 1.9.2,
but I saw error while loading psych:

LoadError: no such file to load -- psych

Can we install psych (thus libyaml) for 1.9.2?

Add support for Ruby 1.9.3

Ruby 1.9.3 is coming soon we should add support for it in Travis so people can start testing against it. It can be installed via rvm with the command:

rvm install ruby-head

Improve notification emails

Provide more information about the build, maybe add a summary about matrix child builds at the top etc. Use an HTML format?

Github service hook doesn't seem to work

... at least that's my impression.

We've had a bunch of people report that they've used the Travis service hook and it didn't work. Then they've set up a generic service hook ping and it worked.

That also might mean that there's some bug in the implicit creation of a repository on our side. Like: It tries to create the repository on the first ping, somehow fails but leaves some record. When the next ping comes in it then works. Not sure.

UI/tabs: make the entire tab clickable

Currently the tab has a pointer cursor, but only the link (which is smaller than the tab) is actually clickable.

Instead the a tag should fill the entire tab.

support for rvm

did all the issues from the old repo disappear?

as far as i remember there was a feature request to add support for rvm within builds.

any news on that?

Support gems that require a different bundler version then the currently installed

e.g. jeweler needs ~>1.0.0, so projects bundeling jeweler cannot be bundled via 1.1 beta.

solution 1

A quick fix for this would be to grep the gemfile for a bundler version
cat Gemfile.lock | grep bundler | head -n1 | pru 'sub(/.*\((.*)\)/,"\\1")'

and if found use a bundler version that matches this requirement (install it if its not there already)

curl http://rubygems.org/api/v1/versions/bundler | pru --require json 'JSON.parse(self).map{|g|g["number"]}.find{|v| Gem::Requirement.new("~>1.0.1").satisfied_by? Gem::Version.new(v) }'

and the use this version to bundle the gemfile

bundle _1.0.13_ install

solution 2 (dirty)

modify the Gemfile.lock and remove any bundler requirement and notify the user that it was removed via .e.g "Not using specified bundler version"

Commit-Hash-Link points back to travis

The link at the commit hash shown at build screen points back to travis not to github.
And the committer info is empty since travis commit 566ae69

Profile view improvment

When you click on 'profile' (http://travis-ci.org/profile) you should see your repos on the left hand side.

Custom build script does not execute chained commands

When using rake db:migrate && rake spec it doesn't seem to execute both commands: http://travis-ci.org/#!/lunks/wargame/builds/2536

Error: Could not find a JavaScript runtime.

The rspec-rails build depends on rails-3.1.0.beta1, which depends (indirectly) on execjs, which requires a javascript engine be available on the box. Please install any of the engines listed on https://github.com/sstephenson/execjs.

Thanks

Build matrix with a single rvm ruby doesn't spawn any child builds

https://github.com/ruby-amqp/amqp/blob/d04fd8b3afe6a31034b988dfa4f96e647d9df539/.travis.yml

http://travis-ci.org/#!/ruby-amqp/amqp/builds/2816

Apparently when a .travis.yml contains an rvm section with a single ruby the configuration step does not spawn any child builds. Of course, in theory, the worker could immediately run the build in this case.

build:finished does not update duration in build history and matrix rows

well, the title says it all ;)

Use octokit instead of cooking our own

We currently use some custom code to access the Github API for populating owner emails for repositories and organizations. We probably should use Octokit for that.

Repo with .rvmrc will kill the site

Hi,

I just tried to build lgierth/pakada-theming at http://travis-ci.org/#!/lgierth/pakada-theming/builds/6317

RVM is waiting for input on whether or not to evaluate the .rvmrc script. This flooded the build worker and ultimately (after around 8 minutes) killed the app.

There are three possible solutions:

1. Disable project-specific .rvmrc scripts in RVM
2. Delete .rvmrc script before chdir'ing into the cloned repo
3. Introduce an (input) timeout for build processes

Would you be interested in a patch for #1 or #3?

(02:42:38) lgierth: is there kind-of a timeout for builds?
(02:42:52) lgierth: is just pushed to my repo with a .rvmrc file
(02:43:10) svenfuchs [~svenfuchs@host] hat den Raum betreten.
(02:43:20) lgierth: now rvm is waiting for yes/no input and thus flooding the buildlog
(02:44:51) lgierth: so i basically fucked the travis-ci.org frontpage as long as lgierth/pakada-theming is the latest build
(02:46:28) lgierth: svenfuchs: my build is flooding travis-ci.org (lgierth/pakada-theming)
(02:47:02) lgierth: it's already slow as hell
(02:48:10) svenfuchs: lgierth: i was just about to go to bed :)
(02:48:13) svenfuchs: but lemme check
(02:48:19) lgierth: sorry :)
(02:48:58) lgierth: ah, got a 500 now
(02:49:03) lgierth: for /profile
(02:49:12) svenfuchs: same here
(02:49:23) svenfuchs: shit happens, don't worry, we're still bleeding alpha
(02:50:23) svenfuchs: i've killed the worker, the app is back
(02:50:29) lgierth: cool, thanks
(02:50:35) svenfuchs: now, this is an interesting build: http://travis-ci.org/#!/lgierth/pakada-theming/builds/6317
(02:50:37) svenfuchs: :D
(02:50:46) lgierth: i'll file an issue for deleting .rvmrc before chdir'ing k?
(02:50:49) svenfuchs: i wonder how to prevent that
(02:50:49) lgierth: hehe
(02:51:07) lgierth: disable project-specific .rvmrc or delete .rvmrc before chdir'ing
(02:51:28) svenfuchs: yeah, or just file an issue about the whole thing (mention that url). there must be a way to ignore a local .rvmrc
(02:51:37) svenfuchs: k
(02:51:43) svenfuchs: lemme restart the worker
(02:52:50) svenfuchs: ok, the worker seems to be back
(02:53:05) svenfuchs: lgierth: thanks a lot, i think we haven't seen this bug before :)
(02:53:20) svenfuchs: i'll call it a day now. cu tomorrow
(02:53:22) lgierth: :)
(02:53:26) lgierth: thanks for the quick response ;)
(02:53:32) svenfuchs: np

Q: misleading ruby versions in logs

If you run a matrix build rvm use will show the right ruby version. But later in the log the shown ruby version points to wrong path. Might this is just a log problem, but looks confusing (at least for me).
Here is log part when ruby 1.8.7 is used:

$ rvm use 1.8.7 && git submodule update --init && rake test
Using /home/travis/.rvm/gems/ruby-1.8.7-p330
/home/travis/.rvm/rubies/ruby-1.8.7-p330/bin/ruby -I"lib:lib:test" 
"/home/travis/.rvm/gems/ruby-1.8.7-p330/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" 
....
(in /tmp/travis/builds/plataformatec/simple_form)
Loaded suite /home/travis/.rvm/gems/ruby-1.8.7-p330/gems/rake-0.8.7/lib/rake/rake_test_loader

and here when ruby 1.9.2 is used:

$ rvm use 1.9.2 && git submodule update --init && rake test
Using /home/travis/.rvm/gems/ruby-1.9.2-p136
/home/travis/.rvm/rubies/ruby-1.8.7-p330/bin/ruby -I"lib:lib:test" 
"/home/travis/.rvm/gems/ruby-1.8.7-p330/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" 
....
(in /tmp/travis/builds/plataformatec/simple_form)
Loaded suite /home/travis/.rvm/gems/ruby-1.8.7-p330/gems/rake-0.8.7/lib/rake/rake_test_loader

(This example is from the build #8 of plataformatec/simple_form - http://travis-ci.org/#!/plataformatec/simple_form/builds/1502)

Reuse github picture for accounts

Point tumblr.travis-ci.org to tumblr

... so we can use our own domain.

http://www.tumblr.com/docs/de/custom_domains

Make the build fail on certain conditions

Sometimes, one may want to force build to fail on certain conditions, e.g. test coverage is less than 75%.

However, that will require like rcov and counting skipped [due to lack of {redis,mongo,couch} on our worker machine] tests as passed or something similar.

Wdyt?

Runs in production environment by default

It seems like the build happens with RAILS_ENV=production by default (for example here you can see "Loading production seeds"). This is surprising, I would have expected to run in test.

build matrix: if ruby version is not present script builds anyway

might not a travis problem...
see http://travis-ci.org/#!/svenfuchs/gem-release/builds/1045
the child builds 18.3 and 18.4 requesting ruby 1.9.2, the rvm returns that this version is not installed, the build script doesn't stop, so the build shows green.
IMO the build should not be green in this case as the requested version was not tested.

Show info to new users

Just signed up and everything is empty, would be nice to see something like "do abs to get some your build results/setup a project"

build status gifs should say "passing" or "failing" instead of "stable" "unstable"

The words "stable" and "unstable" have all sorts of implications that have nothing to do with a CI build passing or failing. I'd recommend using words like "passing" and "failing" instead.

Get an upgraded hoptoad account

Since we now have a staging env we'd want a separate hoptoad app for that. Unfortunately hoptoad wants us to upgrade the plan for that.

Josh, can you ask those guys for a free account? We can give them a logo/banner on our site.

Tumblr log theme

http://travis-ci.tumblr.com

Who wants to add a theme so we can link it from http://travis-ci.org?

sorting of sub-builds

the sort order of sub-builds of a matrix build is alphanum sorting not number sorting. you see 1.1, 1.10, 1.2
see: http://travis-ci.org/#!/rspec/rspec-rails/builds/4708

Bookmarklet for starting builds from the github fork queue

It would be awesome to have a bookmarklet that adds a "test now" button to commits on the github fork queue.

When a build runs repeated calls to foldLog insert multiple linebreaks

... which obviously results in a weird looking build log.

Always failing, a timing issue?

Builds for Rubikon are always failing because of one single test that involves a timed action. In short, a throbber is displayed for a specific time (~100ms) and the output is tested. Because sleep can't guarantee a fixed time, I measure the time taken and calculate the output based on that time. See the code of that test here (or here for a second solution which also failed).

While this works on several machines I tested it, it always fails on Travis' worker for all (!) Rubies used. Is this an issue with the worker or did I miss something in my test?

PS: I had that problem before, when I didn't calculate the expected output, but relied on sleep being correct. Even that worked in 95% of the builds on my local machine. But the current problem seems to be more serious.

support for environment variables

i would like to have some configuration in travis-ci website where i can put environment variables that get promoted to the test that i don't want to check into github.

Track branch names for builds

Should store the branch name for a build and then display it with the commit hash (like: a1b2c3d [master]) or something.

support for branches

maybe i just misconfigured my latest project, but it does not bild if i push changes to a branch other than master.

Add an admin item to the user dropdown

... so that after logging in the user can directly go to the backend (if they're admin)

Matrix child build jobs not displayed correctly

When a matrix build is expanded to child build jobs and one reloads the page then the child build jobs aren't displayed correctly. Instead only "#"'s are displayed. I.e. the repository name and build number are both missing.

ruby-debug vs linecache on rubinius

Apparently bundler does not support a :platform directive for rubinius (it is considered to be 1.8.7, eh, hu? rubygems/bundler#1050) so specifying a different version for ruby-debug or dependend gems (especially linecache) doesn't seem to be possible.

Thus, adding a Gemfile.lock (which is required to deploy to Heroku) will cause bundle install to fail on rbx.

Not sure how to fix this ...

Issues when reloading the page while a build runs

https://skitch.com/joshk/r3714/travis-ci-distributed-build-platform-for-the-ruby-community and https://skitch.com/joshk/r37uy/travis-ci-distributed-build-platform-for-the-ruby-community

Worker not showing up any more

The worker isn't showing up on the worker list any more even though it's clearly running.

My push caused a different fork to be built

Last night I pushed to myronmarston/vcr and travis built svenfuchs/vcr, not myronmarston/vcr.

Very weird. Any ideas what caused it?

help with rspec-rails build (please)

rspec-rails just ran on travis for the first time, but it ran 27 builds instead of the 9 I was expecting, and they all seem to have exited right away.

Here is the travis config: https://github.com/rspec/rspec-rails/blob/master/.travis.yml

Here is the report: http://travis-ci.org/#!/rspec/rspec-rails/builds/4708

Please help/advise.