Merge branch 'main' into sophie-5758

Author: sophietheking

.github/workflows/azure-preview-env-deploy.yml

@@ -34,7 +34,7 @@ permissions:
 
 # This allows one deploy workflow to interrupt another
 concurrency:
-  group: '${{ github.workflow }} @ ${{ github.event.pull_request.head.label }}'
+  group: 'preview-env @ ${{ github.head_ref || github.run_id }} for ${{ github.event.number || github.event.inputs.PR_NUMBER }}'
   cancel-in-progress: true
 
 jobs:

.github/workflows/azure-preview-env-destroy.yml

@@ -19,6 +19,11 @@ on:
 permissions:
   contents: read
 
+# This allows one deploy workflow to interrupt another
+concurrency:
+  group: 'preview-env @ ${{ github.head_ref || github.run_id }} for ${{ github.event.number || github.event.inputs.PR_NUMBER }}'
+  cancel-in-progress: true
+
 jobs:
   destory-azure-preview-env:
     name: Destroy

.github/workflows/optimize-images.yml

@@ -41,10 +41,10 @@ jobs:
           git checkout $GITHUB_HEAD_REF
 
           echo "List the files that changed"
-          git diff --name-only $GITHUB_HEAD_REF $GITHUB_BASE_REF
+          git diff --name-only --diff-filter=d $GITHUB_BASE_REF $GITHUB_HEAD_REF
 
           echo "Run optipng on pngs in from the diff"
-          git diff --name-only -z $GITHUB_HEAD_REF $GITHUB_BASE_REF -- '*.png' | xargs -0 optipng -nx
+          git diff --name-only -z --diff-filter=d $GITHUB_BASE_REF $GITHUB_HEAD_REF -- '*.png' | xargs -0 optipng -nx
 
       - name: Make a commit and a push
         run: |

assets/images/help/education/reverify-academic-affiliation.png

@@ -1,5 +1,3 @@
-@import "@primer/css/layout/index.scss";
-
 .sectionHeading {
   scroll-margin-top: 70px !important;
 }

components/release-notes/PatchNotes.module.scss

@@ -85,7 +85,7 @@ jobs:
     runs-on: ubuntu-latest
     strategy:
       matrix:
-        dotnet: [ '3.0', '3.1.x', '5.0.x' ]
+        dotnet-version: [ '3.0', '3.1.x', '5.0.x' ]
 
     steps:
       - uses: actions/checkout@v2

content/actions/automating-builds-and-tests/building-and-testing-net.md

@@ -206,7 +206,9 @@ The `github` context contains information about the workflow run and the event t
 | `github.retention_days` | `string` | The number of days that workflow run logs and artifacts are kept. |
 | `github.run_id` | `string` | {% data reusables.actions.run_id_description %} |
 | `github.run_number` | `string` | {% data reusables.actions.run_number_description %} |
+{%- ifversion fpt or ghec or ghes > 3.5 or ghae-issue-4722 %}
 | `github.run_attempt` | `string` | A unique number for each attempt of a particular workflow run in a repository. This number begins at 1 for the workflow run's first attempt, and increments with each re-run. |
+{% endif %}
 | `github.server_url` | `string` | The URL of the GitHub server. For example: `https://github.com`. |
 | `github.sha` | `string` | The commit SHA that triggered the workflow run. |
 | `github.token` | `string` | A token to authenticate on behalf of the GitHub App installed on your repository. This is functionally equivalent to the `GITHUB_TOKEN` secret. For more information, see "[Automatic token authentication](/actions/security-guides/automatic-token-authentication)." |

content/actions/learn-github-actions/contexts.md

@@ -38,7 +38,7 @@ You can configure a {% data variables.product.prodname_actions %} _workflow_ to
 
 A workflow is a configurable automated process that will run one or more jobs.  Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.
 
-Your repository can have multiple workflows in a repository, each of which can perform a different set of steps.  For example, you can have one workflow to build and test pull requests, another workflow to deploy your application every time a release is created, and still another workflow that adds a label every time someone opens a new issue.
+You can have multiple workflows in a repository, each of which can perform a different set of steps.  For example, you can have one workflow to build and test pull requests, another workflow to deploy your application every time a release is created, and still another workflow that adds a label every time someone opens a new issue.
 
 {% ifversion fpt or ghes > 3.3 or ghae-issue-4757 or ghec %}You can reference a workflow within another workflow, see "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)."{% endif %}
 
@@ -266,4 +266,4 @@ To understand how billing works for {% data variables.product.prodname_actions %
 ## Further reading
 
 {% ifversion ghec or ghes or ghae %}
-- "[About {% data variables.product.prodname_actions %} for enterprises](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/about-github-actions-for-enterprises)"{% endif %}
+- "[About {% data variables.product.prodname_actions %} for enterprises](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/about-github-actions-for-enterprises)"{% endif %}

content/actions/learn-github-actions/understanding-github-actions.md

@@ -685,6 +685,25 @@ on:
 
 {% endnote %}
 
+#### Running your workflow when a pull request merges
+
+When a pull request merges, the pull request is automatically closed. To run a workflow when a pull request merges, use the `pull_request` `closed` event type along with a conditional that checks the `merged` value of the event. For example, the following workflow will run whenever a pull request closes. The `if_merged` job will only run if the pull request was also merged.
+
+```yaml
+on:
+  pull_request:
+    types:
+      - closed
+
+jobs:
+  if_merged:
+    if: github.event.pull_request.merged == true
+    runs-on: ubuntu-latest
+    steps:
+    - run: |
+        echo The PR was merged
+```
+
 {% data reusables.developer-site.pull_request_forked_repos_link %}
 
 ### `pull_request_comment` (use `issue_comment`)
@@ -869,6 +888,25 @@ on:
 
 {% endnote %}
 
+#### Running your workflow when a pull request merges
+
+When a pull request merges, the pull request is automatically closed. To run a workflow when a pull request merges, use the `pull_request_target` `closed` event type along with a conditional that checks the `merged` value of the event. For example, the following workflow will run whenever a pull request closes. The `if_merged` job will only run if the pull request was also merged.
+
+```yaml
+on:
+  pull_request_target:
+    types:
+      - closed
+
+jobs:
+  if_merged:
+    if: github.event.pull_request_target.merged == true
+    runs-on: ubuntu-latest
+    steps:
+    - run: |
+        echo The PR was merged
+```
+
 ### `push`
 
 | Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |

content/actions/using-workflows/events-that-trigger-workflows.md

@@ -56,12 +56,6 @@ topics:
 
 {% data reusables.enterprise-accounts.dormant-user-release-phase %}
 
-{% warning %}
-
-**Note:** During the private beta, ongoing improvements to the report download feature may limit its availability.
-
-{% endwarning %}
-
 ## Downloading the dormant users report from your enterprise account
 
 {% data reusables.enterprise-accounts.access-enterprise %}