Processes Job state updates from Travis Worker, as well as enqueuing Jobs.
Ruby Shell
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
bin
config extract app context Oct 26, 2015
lib/travis use config.notifications for addons (different configs on org and com) Sep 28, 2016
script Fix RabbitMQ credentials for development environment Feb 6, 2012
spec
var/librato update librato space Dec 2, 2015
.gitignore git ignore .jdk-overlay Oct 9, 2015
.librato.yml update librato space Dec 2, 2015
.rspec Remove travis-core Oct 9, 2015
.ruby-version Use .ruby-version file instead of ruby statement in Gemfile Jun 2, 2016
.travis.yml
CONTRIBUTING.md
Gemfile notify scheduler, use sidekiq-pro, cleanup addons Sep 28, 2016
Gemfile.lock notify scheduler, use sidekiq-pro, cleanup addons Sep 28, 2016
MIT-LICENSE.md explain hub in the readme Oct 9, 2015
NOTES.md Re-add Coder to see if that removes Encoding::UndefinedConversionError Nov 9, 2015
Procfile
README.md improve instrument log line Oct 10, 2015
Rakefile improve rakefile Mar 24, 2016

README.md

Travis Hub Build Status

Keeper of the statuses

Travis Hub is the application that, in the life-cycle of accepting, evaluating, and executing a build request, sits in the fifth position, next to Travis Logs.

In short Hub deals with updates to the job and build status coming in from the workers, while Logs deals with collecting build log output from them.

Once a build request has been:

they will be picked by a Worker which will execute the build Bash script as generated by the build script compiler).

The worker goes through a series of stages while acquiring and preparing a VM, and running the build script. Each time the state of the job changes the worker will send a message that will be processed by Hub. These messages are:

  • job:receive signals that the worker has picked up a job and is going to boot a VM for it. (This state is displayed as "booting" in the UI.)
  • job:start signals that the worker has started executing the build script.
  • job:finish signals that the worker has finished executing the build script.
  • job:restart occurs when the worker has troubles booting a VM, or looses connection to it while running the build script. (In this case the job's state will be reset to :created so that Scheduler will queue it again, and Worker will try again.

Processing these messages Hub will change the job's state in the database, set attributes such as received_at, potentially change the respective build's state as well. It will then emit events such as job:started or build:finished which will send out notifications to other parties (such as the web UI via Pusher, GitHub commit status updates, email, IRC, webhook notifications etc).

History

Travis Hub was the first service that we extracted from our Rails application apart from Travis Listener. It was huge, and did all the things that now are being split up into 6 applications (Gatekeeper, Scheduler, Hub, Logs, Sync, Tasks). Nowadays it is one of the smallest service that deals with our core models directly.

Contributing

See the CONTRIBUTING.md file for information on how to contribute to travis-hub. Note that we're using a central issue tracker for all the Travis projects.

License & copyright

See MIT-LICENSE.