The public Travis API
c6e3c29a57
We can do it, because we use :transaction strategy with DatabaseCleaner, which starts transaction before each test and rollbacks after it. That way data before each test is consistent. The big advantage of such approach is that tests are fast now - we need to only load Scenario data once. One of the drawbacks, on the other hand, is that we need to always load this data, even if no integration tests need running. We can try to be smart about it and check if any integration tests are loaded. |
||
|---|---|---|
| config | ||
| docs | ||
| lib/travis/api | ||
| public/images/result | ||
| script | ||
| spec | ||
| .buildpacks | ||
| .gitignore | ||
| .travis.yml | ||
| config.ru | ||
| Gemfile | ||
| Gemfile.lock | ||
| Procfile | ||
| Rakefile | ||
| README.md | ||
| travis-api.gemspec | ||
The public Travis API
This is the app running on https://api.travis-ci.org/
Installation
Setup:
$ bundle install
Run tests:
$ RAILS_ENV=test rake db:create db:schema:load
$ rake spec
Run the server:
$ rake db:create db:schema:load
$ foreman start
Contributing
- Fork it
- Create your feature branch (
git checkout -b my-new-feature) - Commit your changes (
git commit -am 'Add some feature') - Push to the branch (
git push origin my-new-feature) - Create new Pull Request
API documentation
We use source code comments to add documentation. If the server is running, you
can browse an HTML documenation at /docs.
Project architecture
lib
`-- travis
`-- api
`-- app
|-- endpoint # API endpoints
|-- extensions # Sinatra extensions
|-- helpers # Sinatra helpers
`-- middleware # Rack middleware
Classes inheriting from Endpoint or Middleware, they will automatically be
set up properly.
Each endpoint class gets mapped to a prefix, which defaults to the snake-case
class name (i.e. Travis::Api::App::Profile will map to /profile).
It can be overridden by setting :prefix:
require 'travis/api/app'
class Travis::Api::App
class MyRouts < Endpoint
set :prefix, '/awesome'
end
end