# docs-travis-ci-com: the Jekyll and Slate source behind the Travis CI docs > The Travis CI documentation site is a Jekyll build with a Slate API reference, a Ruby and bundler toolchain and a Rake task that assembles both, and the repository doubles as the contribution guide for the people who edit it. It suits anyone who wants to write for the Travis CI docs or mirror the site structure, and it is a documentation site, not a CI product. **travis-ci/docs-travis-ci-com** — The Travis CI Documentation - Repository: https://github.com/travis-ci/docs-travis-ci-com - Website: http://docs.travis-ci.com - Stars: 647 · Forks: 3,438 - Language: HTML - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/travis-ci-docs-travis-ci-com ## A Jekyll site with a Slate API reference This repository is the documentation site for Travis CI, and the README opens with a build status badge and the statement that it is the documentation site, followed by a guide to adding new documentation and updating existing documentation. The stack is a Jekyll site with a Ruby toolchain, and the top level of the repository shows it in full. There is a _config.yml, the _includes, _layouts, _plugins, _data and assets directories that Jekyll expects, an index.html, a 404.html, a CNAME file for the custom domain, and content directories named legal, newsletter and user. A Dockerfile, a Procfile, a config.ru, a Rakefile and a Gemfile with a Gemfile.lock complete the deployment side, and there is a .ruby-version file pinning the interpreter. The API documentation is a separate system. All Travis CI API V2 and 2.1 documentation is maintained in slate/source and generated from the source at build time, and the slate/ directory sits alongside the Jekyll content. So there are two documentation trees in one repository, one for prose and one for the API reference, and they are assembled by the same build. The homepage is docs.travis-ci.com and the licence is MIT, distributed like other Travis CI projects. The audience is two groups, and they need different things. The first is a Travis CI user reading the docs, and the second is a contributor who wants to fix a page, and the rest of the README is written for the second group. ## Two contribution paths, and the edit on GitHub button The README documents two workflows, and the second one is the more interesting design decision. Adding documentation takes seven steps. Review the documentation guidelines in STYLE.md. Check existing documentation to verify the page does not already exist, or look for related documentation that could be enhanced instead. Determine proper placement by browsing to the user folder, or another specific folder, and creating a branch. Create a new file and add the new documentation files, making sure to insert the name and extension for the file. Commit the changes with a short message describing them. Test the changes locally to verify the edits. Then submit a pull request with a clear title and description, and click Create pull request. Updating an existing page is shorter and uses a feature of GitHub itself. You click the Improve this page on GitHub button in the top right corner, which takes you to GitHub where you edit the relevant file, commit your changes naming your branch, click the Propose changes button, build the docs locally to verify, and then submit a pull request with a clear title and description. That button is the significant part. It means a reader who spots a typo does not have to clone a repository, install Ruby, run bundler and remember the Jekyll commands, because the edit happens in the browser and the local build step is only needed for a substantive change. For a documentation project with thousands of pages, that is the difference between a correction getting made and a correction being filed as an issue. Both workflows end the same way, with the team reviewing the pull request and approving any necessary changes. ## The local toolchain: bundler, Jekyll and Puma The local environment section is a standard Jekyll setup, and it is worth reading because the two server options are not interchangeable. First, install Ruby and RubyGems. Clone the documentation repository. Then install bundler: ```sh-session $ gem install bundler ``` And then install the application dependencies: ```sh-session $ bundle install --binstubs ``` The --binstubs flag is what produces the bin/ directory that every later command uses, since the documented commands are all invoked as ./bin/... rather than through a global binary. To generate the documentation, run: ```sh-session $ ./bin/jekyll build ``` To preview it, there are two options and the README is explicit about which to use. Jekyll is enough for documentation edits: ```sh-session $ ./bin/jekyll serve ``` And Puma is necessary for more programmatic pull requests, such as handling webhook notifications via POST: ```sh-session $ ./bin/puma ``` The first serves on localhost:4000 in a browser, the second on localhost:9292. The distinction is a real one. A Jekyll server serves static output, so it cannot process a request that needs a response computed at request time. A webhook receiver needs a POST endpoint that answers, which means an application server. The two commands differ in port, 4000 against 9292, which is a useful signal that they are not the same thing. The Dockerfile shows how the same application is run in production. It is based on ruby:3.2-slim with git, make, a compiler toolchain, libpq-dev, libcurl and nodejs installed for the bundle install, UTF-8 locale settings, a frozen bundler configuration so the Gemfile cannot drift from the lockfile, a copy of the source and a bundle exec rake build. The container then exposes port 4000 and its command is bundle exec puma with the port argument set to 4000. That last detail is worth noticing. In production, Puma serves on 4000, the same port the local Jekyll preview uses, so the local and deployed setups differ in the server, not the port. ## A Rake build that assembles prose and API reference The Rakefile is the piece that ties the two documentation systems together, and it is the one file in the repository that explains why the build exists at all rather than just running Jekyll. The Dockerfile runs bundle exec rake build as the build step, so the Rake task is on the critical path for every container image, and the Gemfile install in the image uses --verbose --retry=3, which is the sensible setting for a network-dependent install inside a build. The repository also carries a .rubocop.yml with a .rubocop_todo.rb companion file, which is a common pattern in Ruby projects that adopt a linter on an existing codebase: the todo file records the offences that are grandfathered in, and the main config holds the rules for new code. There is a .coafile and an .alexrc, so prose is checked for insensitive language as well as code being linted. The .travis.yml is still present, which is a small historical artefact worth noting in a repository whose subject is a CI product that has largely moved on. The practical takeaway for a contributor is that the build is not a single command. There is a Jekyll build for the prose, a Slate build for the API reference, and a Rake task that runs the combination. The README's local instructions cover the Jekyll side, which is enough for editing prose, and that is exactly the scope the workflow assumes for a documentation pull request. ## Where docs-travis-ci-com is the wrong thing to adopt The first case is a team looking for Travis CI. This is documentation. The continuous integration product itself is a separate codebase, and adopting this repository gives you a Jekyll site and a Slate API reference, not a build server. That said plainly, because the name invites the confusion. The second case is a documentation project that has outgrown hand-edited Markdown. Jekyll with a plugins directory is a fine model for a site where a person writes a page, but a product with a large API surface and many generated pages usually moves to a component based authoring workflow, where a source of truth in JSON or a schema generates the reference pages, and where a documentation platform handles versioning, search and localisation. This repository has exactly one generated tree, slate/source for the API reference, and everything else is written by hand. The third case is a team that wants a modern toolchain. Jekyll is Ruby, and the dependency set here is old enough that the Docker image pins bundler 2.4.22 explicitly, which is what you do when the bundler version bundled with a given Ruby is not the one you want. The site is stable and it renders, but a greenfield docs site today would more likely start with a static site generator in JavaScript or a documentation platform, and would not need a Puma server to handle a webhook preview. The alternative worth comparing is simply hosting the same content in a documentation platform, where versioning, search, redirects and a preview environment are handled for you and the review flow lives next to the content. The difference in approach is ownership of the whole stack. This repository gives you a Jekyll site you can run anywhere, including inside the Docker image, and takes on the cost of maintaining plugins, a Ruby dependency tree and a build that assembles two separate documentation systems. ## Conclusion docs-travis-ci-com fits a technical writer or engineer who wants to improve the Travis CI documentation, or a team that wants to mirror the structure of a large product documentation site, since the whole pipeline is a plain Jekyll build with a Ruby toolchain and a documented local preview. It is the wrong choice for anyone looking for Travis CI itself, for a documentation project that needs a component based authoring workflow, and for a team that wants a modern static site generator rather than Jekyll with a plugin directory. Before contributing, read STYLE.md, since the guidelines are the first step in both the add and the update workflow, and note that the API reference is generated at build time from slate/source, so API changes are not edited in the same place as prose. ## FAQ ### How do I build the Travis CI documentation site locally? Install Ruby and RubyGems, clone the repository, run gem install bundler, then bundle install --binstubs, and finally ./bin/jekyll build to generate the documentation. The binstubs flag is what creates the bin/ directory the later commands use. ### What is the difference between the Jekyll and Puma local servers? Jekyll is sufficient for documentation edits and serves on localhost:4000 with ./bin/jekyll serve. Puma is necessary for more programmatic pull requests such as handling webhook notifications via POST, and serves on localhost:9292 with ./bin/puma. ### How do I fix a typo in the Travis CI documentation? Click the Improve this page on GitHub button in the top right corner of the page, edit the file on GitHub, commit with a named branch, click Propose changes, build the docs locally to verify, and then submit a pull request with a clear title and description. ### Where does the Travis CI API reference documentation live? All Travis CI API V2 and 2.1 documentation is maintained in slate/source and generated from the source at build time, so the API reference is a separate tree from the rest of the Jekyll content. ### What licence is the Travis CI documentation released under? It is distributed under the MIT license, like other Travis CI projects, with the licence file at the repository root. The repository is not archived and the last push was on 2026-09-22. ## Sources - [Issues](https://github.com/travis-ci/docs-travis-ci-com/issues) - [License: MIT](https://github.com/travis-ci/docs-travis-ci-com/blob/master/LICENSE) - [Project website](http://docs.travis-ci.com) - [README](https://github.com/travis-ci/docs-travis-ci-com/blob/master/README.md) - [travis-ci/docs-travis-ci-com on GitHub](https://github.com/travis-ci/docs-travis-ci-com) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/travis-ci-docs-travis-ci-com