BUG - Ensure coverage comment is triggered (#1879)

It seems the coverage comment workflow was not being triggered due to a
lack of context regarding the original workflow trigger event.

This change should ensure that it accesses the correct context only when
the trigger workflow has been completed successfully.

Author: trallard

.github/workflows/coverage.yml

@@ -8,15 +8,36 @@ on:
 
 jobs:
   test:
-    name: Run tests & display coverage
+    name: "Run tests & display coverage"
     runs-on: ubuntu-latest
-    if: github.event.workflow_run.event == 'pull_request' && github.event.workflow_run.conclusion == 'success'
     permissions:
       pull-requests: write
       contents: write # needed to edit the comment vs opening multiple ones
       actions: read
     steps:
-      - name: Post comment
+      - name: "Get the triggering workflow run details"
+        id: get-run
+        uses: octokit/request-action@v2.x
+        with:
+          route: GET /repos/${{ github.repository }}/actions/runs/${{ github.event.workflow_run.id }}
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      - name: "Check if the trigger was a PR event"
+        run: |
+          TRIGGER_EVENT=$(echo '${{ steps.get-run.outputs.data }}' | jq -r '.event')
+          if [[ "$TRIGGER_EVENT" != "pull_request" ]]; then
+            echo "Workflow was not triggered by a PR, skipping coverage comment."
+            exit 78  # Exiting with a neutral status
+          fi
+      # this needs the .coverage file so we download from the CI workflow artifacts
+      - name: "Download coverage data 📥"
+        uses: actions/download-artifact@v4
+        with:
+          pattern: coverage-data-*
+          merge-multiple: true
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          run-id: ${{ github.event.workflow_run.id }}
+      - name: "Post coverage comment"
         uses: py-cov-action/python-coverage-comment-action@v3
         with:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

docs/community/practices/versions.md

@@ -14,6 +14,7 @@ We define "support" as testing against each of these versions so that users can
 For example, if we made a minor release tomorrow, we'd [look at the EOL schedule for Python](https://endoflife.date/python) and support all the versions that fall within a 3.5-year window.
 
 [^1]: Our support for Python versions is inspired by [NEP 029](https://numpy.org/neps/nep-0029-deprecation_policy.html).
+
 [^2]: These policies are goals, not promises. We are a volunteer-led community with limited time. Consider these sections to be our intention, but we recognize that we may not always be able to meet these criteria if we cannot do so. We welcome contributions from others to help us more sustainably meet these goals!
 
 ## Supported Sphinx versions

docs/user_guide/theme-elements.md

@@ -203,8 +203,11 @@ Here's a numeric footnote[^1], another one (preceded by a space) [^2], a named f
 All will end up as numbers in the rendered HTML, but in the source they look like `[^1]`, `[^2]`, `[^named]` and `[^*]`.
 
 [^1]: Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar.
+
 [^2]: Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar.
+
 [^named]: Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar.
+
 [^*]: Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar. Foo bar foo bar.
 
 ## Link shortening for git repository services