Merge branch 'main' into patch-1

content/actions/guides/publishing-docker-images.md

@@ -36,8 +36,9 @@ We recommend that you have a basic understanding of workflow configuration optio
 You might also find it helpful to have a basic understanding of the following:
 
 - "[Encrypted secrets](/actions/reference/encrypted-secrets)"
-- "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow)"
-- "[Working with the Docker registry](/packages/working-with-a-github-packages-registry/working-with-the-docker-registry)"
+- "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow)"{% if currentVersion == "free-pro-team@latest" %}
+- "[Working with the {% data variables.product.prodname_container_registry %}](/packages/working-with-a-github-packages-registry/working-with-the-container-registry)"{% else %}
+- "[Working with the Docker registry](/packages/working-with-a-github-packages-registry/working-with-the-docker-registry)"{% endif %}
 
 ## About image configuration
 
@@ -63,9 +64,11 @@ The `build-push-action` options required for Docker Hub are:
 * `tags`: The tag of your new image in the format `DOCKER-HUB-NAMESPACE/DOCKER-HUB-REPOSITORY:VERSION`. You can set a single tag as shown below, or specify multiple tags in a list.
 * `push`: If set to `true`, the image will be pushed to the registry if it is built successfully.
 
-{% raw %}
 ```yaml{:copy}
 name: Publish Docker image
+
+{% data reusables.actions.actions-not-certified-by-github %}
+
 on:
   release:
     types: [published]
@@ -79,35 +82,50 @@ jobs:
       - name: Log in to Docker Hub
         uses: docker/login-action@v1
         with:
-          username: ${{ secrets.DOCKER_USERNAME }}
-          password: ${{ secrets.DOCKER_PASSWORD }}
+          username: {% raw %}${{ secrets.DOCKER_USERNAME }}{% endraw %}
+          password: {% raw %}${{ secrets.DOCKER_PASSWORD }}{% endraw %}
       - name: Push to Docker Hub
         uses: docker/build-push-action@v2
         with:
           push: true
           tags: my-docker-hub-namespace/my-docker-hub-repository:latest
 ```
-{% endraw %}
 
-{% data reusables.github-actions.docker-tag-with-ref %}
+The above workflow checks out the {% data variables.product.prodname_dotcom %} repository, uses the `login-action` to log in to the registry, and then uses the `build-push-action` action to: build a Docker image based on your repository's `Dockerfile`; push the image to Docker Hub, and apply a tag to the image.
 
 ## Publishing images to {% data variables.product.prodname_registry %}
 
 {% data reusables.github-actions.release-trigger-workflow %}
 
-In the example workflow below, we use the Docker `login-action` and `build-push-action` actions to build the Docker image, and if the build succeeds, push the built image to {% data variables.product.prodname_registry %}.
+In the example workflow below, we use the Docker `login-action`{% if currentVersion == "free-pro-team@latest" %}, `metadata-action`,{% endif %} and `build-push-action` actions to build the Docker image, and if the build succeeds, push the built image to {% data variables.product.prodname_registry %}.
 
 The `login-action` options required for {% data variables.product.prodname_registry %} are:
-* `registry`: Must be set to `docker.pkg.github.com`.
+* `registry`: Must be set to {% if currentVersion == "free-pro-team@latest" %}`ghcr.io`{% else %}`docker.pkg.github.com`{% endif %}.
 * `username`: You can use the {% raw %}`${{ github.actor }}`{% endraw %} context to automatically use the username of the user that triggered the workflow run. For more information, see "[Context and expression syntax for GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)."
 * `password`: You can use the automatically-generated `GITHUB_TOKEN` secret for the password. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token)."
 
-The `build-push-action` options required for {% data variables.product.prodname_registry %} are:
-* `tags`: Must be set in the format `docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION`. For example, for an image named `octo-image` stored on {% data variables.product.prodname_dotcom %} at `http://github.com/octo-org/octo-repo`, the `tags` option should be set to `docker.pkg.github.com/octo-org/octo-repo/octo-image:latest`. You can set a single tag as shown below, or specify multiple tags in a list.
-* `push`: If set to `true`, the image will be pushed to the registry if it is built successfully.
+{% if currentVersion == "free-pro-team@latest" %}
+The `metadata-action` option required for {% data variables.product.prodname_registry %} is:
+* `images`: The namespace and name for the Docker image you are building.
+{% endif %}
 
+The `build-push-action` options required for {% data variables.product.prodname_registry %} are:{% if currentVersion == "free-pro-team@latest" %}
+* `context`: Defines the build's context as the set of files located in the specified path.{% endif %}
+* `push`: If set to `true`, the image will be pushed to the registry if it is built successfully.{% if currentVersion == "free-pro-team@latest" %}
+* `tags` and `labels`: These are populated by output from `metadata-action`.{% else %}
+* `tags`: Must be set in the format `docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION`. For example, for an image named `octo-image` stored on {% data variables.product.prodname_dotcom %} at `http://github.com/octo-org/octo-repo`, the `tags` option should be set to `docker.pkg.github.com/octo-org/octo-repo/octo-image:latest`. You can set a single tag as shown below, or specify multiple tags in a list.{% endif %}
+
+{% if currentVersion == "free-pro-team@latest" %}
+{% data reusables.package_registry.publish-docker-image %}
+
+The above workflow if triggered by a push to the "release" branch. It checks out the GitHub repository, and uses the `login-action` to log in to the {% data variables.product.prodname_container_registry %}. It then extracts labels and tags for the Docker image. Finally, it and uses the `build-push-action` action to build the image and publish it on the {% data variables.product.prodname_container_registry %}.
+
+{% else %}
 ```yaml{:copy}
 name: Publish Docker image
+
+{% data reusables.actions.actions-not-certified-by-github %}
+
 on:
   release:
     types: [published]
@@ -133,19 +151,25 @@ jobs:
           push: true
           tags: |
             {% if currentVersion == "github-ae@latest" %}docker.YOUR-HOSTNAME.com{% else %}docker.pkg.github.com{% endif %}{% raw %}/${{ github.repository }}/octo-image:${{ github.sha }}{% endraw %}
-            {% if currentVersion == "github-ae@latest" %}docker.YOUR-HOSTNAME.com{% else %}docker.pkg.github.com{% endif %}{% raw %}/${{ github.repository }}/octo-image:${{ github.ref }}{% endraw %}
+            {% if currentVersion == "github-ae@latest" %}docker.YOUR-HOSTNAME.com{% else %}docker.pkg.github.com{% endif %}{% raw %}/${{ github.repository }}/octo-image:${{ github.event.release.tag_name }}{% endraw %}
 ```
 
-{% data reusables.github-actions.docker-tag-with-ref %}
+The above workflow checks out the {% data variables.product.prodname_dotcom %} repository, uses the `login-action` to log in to the registry, and then uses the `build-push-action` action to: build a Docker image based on your repository's `Dockerfile`; push the image to the Docker registry, and apply the commit SHA and release version as image tags.
+{% endif %}
 
 ## Publishing images to Docker Hub and {% data variables.product.prodname_registry %}
 
 In a single workflow, you can publish your Docker image to multiple registries by using the `login-action` and `build-push-action` actions for each registry.
 
 The following example workflow uses the steps from the previous sections ("[Publishing images to Docker Hub](#publishing-images-to-docker-hub)" and "[Publishing images to {% data variables.product.prodname_registry %}](#publishing-images-to-github-packages)") to create a single workflow that pushes to both registries.
 
+
+
 ```yaml{:copy}
 name: Publish Docker image
+
+{% data reusables.actions.actions-not-certified-by-github %}
+
 on:
   release:
     types: [published]
@@ -164,22 +188,33 @@ jobs:
         with:
           username: {% raw %}${{ secrets.DOCKER_USERNAME }}{% endraw %}
           password: {% raw %}${{ secrets.DOCKER_PASSWORD }}{% endraw %}
-      - name: Log in to GitHub Docker Registry
+      - name: Log in to the {% if currentVersion == "free-pro-team@latest" %}Container{% else %}Docker{% endif %} registry
         uses: docker/login-action@v1
         with:
-          registry: {% if currentVersion == "github-ae@latest" %}docker.YOUR-HOSTNAME.com{% else %}docker.pkg.github.com{% endif %}
+          registry: {% if currentVersion == "free-pro-team@latest" %}ghcr.io{% elsif currentVersion == "github-ae@latest" %}docker.YOUR-HOSTNAME.com{% else %}docker.pkg.github.com{% endif %}
           username: {% raw %}${{ github.actor }}{% endraw %}
           password: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
-      - name: Push to Docker Hub
+      - name: Build and push to Docker Hub
         uses: docker/build-push-action@v2
         with:
           push: true
-          tags: my-docker-hub-namespace/my-docker-hub-repository:{% raw %}${{ github.ref }}{% endraw %}
-      - name: Build container image
+          tags: my-docker-hub-namespace/my-docker-hub-repository:{% raw %}${{ github.event.release.tag_name }}{% endraw %}{% if currentVersion == "free-pro-team@latest" %}
+      - name: Extract metadata (tags, labels) for Docker
+        id: meta
+        uses: docker/metadata-action@v3
+        with:
+          images: ghcr.io/{% raw %}${{ github.repository }}{% endraw %}{% endif %}
+      - name: Build and push to {% data variables.product.prodname_registry %}
         uses: docker/build-push-action@v2
         with:
-          push: true
-          tags: {% if currentVersion == "github-ae@latest" %}docker.YOUR-HOSTNAME.com{% else %}docker.pkg.github.com{% endif %}{% raw %}/${{ github.repository }}/my-image:${{ github.ref }}{% endraw %}
+          push: true{% if currentVersion == "free-pro-team@latest" %}
+          context: .
+          tags: {% raw %}${{ steps.meta.outputs.tags }}{% endraw %}
+          labels: {% raw %}${{ steps.meta.outputs.labels }}{% endraw %}{% else %}
+          tags: {% if currentVersion == "github-ae@latest" %}docker.YOUR-HOSTNAME.com{% else %}docker.pkg.github.com{% endif %}{% raw %}/${{ github.repository }}/my-image:${{ github.event.release.tag_name }}{% endraw %}{% endif %}
 ```
 
-The above workflow checks out the {% data variables.product.prodname_dotcom %} repository, uses the `login-action` twice to log in to both registries, and then uses the `build-push-action` action twice to build and push the Docker image to Docker Hub and {% data variables.product.prodname_registry %}. For both steps, it tags the built Docker image with the Git reference of the workflow event. This workflow is triggered on publishing a {% data variables.product.prodname_dotcom %} release, so the reference for both registries will be the Git tag for the release.
+The above workflow checks out the {% data variables.product.prodname_dotcom %} repository, uses the `login-action` twice to log in to both registries, and then uses the `build-push-action` action twice to build and push the Docker image to Docker Hub and the 
+{% if currentVersion == "free-pro-team@latest" %}{% data variables.product.prodname_container_registry %}. For Docker Hub, it tags the built Docker image with the version tag for the release that triggered the workflow. For the {% data variables.product.prodname_container_registry %}, tags and labels are automatically generated by the `metadata-action` action. 
+{% else %}Docker registry. For both steps, it tags the built Docker image with the version tag for the release that triggered the workflow.
+{% endif %}

content/billing/managing-billing-for-github-packages/about-billing-for-github-packages.md

@@ -20,7 +20,7 @@ topics:
 
 {% note %}
 
-**Billing update for container image storage:** During the beta phase of the {% data variables.product.prodname_container_registry %}, Docker image storage and bandwidth are free for both the previous `docker.pkg.github.com` and current `ghcr.io` hosting services. For more information, see "[Introduction to {% data variables.product.prodname_registry %}](/packages/learn-github-packages/introduction-to-github-packages)."
+**Billing update for container image storage:** The period of free use for container image storage and bandwidth for the {% data variables.product.prodname_container_registry %} has been extended. If you are using {% data variables.product.prodname_container_registry %} you'll be informed at least one month in advance of billing commencing and you'll be given an estimate of how much you should expect to pay. For more information about the {% data variables.product.prodname_container_registry %}, see "[Working with the Container registry](/packages/working-with-a-github-packages-registry/working-with-the-container-registry)."
 
 {% endnote %}
 

content/desktop/contributing-and-collaborating-using-github-desktop/managing-commits/reordering-commits.md

@@ -36,6 +36,7 @@ When you reorder commits, you may see one of the following notifications or erro
 
 * A message states that there are merge conflicts that you must resolve before the application can continue reordering commits on your branch.
     1. Click **View conflicts** to see the conflicts.
+      ![reorder resolve conflicts message](/assets/images/help/desktop/reorder-resolve-conflicts.png)
     {% data reusables.desktop.resolve-merge-conflicts %}
-
-  ![reorder resolve conflicts message](/assets/images/help/desktop/reorder-resolve-conflicts.png)
+   3. When all conflicts are resolved, you can reorder your commits.
+

content/github/authenticating-to-github/keeping-your-account-and-data-secure/about-githubs-ip-addresses.md

@@ -15,11 +15,18 @@ topics:
   - Identity
   - Access management
 ---
+
 You can retrieve a list of {% data variables.product.prodname_dotcom %}'s IP addresses from the [meta](https://api.github.com/meta) API endpoint. For more information, see "[Meta](/rest/reference/meta)."
 
+{% note %}
+
+**Note:** The list of {% data variables.product.prodname_dotcom %} IP addresses returned by the Meta API is not intended to be an exhaustive list. For example, IP addresses for some {% data variables.product.prodname_dotcom %} services might not be listed, such as LFS or {% data variables.product.prodname_registry %}.
+
+{% endnote %}
+
 These ranges are in [CIDR notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#CIDR_notation). You can use an online conversion tool such as this  [CIDR / VLSM Supernet Calculator](http://www.subnet-calculator.com/cidr.php) to convert from CIDR notation to IP address ranges.
 
-We make changes to our IP addresses from time to time, and will keep this API up to date. We do not recommend allowing by IP address, however if you use these IP ranges we strongly encourage regular monitoring of our API.
+We make changes to our IP addresses from time to time. We do not recommend allowing by IP address, however if you use these IP ranges we strongly encourage regular monitoring of our API.
 
 For applications to function, you must allow TCP ports 22, 80, 443, and 9418 via our IP ranges for `github.com`.
 

content/github/collaborating-with-pull-requests/working-with-forks/syncing-a-fork.md

@@ -12,6 +12,22 @@ versions:
 topics:
   - Pull requests
 ---
+
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
+
+### Syncing a fork from the web UI
+
+1. On {% data variables.product.product_name %}, navigate to the main page of the forked repository that you want to sync with the upstream repository.
+1. Select the **Fetch upstream** drop-down.
+    !["Fetch upstream" drop-down](/assets/images/help/repository/fetch-upstream-drop-down.png)
+1. Review the details about the commits from the upstream repository, then click **Fetch and merge**.
+    !["Fetch and merge" button](/assets/images/help/repository/fetch-and-merge-button.png)
+
+If the changes from the upstream repository cause conflicts, {% data variables.product.company_short %} will prompt you to create a pull request to resolve the conflicts.
+
+### Syncing a fork from the command line 
+
+{% endif %}
 Before you can sync your fork with an upstream repository, you must [configure a remote that points to the upstream repository](/articles/configuring-a-remote-for-a-fork) in Git.
 
 {% data reusables.command_line.open_the_multi_os_terminal %}

content/github/committing-changes-to-your-project/index.md

@@ -1,5 +1,6 @@
 ---
 title: Committing changes to your project
+intro: 'You can manage code changes in a repository by grouping work into commits.'
 redirect_from:
   - /categories/21/articles/
   - /categories/commits/
@@ -13,4 +14,3 @@ children:
   - /viewing-and-comparing-commits
   - /troubleshooting-commits
 ---
-

content/github/managing-subscriptions-and-notifications-on-github/index.md

@@ -1,5 +1,6 @@
 ---
 title: Managing subscriptions and notifications on GitHub
+intro: 'You can specify how to receive notifications, the repositories you are interested in, and the types of activity you want to hear about.'
 redirect_from:
   - /categories/76/articles/
   - /categories/notifications/
@@ -15,4 +16,3 @@ children:
   - /viewing-and-triaging-notifications
   - /managing-subscriptions-for-activity-on-github
 ---
-

content/packages/index.md

@@ -12,13 +12,12 @@ featuredLinks:
     - /packages/learn-github-packages/installing-a-package
   popular:
     - /packages/working-with-a-github-packages-registry/working-with-the-npm-registry
-    - /packages/working-with-a-github-packages-registry/working-with-the-docker-registry
+    - '{% if currentVersion == "free-pro-team@latest" %}/packages/working-with-a-github-packages-registry/working-with-the-container-registry{% else %}/packages/working-with-a-github-packages-registry/working-with-the-docker-registry{% endif %}'
     - /packages/learn-github-packages
     - /packages/working-with-a-github-packages-registry/working-with-the-apache-maven-registry
   guideCards:
-    - /packages/working-with-a-github-packages-registry/working-with-the-docker-registry
-    - /packages/working-with-a-github-packages-registry/enabling-improved-container-support-with-the-container-registry
-    - /packages/working-with-a-github-packages-registry/working-with-the-rubygems-registry
+   - '{% if currentVersion == "free-pro-team@latest" %}/packages/working-with-a-github-packages-registry/working-with-the-container-registry{% else %}/packages/working-with-a-github-packages-registry/working-with-the-docker-registry{% endif %}'
+   - /packages/working-with-a-github-packages-registry/working-with-the-rubygems-registry
 changelog:
   label: packages
   prefix: 'Packages: '

content/packages/learn-github-packages/about-permissions-for-github-packages.md

@@ -14,11 +14,11 @@ The permissions for packages are either repository-scoped or user/organization-s
 
 ## Permissions for repository-scoped packages
 
-A repository-scoped package inherits the permissions and visibility of the repository that owns the package. You can find a package scoped to a repository by going to the main page of the repository and clicking the **Packages** link to the right of the page.
+A repository-scoped package inherits the permissions and visibility of the repository that owns the package. You can find a package scoped to a repository by going to the main page of the repository and clicking the **Packages** link to the right of the page. {% if currentVersion == "free-pro-team@latest" %}For more information, see "[Connecting a repository to a package](/packages/learn-github-packages/connecting-a-repository-to-a-package)."{% endif %}
 
 The {% data variables.product.prodname_registry %} registries below use repository-scoped permissions:
 
-  - Docker registry (`docker.pkg.github.com`)
+  {% if currentVersion != "free-pro-team@latest" %}- Docker registry (`docker.pkg.github.com`){% endif %}
   - npm registry
   - RubyGems registry
   - Apache Maven registry