Merge branch 'main' into patch-2

Author: mchammer01

.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: |

components/release-notes/PatchNotes.module.scss

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

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

@@ -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/learn-github-actions/understanding-github-actions.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/using-workflows/events-that-trigger-workflows.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/code-security/code-scanning/using-codeql-code-scanning-with-your-existing-ci-system/configuring-codeql-cli-in-your-ci-system.md

@@ -223,7 +223,7 @@ When you have decided on the most secure and reliable method for your CI server,
 | Option | Required | Usage |
 |--------|:--------:|-----|
 | <nobr>`--repository`</nobr> | {% octicon "check-circle-fill" aria-label="Required" %} | Specify the *OWNER/NAME* of the repository to upload data to. The owner must be an organization within an enterprise that has a license for {% data variables.product.prodname_GH_advanced_security %} and {% data variables.product.prodname_GH_advanced_security %} must be enabled for the repository{% ifversion fpt or ghec %}, unless the repository is public{% endif %}. For more information, see "[Managing security and analysis settings for your repository](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository)."
-| <nobr>`--ref`</nobr> | {% octicon "check-circle-fill" aria-label="Required" %} | Specify the name of the `ref` you checked out and analyzed so that the results can be matched to the correct code. For a branch use: `refs/heads/BRANCH-NAME`, for the head commit of a pull request use `refs/pulls/NUMBER/head`, or for the {% data variables.product.prodname_dotcom %}-generated merge commit of a pull request use `refs/pulls/NUMBER/merge`.
+| <nobr>`--ref`</nobr> | {% octicon "check-circle-fill" aria-label="Required" %} | Specify the name of the `ref` you checked out and analyzed so that the results can be matched to the correct code. For a branch use: `refs/heads/BRANCH-NAME`, for the head commit of a pull request use `refs/pull/NUMBER/head`, or for the {% data variables.product.prodname_dotcom %}-generated merge commit of a pull request use `refs/pull/NUMBER/merge`.
 | <nobr>`--commit`</nobr> | {% octicon "check-circle-fill" aria-label="Required" %} | Specify the full SHA of the commit you analyzed.
 | <nobr>`--sarif`</nobr> | {% octicon "check-circle-fill" aria-label="Required" %} | Specify the SARIF file to load.{% ifversion ghes > 3.0 or ghae %}
 | <nobr>`--github-url`</nobr> | {% octicon "check-circle-fill" aria-label="Required" %} | Specify the URL for {% data variables.product.product_name %}.{% endif %}

content/code-security/code-scanning/using-codeql-code-scanning-with-your-existing-ci-system/migrating-from-the-codeql-runner-to-codeql-cli.md

@@ -53,7 +53,7 @@ These examples also assume that the {% data variables.product.prodname_codeql_cl
 
 In these examples, a {% data variables.product.prodname_dotcom %} token with suitable scopes is stored in the `$TOKEN` environment variable and passed to the example commands via `stdin`, or is stored in the `$GITHUB_TOKEN` environment variable.
 
-The ref name and commit SHA being checked out and analyzed in these examples are known during the workflow. For a branch, use `refs/heads/BRANCH-NAME` as the ref. For the head commit of a pull request, use `refs/pulls/NUMBER/head`. For a {% data variables.product.prodname_dotcom %}-generated merge commit of a pull request, use `refs/pulls/NUMBER/merge`. The examples below all use `refs/heads/main`. If you use a different branch name, you must modify the sample code.
+The ref name and commit SHA being checked out and analyzed in these examples are known during the workflow. For a branch, use `refs/heads/BRANCH-NAME` as the ref. For the head commit of a pull request, use `refs/pull/NUMBER/head`. For a {% data variables.product.prodname_dotcom %}-generated merge commit of a pull request, use `refs/pull/NUMBER/merge`. The examples below all use `refs/heads/main`. If you use a different branch name, you must modify the sample code.
 
 ### Single non-compiled language (JavaScript)
 

content/get-started/quickstart/hello-world.md

@@ -26,27 +26,28 @@ In this quickstart guide, you will:
 * Make changes to a file and push them to {% data variables.product.product_name %} as commits
 * Open and merge a pull request
 
-To complete this tutorial, you need a [{% data variables.product.product_name %} account](http://github.com) and Internet access. You don't need to know how to code, use the command line, or install Git (the version control software that {% data variables.product.product_name %} is built on).
+To complete this tutorial, you need a [{% data variables.product.product_name %} account](http://github.com) and Internet access. You don't need to know how to code, use the command line, or install Git (the version control software that {% data variables.product.product_name %} is built on). If you have a question about any of the expressions used in this guide, head on over to the [glossary](/get-started/quickstart/github-glossary) to find out more about our terminology.
 
 ## Creating a repository
 
-A repository is usually used to organize a single project. Repositories can contain folders and files, images, videos, spreadsheets, and data sets -- anything your project needs. Often, repositories include a `README` file, a file with information about your project. {% data variables.product.product_name %} makes it easy to add one at the same time you create your new repository. It also offers other common options such as a license file.
+A repository is usually used to organize a single project. Repositories can contain folders and files, images, videos, spreadsheets, and data sets -- anything your project needs. Often, repositories include a _README_ file, a file with information about your project. _README_ files are written in the plain text Markdown language. You can use this [cheat sheet](https://www.markdownguide.org/cheat-sheet/) to get started with Markdown syntax. {% data variables.product.product_name %} lets you add a _README_ file at the same time you create your new repository. {% data variables.product.product_name %} also offers other common options such as a license file, but you do not have to select any of them now.
 
 Your `hello-world` repository can be a place where you store ideas, resources, or even share and discuss things with others.
 
 {% data reusables.repositories.create_new %}
 1. In the **Repository name** box, enter `hello-world`.
 2. In the **Description** box, write a short description.
 3. Select **Add a README file**.
-4. Click **Create repository**.
+4. Select whether your repository will be **Public** or **Private**.
+5. Click **Create repository**.
 
    ![Create a hello world repository](/assets/images/help/repository/hello-world-repo.png)
 
 ## Creating a branch
 
 Branching lets you have different versions of a repository at one time.
 
-By default, your repository has one branch named `main` that is considered to be the definitive branch. You can use branches to experiment and make edits before committing them to `main`.
+By default, your repository has one branch named `main` that is considered to be the definitive branch. You can create additional branches off of `main` in your repository. You can use branches to have different versions of a project at one time. This is helpful when you want to add new features to a project without changing the main source of code. The work done on different branches will not show up on the main branch until you merge it, which we will cover later in this guide. You can use branches to experiment and make edits before committing them to `main`.
 
 When you create a branch off the `main` branch, you're making a copy, or snapshot, of `main` as it was at that point in time. If someone else made changes to the `main` branch while you were working on your branch, you could pull in those updates.
 
@@ -61,8 +62,8 @@ This diagram shows:
 Have you ever saved different versions of a file? Something like:
 
 * `story.txt`
-* `story-joe-edit.txt`
-* `story-joe-edit-reviewed.txt`
+* `story-edit.txt`
+* `story-edit-reviewed.txt`
 
 Branches accomplish similar goals in {% data variables.product.product_name %} repositories.
 
@@ -86,9 +87,9 @@ When you created a new branch in the previous step, {% data variables.product.pr
 
 You can make and save changes to the files in your repository. On {% data variables.product.product_name %}, saved changes are called commits. Each commit has an associated commit message, which is a description explaining why a particular change was made. Commit messages capture the history of your changes so that other contributors can understand what you’ve done and why.
 
-1. Click the `README.md` file.
-1. Click {% octicon "pencil" aria-label="The edit icon" %} to edit the file.
-3. In the editor, write a bit about yourself.
+1. Under the `readme-edits` branch you created, click the _README.md_ file.
+2. Click {% octicon "pencil" aria-label="The edit icon" %} to edit the file.
+3. In the editor, write a bit about yourself. Try using different Markdown elements.
 4. In the **Commit changes** box, write a commit message that describes your changes.
 5. Click **Commit changes**.
 
@@ -117,17 +118,23 @@ You can even open pull requests in your own repository and merge them yourself.
 
 5. Click **Create pull request**.
 6. Give your pull request a title and write a brief description of your changes. You can include emojis and drag and drop images and gifs.
+7. Optionally, to the right of your title and description, click the {% octicon "gear" aria-label="The Gear icon" %} next to **Reviewers**. **Assignees**, **Labels**, **Projects**, or **Milestone** to add any of these options to your pull request. You do not need to add any yet, but these options offer different ways to collaborate using pull requests. For more information, see "[About pull requests](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)."
 7. Click **Create pull request**.
 
 Your collaborators can now review your edits and make suggestions.
 
 ## Merging your pull request
 
-In this final step, you will merge your `readme-edits` branch into the `main` branch.
+In this final step, you will merge your `readme-edits` branch into the `main` branch.  After you merge your pull request, the changes on your `readme-edits` branch will be incorporated into `main`.
+
+Sometimes, a pull request may introduce changes to code that conflict with the existing code on `main`. If there are any conflicts, {% data variables.product.product_name %} will alert you about the conflicting code and prevent merging until the conflicts are resolved. You can make a commit that resolves the conflicts or use comments in the pull request to discuss the conflicts with your team members.
+
+In this walk-through, you should not have any conflicts, so you are ready to merge your branch into the main branch.
 
 1. Click **Merge pull request** to merge the changes into `main`.
-2. Click **Confirm merge**.
-3. Go ahead and delete the branch, since its changes have been incorporated, by clicking **Delete branch**.
+  ![Screen shot of merge button.](/assets/images/help/pull_requests/pullrequest-mergebutton.png)
+2. Click **Confirm merge**. You will receive a message that the request was successfully merged and the request was closed.
+3. Click **Delete branch**. Now that your pull request is merged and your changes are on `main`, you can safely delete the `readme-edits` branch. If you want to make more changes to your project, you can always create a new branch and repeat this process.
 
 ## Next steps