🔄 synced file(s) with conda/infrastructure (#242)

Co-authored-by: Conda Bot <conda-bot@users.noreply.github.com>
conda · May 13, 2024 · ea6f4d1 · ea6f4d1
1 parent 2b0d7dd
commit ea6f4d1
Show file tree

Hide file tree

Showing 7 changed files with 76 additions and 46 deletions.
diff --git a/.github/workflows/cla.yml b/.github/workflows/cla.yml
@@ -18,7 +18,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Check CLA
-        uses: conda/actions/check-cla@1e442e090ad28c9b0f85697105703a303320ffd1
+        uses: conda/actions/check-cla@976289d0cfd85139701b26ddd133abdd025a7b5f # v24.5.0
         with:
           # [required]
           # A token with ability to comment, label, and modify the commit status

diff --git a/.github/workflows/issues.yml b/.github/workflows/issues.yml
@@ -23,12 +23,12 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       # remove [pending::feedback]
-      - uses: actions-ecosystem/action-remove-labels@2ce5d41b4b6aa8503e285553f75ed56e0a40bae0
+      - uses: actions-ecosystem/action-remove-labels@2ce5d41b4b6aa8503e285553f75ed56e0a40bae0 # v1.3.0
         with:
           labels: ${{ env.FEEDBACK_LBL }}
           github_token: ${{ secrets.PROJECT_TOKEN }}
       # add [pending::support], if still open
-      - uses: actions-ecosystem/action-add-labels@18f1af5e3544586314bbe15c0273249c770b2daf
+      - uses: actions-ecosystem/action-add-labels@18f1af5e3544586314bbe15c0273249c770b2daf # v1.1.3
         if: github.event.issue.state == 'open'
         with:
           labels: ${{ env.SUPPORT_LBL }}

diff --git a/.github/workflows/labels.yml b/.github/workflows/labels.yml
@@ -19,20 +19,20 @@ jobs:
       GLOBAL: https://raw.githubusercontent.com/conda/infra/main/.github/global.yml
       LOCAL: .github/labels.yml
     steps:
-      - uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b
+      - uses: actions/checkout@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b # v4.1.5
       - id: has_local
-        uses: andstor/file-existence-action@076e0072799f4942c8bc574a82233e1e4d13e9d6
+        uses: andstor/file-existence-action@076e0072799f4942c8bc574a82233e1e4d13e9d6 # v3.0.0
         with:
           files: ${{ env.LOCAL }}
       - name: Global Only
-        uses: EndBug/label-sync@52074158190acb45f3077f9099fea818aa43f97a
+        uses: EndBug/label-sync@52074158190acb45f3077f9099fea818aa43f97a # v2.3.3
         if: steps.has_local.outputs.files_exists == 'false'
         with:
           config-file: ${{ env.GLOBAL }}
           delete-other-labels: true
           dry-run: ${{ github.event.inputs.dryrun }}
       - name: Global & Local
-        uses: EndBug/label-sync@52074158190acb45f3077f9099fea818aa43f97a
+        uses: EndBug/label-sync@52074158190acb45f3077f9099fea818aa43f97a # v2.3.3
         if: steps.has_local.outputs.files_exists == 'true'
         with:
           config-file: |

diff --git a/.github/workflows/lock.yml b/.github/workflows/lock.yml
@@ -17,7 +17,7 @@ jobs:
     if: '!github.event.repository.fork'
     runs-on: ubuntu-latest
     steps:
-      - uses: dessant/lock-threads@1bf7ec25051fe7c00bdd17e6a7cf3d7bfb7dc771
+      - uses: dessant/lock-threads@1bf7ec25051fe7c00bdd17e6a7cf3d7bfb7dc771 # v5.0.1
         with:
           # Number of days of inactivity before a closed issue is locked
           issue-inactive-days: 365

diff --git a/.github/workflows/project.yml b/.github/workflows/project.yml
@@ -13,7 +13,7 @@ jobs:
     if: '!github.event.repository.fork'
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/add-to-project@9bfe908f2eaa7ba10340b31e314148fcfe6a2458
+      - uses: actions/add-to-project@9bfe908f2eaa7ba10340b31e314148fcfe6a2458 # v1.0.1
         with:
           # issues are added to the Planning project
           # PRs are added to the Review project

diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
@@ -33,12 +33,12 @@ jobs:
             days-before-issue-stale: 90
             days-before-issue-close: 21
     steps:
-      - uses: conda/actions/read-yaml@1e442e090ad28c9b0f85697105703a303320ffd1
+      - uses: conda/actions/read-yaml@976289d0cfd85139701b26ddd133abdd025a7b5f # v24.5.0
         id: read_yaml
         with:
           path: https://raw.githubusercontent.com/conda/infra/main/.github/messages.yml
 
-      - uses: actions/stale@28ca1036281a5e5922ead5184a1bbf96e5fc984e
+      - uses: actions/stale@28ca1036281a5e5922ead5184a1bbf96e5fc984e # v9.0.0
         id: stale
         with:
           # Only issues with these labels are checked whether they are stale

diff --git a/RELEASE.md b/RELEASE.md
@@ -14,18 +14,18 @@
 
 # Release Process
 
-> **Note:**
+> [!NOTE]
 > Throughout this document are references to the version number as `YY.M.[$patch_number]`, this should be replaced with the correct version number. Do **not** prefix the version with a lowercase `v`.
 
 ## 1. Open the release issue and cut a release branch. (do this ~1 week prior to release)
 
-> **Note:**
+> [!NOTE]
 > The new release branch should adhere to the naming convention of `YY.M.x` (make sure to put the `.x` at the end!). In the case of patch/hotfix releases, however, do NOT cut a new release branch; instead, use the previously-cut release branch with the appropriate `YY.M.x` version numbers.
 
 Use the issue template below to create the release issue. After creating the release issue, pin it for easy access.
 
 <details>
-<summary><code>GitHub Issue Template</code></summary>
+<summary><h3>Release Template</h3></summary>
 
 ```markdown
 ### Summary
@@ -45,18 +45,23 @@ Placeholder for `{{ repo.name }} YY.M.x` release.
 [conda-forge]: https://github.com/conda-forge/{{ repo.name }}-feedstock
 [ReadTheDocs]: https://readthedocs.com/projects/continuumio-{{ repo.name }}/
 
-#### The week before release week
+<details open>  <!-- feel free to remove the open attribute once this section is completed -->
+<summary><h4>The week before release week</h4></summary>
 
 - [ ] Create release branch (named `YY.M.x`)
 - [ ] Ensure release candidates are being successfully built (see `conda-canary/label/rc-{{ repo.name }}-YY.M.x`)
 - [ ] [Complete outstanding PRs][milestone]
 - [ ] Test release candidates
     <!-- indicate here who has signed off on testing -->
 
-#### Release week
+</details>
+
+<details open>  <!-- feel free to remove the open attribute once this section is completed -->
+<summary><h4>Release week</h4></summary>
 
 - [ ] Create release PR (see [release process][process])
 - [ ] [Publish release][releases]
+- [ ] Merge `YY.M.x` back into `main`
 - [ ] Activate the `YY.M.x` branch on [ReadTheDocs][ReadTheDocs]
 - [ ] Feedstocks
     - [ ] Bump version & update dependencies/tests in [Anaconda, Inc.'s feedstock][main]
@@ -72,22 +77,56 @@ Placeholder for `{{ repo.name }} YY.M.x` release.
         - [ ] [Matrix (conda/conda)](https://matrix.to/#/#conda_conda:gitter.im) (this auto posts from Discourse)
     - Summary
         - [ ] [Twitter](https://twitter.com/condaproject)
+
+</details>
 ```
 </details>
 
-> **Note:**
+If a patch release is necessary, reopen the original release issue and append the following template to the release issue summary.
+
+<details>
+<summary><h3>Patch Release Template</h3></summary>
+
+```markdown
+<details open>  <!-- feel free to remove the open attribute once this section is completed -->
+<summary><h4>Patch YY.M.N</h4></summary>
+
+- [ ] <!-- list issues & PRs that need to be resolved here -->
+- [ ] Create release PR (see [release process][process])
+- [ ] [Publish release][releases]
+- [ ] Merge `YY.M.x` back into `main`
+- [ ] Feedstocks
+    - [ ] Bump version & update dependencies/tests in [Anaconda, Inc.'s feedstock][main]
+    - [ ] Bump version & update dependencies/tests in [conda-forge feedstock][conda-forge]
+- [ ] Hand off to the Anaconda packaging team
+
+</details>
+```
+
+</details>
+
+> [!NOTE]
 > The [epic template][epic template] is perfect for this; remember to remove the **`epic`** label.
 
 ## 2. Alert various parties of the upcoming release. (do this ~1 week prior to release)
 
 Let various interested parties know about the upcoming release; at minimum, conda-forge maintainers should be informed. For major features, a blog post describing the new features should be prepared and posted once the release is completed (see the announcements section of the release issue).
 
-## 3. Ensure `rever.xsh` and `news/TEMPLATE` are up to date.
+## 3. Manually test canary build(s).
+
+### Canary Builds for Manual Testing
+
+Once the release PRs are filed, successful canary builds will be available on `https://anaconda.org/conda-canary/conda/files?channel=rc-{{ repo.name }}-YY.M.x` for manual testing.
+
+> [!NOTE]
+> You do not need to apply the `build::review` label for release PRs; every commit to the release branch builds and uploads canary builds to the respective `rc-` label.
+
+## 4. Ensure `rever.xsh` and `news/TEMPLATE` are up to date.
 
 These are synced from [`conda/infrastructure`][infrastructure].
 
 <details>
-<summary><h2>4. Run rever. (ideally done on the Monday of release week)</h2></summary>
+<summary><h2>5. Run rever. (ideally done on the Monday of release week)</h2></summary>
 
 Currently, there are only 2 activities we use rever for, (1) aggregating the authors and (2) updating the changelog. Aggregating the authors can be an error-prone process and also suffers from builtin race conditions (_i.e._, to generate an updated `.authors.yml` we need an updated `.mailmap` but to have an updated `.mailmap` we need an updated `.authors.yml`). This is why the following steps are very heavy-handed (and potentially repetitive) in running rever commands, undoing commits, squashing/reordering commits, etc.
 
@@ -119,9 +158,9 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut
     (rever) $ git checkout -b changelog-YY.M.[$patch_number]
     ```
 
-2. Run `rever --activities authors`:
+2. Run `rever --activities authors <VERSION>`:
 
-    > **Note:**
+    > **Note:** <!-- GH doesn't support nested admonitions, see https://github.com/orgs/community/discussions/16925 -->
     > Include `--force` when re-running any rever commands for the same `<VERSION>`, otherwise, rever will skip the activity and no changes will be made (i.e., rever remembers if an activity has been run for a given version).
 
     ```bash
@@ -166,7 +205,7 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut
         (rever) $ git commit -m "Update .authors.yml"
         ```
 
-    - Rerun `rever --activities authors` and finally check that your `.mailmap` is correct by running:
+    - Rerun `rever --activities authors --force <VERSION>` and finally check that your `.mailmap` is correct by running:
 
         ```bash
         git shortlog -se
@@ -194,15 +233,15 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut
     - Continue repeating the above processes until the `.authors.yml` and `.mailmap` are corrected to your liking. After completing this, you will have at most two commits on your release branch:
 
         ```bash
-        (rever) $ git cherry -v main
+        (rever) $ git cherry -v <release branch>
         + 86957814cf235879498ed7806029b8ff5f400034 Update .authors.yml
         + 3ec7491f2f58494a62f1491987d66f499f8113ad Update .mailmap
         ```
 
 
 4. Review news snippets (ensure they are all using the correct Markdown format, **not** reStructuredText) and add additional snippets for undocumented PRs/changes as necessary.
 
-    > **Note:**
+    > **Note:** <!-- GH doesn't support nested admonitions, see https://github.com/orgs/community/discussions/16925 -->
     > We've found it useful to name news snippets with the following format: `<PR #>-<DESCRIPTIVE SLUG>`.
     >
     > We've also found that we like to include the PR #s inline with the text itself, e.g.:
@@ -213,7 +252,7 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut
     > * Add `win-arm64` as a known platform (subdir). (#11778)
     > ```
 
-    - You can utilize [GitHub's compare view][compare] to review what changes are to be included in this release.
+    - You can utilize [GitHub's compare view][compare] to review what changes are to be included in this release. Make sure you compare the current release branch against the previous one (e.g., `24.5.x` would be compared against `24.3.x`)
 
     - Add a new news snippet for any PRs of importance that are missing.
 
@@ -227,15 +266,15 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut
     - After completing this, you will have at most three commits on your release branch:
 
         ```bash
-        (rever) $ git cherry -v main
+        (rever) $ git cherry -v <release branch>
         + 86957814cf235879498ed7806029b8ff5f400034 Update .authors.yml
         + 3ec7491f2f58494a62f1491987d66f499f8113ad Update .mailmap
         + 432a9e1b41a3dec8f95a7556632f9a93fdf029fd Update news
         ```
 
 5. Run `rever --activities changelog`:
 
-    > **Note:**
+    > **Note:** <!-- GH doesn't support nested admonitions, see https://github.com/orgs/community/discussions/16925 -->
     > This has previously been a notoriously fickle step (likely due to incorrect regex patterns in the `rever.xsh` config file and missing `github` keys in `.authors.yml`) so beware of potential hiccups. If this fails, it's highly likely to be an innocent issue.
 
     ```bash
@@ -254,7 +293,7 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut
     - After completing this, you will have at most three commits on your release branch:
 
         ```bash
-        (rever) $ git cherry -v main
+        (rever) $ git cherry -v <release branch>
         + 86957814cf235879498ed7806029b8ff5f400034 Update .authors.yml
         + 3ec7491f2f58494a62f1491987d66f499f8113ad Update .mailmap
         + 432a9e1b41a3dec8f95a7556632f9a93fdf029fd Update news
@@ -269,7 +308,7 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut
     - After completing this, you will have at most five commits on your release branch:
 
         ```bash
-        (rever) $ git cherry -v main
+        (rever) $ git cherry -v <release branch>
         + 86957814cf235879498ed7806029b8ff5f400034 Update .authors.yml
         + 3ec7491f2f58494a62f1491987d66f499f8113ad Update .mailmap
         + 432a9e1b41a3dec8f95a7556632f9a93fdf029fd Update news
@@ -291,7 +330,7 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut
     - After completing this, you will have at most six commits on your release branch:
 
         ```bash
-        (rever) $ git cherry -v main
+        (rever) $ git cherry -v <release branch>
         + 86957814cf235879498ed7806029b8ff5f400034 Update .authors.yml
         + 3ec7491f2f58494a62f1491987d66f499f8113ad Update .mailmap
         + 432a9e1b41a3dec8f95a7556632f9a93fdf029fd Update news
@@ -325,7 +364,7 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut
 
 11. [Create][new release] the release and **SAVE AS A DRAFT** with the following values:
 
-    > **Note:**
+    > **Note:** <!-- GH doesn't support nested admonitions, see https://github.com/orgs/community/discussions/16925 -->
     > Only publish the release after the release PR is merged, until then always **save as draft**.
 
     | Field | Value |
@@ -336,22 +375,13 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut
 
 </details>
 
-## 5. Wait for review and approval of release PR.
-
-## 6. Manually test canary build(s).
-
-### Canary Builds for Manual Testing
-
-Once the release PRs are filed, successful canary builds will be available on `https://anaconda.org/conda-canary/conda/files?channel=rc-{{ repo.name }}-YY.M.x` for manual testing.
-
-> **Note:**
-> You do not need to apply the `build::review` label for release PRs; every commit to the release branch builds and uploads canary builds to the respective `rc-` label.
+## 6. Wait for review and approval of release PR.
 
 ## 7. Merge release PR and publish release.
 
 To publish the release, go to the project's release page (e.g., https://github.com/conda/conda/releases) and add the release notes from `CHANGELOG.md` to the draft release you created earlier. Then publish the release.
 
-> **Note:**
+> [!NOTE]
 > Release notes can be drafted and saved ahead of time.
 
 ## 8. Merge/cherry pick the release branch over to the `main` branch.
@@ -367,19 +397,19 @@ To publish the release, go to the project's release page (e.g., https://github.c
 
 4. Ensure that all of the commits being pulled in look accurate, then select "Create pull request".
 
-> **Note:**
+> [!NOTE]
 > Make sure NOT to push the "Update Branch" button. If there are [merge conflicts][merge conflicts], create a temporary "connector branch" dedicated to fixing merge conflicts separately from the `YY.M.x` and `main` branches.
 
 5. Review and merge the pull request the same as any code change pull request.
 
-> **Note:**
+> [!NOTE]
 > The commits from the release branch need to be retained in order to be able to compare individual commits; in other words, a "merge commit" is required when merging the resulting pull request vs. a "squash merge". Protected branches will require permissions to be temporarily relaxed in order to enable this action.
 
 </details>
 
 ## 9. Open PRs to bump [Anaconda Recipes][Anaconda Recipes] and [conda-forge][conda-forge] feedstocks to use `YY.M.[$patch_number]`.
 
-> **Note:**
+> [!NOTE]
 > Conda-forge's PRs will be auto-created via the `regro-cf-autotick-bot`. Follow the instructions below if any changes need to be made to the recipe that were not automatically added (these instructions are only necessary for anyone who is _not_ a conda-forge feedstock maintainer, since maintainers can push changes directly to the autotick branch):
 > - Create a new branch based off of autotick's branch (autotick's branches usually use the `regro-cf-autotick-bot:XX.YY.[$patch_number]_[short hash]` syntax)
 > - Add any changes via commits to that new branch
@@ -392,7 +422,7 @@ To publish the release, go to the project's release page (e.g., https://github.c
 
 ## 10. Hand off to Anaconda's packaging team.
 
-> **Note:**
+> [!NOTE]
 > This step should NOT be done past Thursday morning EST; please start the process on a Monday, Tuesday, or Wednesday instead in order to avoid any potential debugging sessions over evenings or weekends.
 
 <details>