diff --git a/README.md b/README.md
index 4d25d84ce700226e4bb99b8dff05747b7b1e203e..bb41d0441a002bb0ca1d802c8d4320c0ce9771a2 100644
--- a/README.md
+++ b/README.md
@@ -72,7 +72,7 @@ Code is under the [BSD 2-clause "Simplified" License](LICENSE.txt).
Documentation is under the [Creative Commons Attribution license](https://creativecommons.org/licenses/by/4.0/).
## Sponsors
-Our Xserve ESXi boxes for CI are hosted by [MacStadium](https://www.macstadium.com).
+Our macOS continuous integration infrastructure is hosted by [MacStadium](https://www.macstadium.com).
[](https://www.macstadium.com)
diff --git a/docs/Bottles.md b/docs/Bottles.md
index c52ad8292640f03df715a6a21fb49a89f38e331f..2aa9cb83424c1beee9a973ed19ea7f679f4ecd3d 100644
--- a/docs/Bottles.md
+++ b/docs/Bottles.md
@@ -8,7 +8,7 @@ If a bottle is available and usable it will be downloaded and poured automatical
Bottles will not be used if the user requests it (see above), if the formula requests it (with `pour_bottle?`), if any options are specified during installation (bottles are all compiled with default options), if the bottle is not up to date (e.g. lacking a checksum) or if the bottle's `cellar` is not `:any` nor equal to the current `HOMEBREW_CELLAR`.
## Creation
-Bottles are created using the [Brew Test Bot](Brew-Test-Bot.md). This happens mostly when people submit pull requests to Homebrew and the `bottle do` block is updated by maintainers when they `brew pull --bottle` the contents of a pull request. For the Homebrew organisations' taps they are uploaded to and downloaded from [Bintray](https://bintray.com/homebrew).
+Bottles are created using the [Brew Test Bot](Brew-Test-Bot.md). This happens mostly when people submit pull requests to Homebrew and the `bottle do` block is updated by maintainers when they `brew pr-publish` or `brew pr-pull` the contents of a pull request. For the Homebrew organisations' taps they are uploaded to and downloaded from [Bintray](https://bintray.com/homebrew).
By default, bottles will be built for the oldest CPU supported by the OS/architecture you're building for (Core 2 for 64-bit OSs). This ensures that bottles are compatible with all computers you might distribute them to. If you *really* want your bottles to be optimised for something else, you can pass the `--bottle-arch=` option to build for another architecture; for example, `brew install foo --build-bottle --bottle-arch=penryn`. Just remember that if you build for a newer architecture some of your users might get binaries they can't run and that would be sad!
diff --git a/docs/Brew-Test-Bot-For-Core-Contributors.md b/docs/Brew-Test-Bot-For-Core-Contributors.md
index 4795e6c842d28563b381b188d06e1b6c7be84b88..cdff7164c61f88ad166185919d2e789b50599735 100644
--- a/docs/Brew-Test-Bot-For-Core-Contributors.md
+++ b/docs/Brew-Test-Bot-For-Core-Contributors.md
@@ -2,25 +2,16 @@
If a build has run and passed on `brew test-bot` then it can be used to quickly bottle formulae.
-There are two types of Jenkins jobs you will interact with:
-
-## [Homebrew Core Pull Requests](https://jenkins.brew.sh/job/Homebrew%20Core%20Pull%20Requests/)
-This job automatically builds any pull requests submitted to Homebrew/homebrew-core. On success or failure it updates the pull request status (see more details on the [main Brew Test Bot documentation page](Brew-Test-Bot.md)). On a successful build it automatically uploads bottles.
-
-## [Homebrew Testing](https://jenkins.brew.sh/job/Homebrew%20Testing/)
-This job is manually triggered to run [`brew test-bot`](https://github.com/Homebrew/homebrew-test-bot/blob/master/cmd/brew-test-bot.rb) with user-specified parameters. On a successful build it automatically uploads bottles.
-
-You can manually start this job with parameters to run [`brew test-bot`](https://github.com/Homebrew/homebrew-test-bot/blob/master/cmd/brew-test-bot.rb) with the same parameters. It's often useful to pass a pull request URL, a commit URL, a commit SHA-1 and/or formula names to have the Brew Test Bot test them, report the results and produce bottles.
-
## Bottling
-To pull and bottle a pull request with `brew pull`:
+
+If a pull request is correct and doesn't need any modifications to commit messages or otherwise:
1. Ensure the job has already completed successfully.
-2. Run `brew pull --bottle 12345` where `12345` is the pull request number (or URL). If it complains about a missing URL with `BrewTestBot` in it then the bottles have not finished uploading yet; wait and try again later.
-3. Run `git push` to push the commits.
+2. Run `brew pr-publish 12345` where `12345` is the pull request number (or URL).
+3. Watch the [actions queue](https://github.com/Homebrew/homebrew-core/actions) to ensure your job finishes. BrewTestBot will usually notify you of failures with a ping as well.
-To bottle a test build:
+If a pull request needs changes to the commit messages:
1. Ensure the job has already completed successfully.
-2. Run `brew pull --bottle https://jenkins.brew.sh/job/Homebrew%20Testing/1234/` where `https://jenkins.brew.sh/job/Homebrew%20Testing/1234/` is the testing build URL in Jenkins.
-3. Run `git push` to push the commits.
+2. Run `brew pr-pull 12345` where `12345` is the pull request number (or URL).
+3. Amend any relevant commits, then run `git push` to push the commits.
diff --git a/docs/Brew-Test-Bot.md b/docs/Brew-Test-Bot.md
index e72199778c2bfed2d4670144c43fa1e91e5a4943..c176deea231e0ad96e489b21442f374f8270af0b 100644
--- a/docs/Brew-Test-Bot.md
+++ b/docs/Brew-Test-Bot.md
@@ -6,10 +6,9 @@ image: https://brew.sh/assets/img/brewtestbot.png
`brew test-bot` is the name for the automated review and testing system funded
by [our Kickstarter in 2013](https://www.kickstarter.com/projects/homebrew/brew-test-bot).
-It comprises four Mac Minis and three Xserves running in two data centres which host
-[a Jenkins instance at https://jenkins.brew.sh](https://jenkins.brew.sh) and run the
-[`test-bot.rb`](https://github.com/Homebrew/homebrew-test-bot/blob/master/cmd/test-bot.rb)
-Ruby script to perform automated testing of commits to the master branch, pull
+It comprises three Mac Pros hosting virtual machines that run the
+[`test-bot.rb`](https://github.com/Homebrew/homebrew-test-bot/) external
+command to perform automated testing of commits to the master branch, pull
requests and custom builds requested by maintainers.
## Pull Requests
@@ -37,24 +36,5 @@ A passed build looks like this:
---
On failed or passed builds you can click the "Details" link to view the result
-in Jenkins.
+in GitHub Actions.
-A passed build looks like this:
-
-
-
----
-
-A failed build looks like this:
-
-
-
----
-
-You can click the test results link
-(e.g. `brew-test-bot.el_capitan.install openssl`) to
-view the failed test output:
-
-
-
----
diff --git a/docs/Homebrew-homebrew-core-Merge-Checklist.md b/docs/Homebrew-homebrew-core-Merge-Checklist.md
index 44cab7b064f50c8020d2eeb26e1f229084fe2cfa..3f2dc6569e9d393e3016bba132e317755187ebbb 100644
--- a/docs/Homebrew-homebrew-core-Merge-Checklist.md
+++ b/docs/Homebrew-homebrew-core-Merge-Checklist.md
@@ -35,7 +35,6 @@ Check for:
- rebase during merge
- version update follows preferred message format for simple version updates: `foobar 7.3`
- other fixes format is `foobar: fix flibble matrix`
- - you can use `--bump` flag for `brew pull` in case the PR have a single commit but the wrong message
- bottle block is not removed
Suggested reply:
@@ -52,8 +51,11 @@ Check for:
brew bump-revision --message 'for libuv' urbit
```
- make sure it is one commit per revision bump
-- if CI is green and formula `bottle :unneeded` you can merge it through GitHub UI
-- if CI is green and bottles need to be pulled, use: `brew pull --bottle $PR_ID`
+- if CI is green and...
+ - formula `bottle :unneeded`, you can merge it through GitHub UI
+ - bottles need to be pulled, and...
+ - the commits are correct and don't need changes, use: `brew pr-publish $PR_ID`
+ - the commits need to be amended, use `brew pr-pull $PR_ID`, make changes, and `git push`
- don't forget to thank the contributor
- celebrate the first-time contributors
- suggest to use `brew bump-formula-pr` next time if this was not the case
diff --git a/docs/Maintainer-Guidelines.md b/docs/Maintainer-Guidelines.md
index 073ff1d6fdea0091db6c43556581a9ad8f928886..b6f085d8a5a6040d88f2bfd2b04368f6b1756a56 100644
--- a/docs/Maintainer-Guidelines.md
+++ b/docs/Maintainer-Guidelines.md
@@ -27,7 +27,7 @@ This is all that really matters:
- Ensure that any dependencies are accurate and minimal. We don't need to
support every possible optional feature for the software.
- Use the GitHub squash & merge workflow where bottles aren't required.
-- Use `brew pull` otherwise, which adds messages to auto-close pull requests and pull bottles built by the Brew Test Bot.
+- Use `brew pr-publish` or `brew pr-pull` otherwise, which adds messages to auto-close pull requests and pull bottles built by the Brew Test Bot.
- Thank people for contributing.
Checking dependencies is important, because they will probably stick around
@@ -60,7 +60,7 @@ We now accept versioned formulae as long as they [meet the requirements](Version
Merging should be done in the `Homebrew/brew` repository to preserve history & GPG commit signing,
and squash/merge via GitHub should be used for formulae where those formulae
don't need bottles or the change does not require new bottles to be pulled.
-Otherwise, you should use `brew pull` (or `rebase`/`cherry-pick` contributions).
+Otherwise, you should use `brew pr-pull` (or `rebase`/`cherry-pick` contributions).
Don鈥檛 `rebase` until you finally `push`. Once `master` is pushed, you can鈥檛
`rebase`: **you鈥檙e a maintainer now!**
diff --git a/docs/New-Maintainer-Checklist.md b/docs/New-Maintainer-Checklist.md
index 5e2307a3c49faf1701d335162020d9b893cec14d..b9961fa05a02a1c2d52bbdb50d02719a84ffa7e5 100644
--- a/docs/New-Maintainer-Checklist.md
+++ b/docs/New-Maintainer-Checklist.md
@@ -30,12 +30,15 @@ A few requests:
non-trivial (e.g. not a test or audit improvement or version bump) changes
to formulae code and don't merge them unless you get at least one approval
and passing tests.
-- Use `brew pull` for formulae changes that require new bottles or change
- multiple formulae and let it auto-close issues wherever possible (it may
- take ~5m). When this isn't necessary use GitHub's "Merge pull request"
- button in "create a merge commit" mode for Homebrew/brew or "squash and
- merge" for a single formulae change. If in doubt, check with e.g. Fork.app
- that you've not accidentally added merge commits.
+- In Homebrew/brew, close pull requests using GitHub's "Merge pull request"
+ button in "Create a merge commit" mode.
+- In Homebrew/homebrew-core, use `brew pr-publish` to close pull requests
+ that require new bottles or change multiple formulae. If commits need to
+ be amended use `brew pr-pull` instead. Let these commands auto-close
+ issues whenever possible (it may take up to 5 minutes). If in doubt,
+ check with e.g. Fork.app that you've not accidentally added merge commits.
+ If bottles are unnecessary, use GitHub's "Merge pull request" button in
+ "Squash and merge" mode for a single formula change.
- Still create your branches on your fork rather than in the main repository.
Note GitHub's UI will create edits and reverts on the main repository if you
make edits or click "Revert" on the Homebrew/brew repository rather than your
@@ -55,8 +58,6 @@ If they accept, follow a few steps to get them set up:
- Invite them to the [**@Homebrew/maintainers** team](https://github.com/orgs/Homebrew/teams/maintainers) (or any relevant [subteams](https://github.com/orgs/Homebrew/teams/maintainers/teams)) to give them write access to relevant repositories (but don't make them owners). They will need to enable [GitHub's Two Factor Authentication](https://help.github.com/articles/about-two-factor-authentication/).
- Ask them to sign in to [Bintray](https://bintray.com) using their GitHub account and they should auto-sync to [Bintray's Homebrew organisation](https://bintray.com/homebrew/organization/edit/members) as a member so they can publish new bottles.
-- Add them to the [Jenkins' GitHub Authorization Settings admin user names](https://jenkins.brew.sh/configureSecurity/) so they can adjust settings and restart jobs.
-- Add them to the [Jenkins' GitHub Pull Request Builder admin list](https://jenkins.brew.sh/configure) to enable `@BrewTestBot test this please` for them.
- Invite them to the [`homebrew-maintainers` private maintainers mailing list](https://lists.sfconservancy.org/mailman/admin/homebrew-maintainers/members/add).
- Invite them to the [`machomebrew` private maintainers Slack](https://machomebrew.slack.com/admin/invites) (and ensure they've read the [communication guidelines](Maintainer-Guidelines.md#communication)) and ask them to use their real name there (rather than a pseudonym they may use on e.g. GitHub).
- Invite them to the Homebrew Maintainers Monthly Call on Google calendar.