repo sync

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/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

content/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility.md

@@ -9,11 +9,9 @@ versions:
   free-pro-team: '*'
 ---
 
-{% data reusables.package_registry.container-registry-beta %}
-
 Packages with granular permissions are scoped to a personal user or organization account. You can change the access control and visibility of a package separately from the repository that it is connected (or linked) to.
 
-Currently, only the {% data variables.product.prodname_container_registry %} offers granular permissions for your container image packages.
+Currently, you can only use granular permissions with the {% data variables.product.prodname_container_registry %}. Granular permissions are not supported in our other package registries, such as the npm registry.
 
 For more information about permissions for repository-scoped packages, packages-related scopes for PATs, or managing permissions for your actions workflows, see "[About permissions for GitHub Packages](/packages/learn-github-packages/about-permissions-for-github-packages)."
 
@@ -41,8 +39,6 @@ If you have admin permissions to an organization-owned container image, you can
 
 If your package is private or internal and owned by an organization, then you can only give access to other organization members or teams.
 
-For organization image containers, organizations admins must enable packages before you can set the visibility to public. For more information, see "[Enabling improved container support with the Container registry](/packages/working-with-a-github-packages-registry/enabling-improved-container-support-with-the-container-registry)."
-
 {% data reusables.package_registry.package-settings-from-org-level %}
 1. On the package settings page, click **Invite teams or people** and enter the name, username, or email of the person you want to give access. You can also enter a team name from the organization to give all team members access.
   ![Container access invite button](/assets/images/help/package-registry/container-access-invite.png)
@@ -135,8 +131,6 @@ When you first publish a package, the default visibility is private and only you
 
 A public package can be accessed anonymously without authentication. Once you make your package public, you cannot make your package private again.
 
-For organization image containers, organizations admins must enable public packages before you can set the visibility to public. For more information, see "[Enabling improved container support with the Container registry](/packages/working-with-a-github-packages-registry/enabling-improved-container-support-with-the-container-registry)."
-
 {% data reusables.package_registry.package-settings-from-org-level %}
 5. Under "Danger Zone", choose a visibility setting:
     - To make the container image visible to anyone, click **Make public**.