Test Renovate branches directly

- Permit tests to run on branches matching renovate/*, configured the
  same as PR tests. This permits Renovate to pre-test branches, and when
  we're comfortable will permit automatic merging if desired.
- Tell renovate where our actions templates are stored.

Author: rbtcollins

.github/renovate.json

@@ -11,5 +11,10 @@
     },
     "prCreation": "not-pending",
     "rangeStrategy": "replace",
-    "stabilityDays": 3
+    "stabilityDays": 3,
+    "github-actions": {
+        "fileMatch": [
+            "^ci\\/.*/[^/]+\\.ya?ml$"
+        ]
+    }
 }

.github/workflows/centos-fmt-clippy-on-all.yaml

@@ -11,6 +11,7 @@ on:
     branches:
       - master
       - stable
+      - renovate/*
   schedule:
     - cron: "30 0 * * 1" # Every Monday at half past midnight
 

.github/workflows/linux-builds-on-master.yaml

@@ -4,9 +4,9 @@
 name: Linux (master) # skip-pr skip-stable
 
 on:
-  push:         # skip-pr
-    branches:   # skip-pr
-      - master  # skip-pr skip-stable
+  push:            # skip-pr
+    branches:      # skip-pr
+      - master     # skip-pr skip-stable
   schedule: # skip-pr skip-stable
     - cron: "30 0 * * 1" # Every Monday at half past midnight UTC skip-pr skip-stable
 

.github/workflows/linux-builds-on-pr.yaml

@@ -4,9 +4,10 @@
 name: Linux (PR) # skip-master skip-stable
 
 on:
-  pull_request: # skip-master skip-stable
-    branches:   # skip-master skip-stable
-      - "*"     # skip-master skip-stable
+  pull_request:    # skip-master skip-stable
+    branches:      # skip-master skip-stable
+      - "*"        # skip-master skip-stable
+      - renovate/* # skip-master skip-stable
 
 jobs:
   build:

.github/workflows/linux-builds-on-stable.yaml

@@ -4,9 +4,9 @@
 name: Linux (stable) # skip-master skip-pr
 
 on:
-  push:         # skip-pr
-    branches:   # skip-pr
-      - stable  # skip-pr skip-master
+  push:            # skip-pr
+    branches:      # skip-pr
+      - stable     # skip-pr skip-master
 
 jobs:
   build:

.github/workflows/macos-builds-on-all.yaml

@@ -10,6 +10,7 @@ on:
     branches:
       - master
       - stable
+      - renovate/*
   schedule:
     - cron: "30 0 * * 1" # Every Monday at half past midnight UTC
 

.github/workflows/windows-builds-on-master.yaml

@@ -4,9 +4,9 @@
 name: Windows (master) # skip-pr skip-stable
 
 on:
-  push:         # skip-pr
-    branches:   # skip-pr
-      - master  # skip-pr skip-stable
+  push:            # skip-pr
+    branches:      # skip-pr
+      - master     # skip-pr skip-stable
   schedule: # skip-pr skip-stable
     - cron: "30 0 * * 1" # Every Monday at half past midnight UTC skip-pr skip-stable
 

.github/workflows/windows-builds-on-pr.yaml

@@ -4,9 +4,10 @@
 name: Windows (PR) # skip-master skip-stable
 
 on:
-  pull_request: # skip-master skip-stable
-    branches:   # skip-master skip-stable
-      - "*"     # skip-master skip-stable
+  pull_request:    # skip-master skip-stable
+    branches:      # skip-master skip-stable
+      - "*"        # skip-master skip-stable
+      - renovate/* # skip-master skip-stable
 
 jobs:
   build:

.github/workflows/windows-builds-on-stable.yaml

@@ -4,9 +4,9 @@
 name: Windows (stable) # skip-master skip-pr
 
 on:
-  push:         # skip-pr
-    branches:   # skip-pr
-      - stable  # skip-pr skip-master
+  push:            # skip-pr
+    branches:      # skip-pr
+      - stable     # skip-pr skip-master
 
 jobs:
   build:

ci/actions-templates/README.md

@@ -4,12 +4,15 @@ This directory contains all the workflows we use in Rustup for GitHub Actions.
 
 ## Triggers for CI builds
 
-Rustup has four situations in which we perform CI builds:
+Rustup has five situations in which we perform CI builds:
 
 1. On PR changes
 2. On merge to master
 3. Time-based rebuilds of master
 4. Pushes to the stable branch
+5. Renovate branches with dependency updates, tested before opening a PR or
+   merging. They are assessed the same as a PR: if it would be good enough as a
+   human proposed change, its good enough as a robot proposed change.
 
 The goals for each of those situations are subtly different. For PR changes,
 we want to know as quickly as possible if the change is likely to be an issue.