From e485c14a3ee29ee486324a96545abf964d428101 Mon Sep 17 00:00:00 2001 From: Matthew Draper Date: Tue, 9 Apr 2019 11:28:49 +0930 Subject: s/Travis/Buildkite/ --- README.md | 2 +- RELEASING_RAILS.md | 2 +- actioncable/karma.conf.js | 6 +++--- guides/source/contributing_to_ruby_on_rails.md | 6 +++--- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 566136e2a2..98ade9b445 100644 --- a/README.md +++ b/README.md @@ -97,7 +97,7 @@ Everyone interacting in Rails and its sub-projects' codebases, issue trackers, c ## Code Status -[![Build Status](https://travis-ci.org/rails/rails.svg?branch=master)](https://travis-ci.org/rails/rails) +[![Build Status](https://badge.buildkite.com/ab1152b6a1f6a61d3ea4ec5b3eece8d4c2b830998459c75352.svg?branch=master)](https://buildkite.com/rails/rails) ## License diff --git a/RELEASING_RAILS.md b/RELEASING_RAILS.md index dd2742b403..d2d7a771bc 100644 --- a/RELEASING_RAILS.md +++ b/RELEASING_RAILS.md @@ -14,7 +14,7 @@ Today is mostly coordination tasks. Here are the things you must do today: Do not release with a Red CI. You can find the CI status here: ``` -https://travis-ci.org/rails/rails +https://buildkite.com/rails/rails ``` ### Is Sam Ruby happy? If not, make him happy. diff --git a/actioncable/karma.conf.js b/actioncable/karma.conf.js index 845b38d74f..83e9c98af1 100644 --- a/actioncable/karma.conf.js +++ b/actioncable/karma.conf.js @@ -52,9 +52,9 @@ if (process.env.CI) { } function buildId() { - const { TRAVIS_BUILD_NUMBER, TRAVIS_BUILD_ID } = process.env - return TRAVIS_BUILD_NUMBER && TRAVIS_BUILD_ID - ? `TRAVIS #${TRAVIS_BUILD_NUMBER} (${TRAVIS_BUILD_ID})` + const { BUILDKITE_JOB_ID } = process.env + return BUILDKITE_JOB_ID + ? `Buildkite ${BUILDKITE_JOB_ID}` : "" } } diff --git a/guides/source/contributing_to_ruby_on_rails.md b/guides/source/contributing_to_ruby_on_rails.md index 569f52652f..c33d523c0e 100644 --- a/guides/source/contributing_to_ruby_on_rails.md +++ b/guides/source/contributing_to_ruby_on_rails.md @@ -302,7 +302,7 @@ the recommended workflow with the [rails-dev-box](https://github.com/rails/rails As a compromise, test what your code obviously affects, and if the change is not in railties, run the whole test suite of the affected component. If all tests are passing, that's enough to propose your contribution. We have -[Travis CI](https://travis-ci.org/rails/rails) as a safety net for catching +[Buildkite](https://buildkite.com/rails/rails) as a safety net for catching unexpected breakages elsewhere. #### Entire Rails: @@ -418,7 +418,7 @@ To run a single test against all adapters, use: $ bundle exec rake TEST=test/cases/associations/has_many_associations_test.rb ``` -You can invoke `test_jdbcmysql`, `test_jdbcsqlite3` or `test_jdbcpostgresql` also. See the file `activerecord/RUNNING_UNIT_TESTS.rdoc` for information on running more targeted database tests, or the file `ci/travis.rb` for the test suite run by the continuous integration server. +You can invoke `test_jdbcmysql`, `test_jdbcsqlite3` or `test_jdbcpostgresql` also. See the file `activerecord/RUNNING_UNIT_TESTS.rdoc` for information on running more targeted database tests. ### Warnings @@ -677,7 +677,7 @@ $ git apply ~/my_changes.patch This works well for simple changes. However, if your changes are complicated or if the code in master has deviated significantly from your target branch, it might require more work on your part. The difficulty of a backport varies greatly from case to case, and sometimes it is simply not worth the effort. -Once you have resolved all conflicts and made sure all the tests are passing, push your changes and open a separate pull request for your backport. It is also worth noting that older branches might have a different set of build targets than master. When possible, it is best to first test your backport locally against the Ruby versions listed in `.travis.yml` before submitting your pull request. +Once you have resolved all conflicts and made sure all the tests are passing, push your changes and open a separate pull request for your backport. It is also worth noting that older branches might have a different set of build targets than master. When possible, it is best to first test your backport locally against the oldest Ruby version permitted by the target branch's `rails.gemspec` before submitting your pull request. And then... think about your next contribution! -- cgit v1.2.3