docs: Update for new pr-* workflows

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).
 
 [![Powered by MacStadium](https://cloud.githubusercontent.com/assets/125011/22776032/097557ac-eea6-11e6-8ba8-eff22dfd58f1.png)](https://www.macstadium.com)
 

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!
 

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.

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:
-
-![Passed Jenkins Build](assets/img/docs/brew-test-bot-passed-jenkins.png)
-
----
-
-A failed build looks like this:
-
-![Failed Jenkins Build](assets/img/docs/brew-test-bot-failed-jenkins.png)
-
----
-
-You can click the test results link
-(e.g. `brew-test-bot.el_capitan.install openssl`) to
-view the failed test output:
-
-![Failed Test](assets/img/docs/brew-test-bot-failed-test.png)
-
----

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

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’t `rebase` until you finally `push`. Once `master` is pushed, you can’t
 `rebase`: **you’re a maintainer now!**

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.