ci,docs: remove bors references after switch to trunk merge queue (#166170)

ci,docs: remove bors references after switch to trunk merge queue

Author: trunk-io[bot]

.github/bors.toml

@@ -1,13 +1,12 @@
 # Trunk configuration file
-# This configuration replicates the bors.toml settings for merge queue functionality
 
 version: 0.1
 
 # CLI configuration
 cli:
   version: 1.22.2
 
-# Merge queue configuration (equivalent to bors.toml)
+# Merge queue configuration
 merge:
   # Use Trunk's merge queue service
   service: queue

.trunk/trunk.yaml

@@ -25,7 +25,7 @@ change, as they can cause merge conflicts in ongoing development.
    commit message is the primary record, not the PR description.
    Include release note annotations.
 7. Push and [create a PR](https://help.github.com/articles/creating-a-pull-request).
-8. Merge via `bors r+` (not the green button).
+8. Merge via the merge queue.
 
 ## Code Review
 

CONTRIBUTING.md

@@ -266,9 +266,9 @@ tc_release_branch() {
   [[ "$branch" == master || "$branch" == release-* || "$branch" == provisional_*  || "$branch" == "staging-"* ]]
 }
 
-tc_bors_branch() {
+is_trunk_branch() {
   branch=$(tc_build_branch)
-  [[ "$branch" == staging ]]
+  [[ "$branch" == trunk-merge/* ]]
 }
 
 if_tc() {

build/teamcity-support.sh

@@ -16,8 +16,8 @@ bazel build //pkg/cmd/bazci
 
 EXTRA_PARAMS=""
 
-if tc_bors_branch; then
-  # enable up to 1 retry (2 attempts, worst-case) per test executable to report flakes but only on release branches and staging.
+if tc_release_branch || is_trunk_branch; then
+  # enable up to 1 retry (2 attempts, worst-case) per test executable to report flakes on release/trunk branches.
   EXTRA_PARAMS=" --flaky_test_attempts=2"
 fi
 

build/teamcity/cockroach/ci/tests-aws-linux-arm64-bigvm/unit_tests_impl.sh

@@ -13,19 +13,16 @@ dir="$(dirname $(dirname $(dirname $(dirname $(dirname "${0}")))))"
 source "$dir/teamcity-support.sh"  # For $root, changed_go_pkgs
 source "$dir/teamcity-bazel-support.sh"  # For run_bazel
 
-# The full race suite takes >4h and is only suitable for nightlies. On master
-# and staging, run just the `server` package which (at the time of writing)
+# The full race suite takes >4h and is only suitable for nightlies. On release
+# branches, run just the `server` package which (at the time of writing)
 # takes <30m to run and exercises most of the code in the system at least
-# rudimentarily. This (hopefully) causes obvious races to fail in bors,
+# rudimentarily. This (hopefully) causes obvious races to fail early,
 # before spraying failures over the nightly stress suite.
 canaryspec=./pkg/server
 tc_start_block "Determine changed packages"
-if tc_release_branch; then
+if tc_release_branch || is_trunk_branch; then
   pkgspec="${canaryspec}"
-  echo "On release branch ($TC_BUILD_BRANCH), so running canary testrace ($pkgspec)"
-elif tc_bors_branch; then
-  pkgspec="${canaryspec}"
-  echo "On bors branch ($TC_BUILD_BRANCH), so running canary testrace ($pkgspec)"
+  echo "On release/trunk branch ($TC_BUILD_BRANCH), so running canary testrace ($pkgspec)"
 else
   pkgspec=$(changed_go_pkgs)
   if [[ $(echo "$pkgspec" | wc -w) -gt 10 ]]; then

build/teamcity/cockroach/ci/tests/testrace.sh

@@ -70,4 +70,4 @@ If Blathers was unable to automatically create a backport PR, follow these steps
    2. If there were any non-trivial merge conflicts, be sure to call those out in the PR message so reviewers can pay closer attention to the diff.
    3. If something goes wrong, you can use `backport --abort` to give up on the current manual backport.
 
-Note: **You do not need to use bors** to merge a backport PR; just hit the big green button once the CI is green and the backport is approved by the reviewer (usually the main reviewer of the original PR to `master` branch). But note that if the backport has been open and unmerged for many days, CI results could be stale, and might not reflect the current state of the release branch. If the backport has been open and unmerged for many days, be sure to **rebase the backport PR on the tip of the release branch before merging** to get an up-to-date CI run.
+Note: Some release branches may have the Trunk merge queue enabled. If so, use the merge queue to merge the backport PR. Otherwise, just hit the big green button once the CI is green and the backport is approved by the reviewer (usually the main reviewer of the original PR to `master` branch). But note that if the backport has been open and unmerged for many days, CI results could be stale, and might not reflect the current state of the release branch. If the backport has been open and unmerged for many days, be sure to **rebase the backport PR on the tip of the release branch before merging** to get an up-to-date CI run.