зеркало из https://github.com/github/docs.git
GH NPM Package Registry Improvements GA (#29652)
Co-authored-by: hubwriter <hubwriter@github.com> Co-authored-by: Steve Guntrip <12534592+stevecat@users.noreply.github.com>
This commit is contained in:
Родитель
7ff6010013
Коммит
c0aed025a3
|
@ -98,9 +98,9 @@ Each time you create a new release, you can trigger a workflow to publish your p
|
|||
|
||||
### Configuring the destination repository
|
||||
|
||||
If you don't provide the `repository` key in your *package.json* file, then {% data variables.product.prodname_registry %} publishes a package in the {% data variables.product.prodname_dotcom %} repository you specify in the `name` field of the *package.json* file. For example, a package named `@my-org/test` is published to the `my-org/test` {% data variables.product.prodname_dotcom %} repository.
|
||||
Linking your package to {% data variables.product.prodname_registry %} using the `repository` key is optional. If you choose not to provide the `repository` key in your *package.json* file, then {% data variables.product.prodname_registry %} publishes a package in the {% data variables.product.prodname_dotcom %} repository you specify in the `name` field of the *package.json* file. For example, a package named `@my-org/test` is published to the `my-org/test` {% data variables.product.prodname_dotcom %} repository. If the `url` specified in the `repository` key is invalid, your package may still be published however it won't be linked to the repository source as intended.
|
||||
|
||||
However, if you do provide the `repository` key, then the repository in that key is used as the destination npm registry for {% data variables.product.prodname_registry %}. For example, publishing the below *package.json* results in a package named `my-amazing-package` published to the `octocat/my-other-repo` {% data variables.product.prodname_dotcom %} repository.
|
||||
If you do provide the `repository` key in your *package.json* file, then the repository in that key is used as the destination npm registry for {% data variables.product.prodname_registry %}. For example, publishing the below *package.json* results in a package named `my-amazing-package` published to the `octocat/my-other-repo` {% data variables.product.prodname_dotcom %} repository. Once published, only the repository source is updated, and the package doesn't inherit any permissions from the destination repository.
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
@ -12,25 +12,25 @@ shortTitle: Private image registry
|
|||
|
||||
## About private image registries and {% data variables.product.prodname_github_codespaces %}
|
||||
|
||||
A registry is a secure space for storing, managing, and fetching private container images. You may use one to store one or more images. There are many examples of registries, such as {% data variables.product.prodname_dotcom %} Container Registry, Azure Container Registry, or DockerHub.
|
||||
A registry is a secure space for storing, managing, and fetching private container images. You may use one to store one or more images. There are many examples of registries, such as {% data variables.product.prodname_container_registry %}, {% data variables.product.prodname_npm_registry %}, Azure Container Registry, or DockerHub.
|
||||
|
||||
{% data variables.product.prodname_dotcom %} Container Registry can be configured to pull container images seamlessly, without having to provide any authentication credentials to {% data variables.product.prodname_github_codespaces %}. For other image registries, you must create secrets in {% data variables.product.prodname_dotcom %} to store the access details, which will allow {% data variables.product.prodname_codespaces %} to access images stored in that registry.
|
||||
{% data variables.product.prodname_ghcr_and_npm_registry %} can be configured to allow container images to be pulled seamlessly into {% data variables.product.prodname_github_codespaces %} during codespace creation, without having to provide any authentication credentials. For other image registries, you must create secrets in {% data variables.product.prodname_dotcom %} to store the access details, which will allow {% data variables.product.prodname_codespaces %} to access images stored in that registry.
|
||||
|
||||
## Accessing images stored in {% data variables.product.prodname_dotcom %} Container Registry
|
||||
## Accessing images stored in {% data variables.product.prodname_ghcr_and_npm_registry %}
|
||||
|
||||
{% data variables.product.prodname_dotcom %} Container Registry is the easiest way for {% data variables.product.prodname_codespaces %} to consume devcontainer container images.
|
||||
{% data variables.product.prodname_ghcr_and_npm_registry %} provide the easiest way for {% data variables.product.prodname_codespaces %} to consume dev container images.
|
||||
|
||||
For more information, see "[Working with the Container registry](/packages/working-with-a-github-packages-registry/working-with-the-container-registry)".
|
||||
For more information, see "[Working with the Container registry](/packages/working-with-a-github-packages-registry/working-with-the-container-registry)" and "[Working with the npm registry](/packages/working-with-a-github-packages-registry/working-with-the-npm-registry)".
|
||||
|
||||
### Accessing an image published to the same repository as the codespace
|
||||
|
||||
If you publish a container image to {% data variables.product.prodname_dotcom %} Container Registry in the same repository that the codespace is being launched in, you will automatically be able to fetch that image on codespace creation. You won't have to provide any additional credentials, unless the **Inherit access from repo** option was unselected when the container image was published.
|
||||
If you publish a container image to {% data variables.product.prodname_ghcr_or_npm_registry %} in the same repository that the codespace is being launched in, you will automatically be able to fetch that image on codespace creation. You won't have to provide any additional credentials, unless the **Inherit access from repo** option was unselected when the container image was published.
|
||||
|
||||
#### Inheriting access from the repository from which an image was published
|
||||
|
||||
By default, when you publish a container image to {% data variables.product.prodname_dotcom %} Container Registry, the image inherits the access setting of the repository from which the image was published. For example, if the repository is public, the image is also public. If the repository is private, the image is also private, but is accessible from the repository.
|
||||
By default, when you publish a container image to {% data variables.product.prodname_ghcr_or_npm_registry %}, the image inherits the access setting of the repository from which the image was published. For example, if the repository is public, the image is also public. If the repository is private, the image is also private, but is accessible from the repository.
|
||||
|
||||
This behavior is controlled by the **Inherit access from repo** option. **Inherit access from repo** is selected by default when publishing via {% data variables.product.prodname_actions %}, but not when publishing directly to {% data variables.product.prodname_dotcom %} Container Registry using a Personal Access Token (PAT).
|
||||
This behavior is controlled by the **Inherit access from repo** option. **Inherit access from repo** is selected by default when publishing via {% data variables.product.prodname_actions %}, but not when publishing directly to {% data variables.product.prodname_ghcr_or_npm_registry %} using a Personal Access Token (PAT).
|
||||
|
||||
If the **Inherit access from repo** option was not selected when the image was published, you can manually add the repository to the published container image's access controls. For more information, see "[Configuring a package's access control and visibility](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#inheriting-access-for-a-container-image-from-a-repository)."
|
||||
|
||||
|
@ -46,13 +46,13 @@ If you want to allow a subset of an organization's repositories to access a cont
|
|||
|
||||
### Publishing a container image from a codespace
|
||||
|
||||
Seamless access from a codespace to {% data variables.product.prodname_dotcom %} Container Registry is limited to pulling container images. If you want to publish a container image from inside a codespace, you must use a personal access token (PAT) with the `write:packages` scope.
|
||||
Seamless access from a codespace to {% data variables.product.prodname_ghcr_or_npm_registry %} is limited to pulling container images. If you want to publish a container image from inside a codespace, you must use a personal access token (PAT) with the `write:packages` scope.
|
||||
|
||||
We recommend publishing images via {% data variables.product.prodname_actions %}. For more information, see "[Publishing Docker images](/actions/publishing-packages/publishing-docker-images)."
|
||||
We recommend publishing images via {% data variables.product.prodname_actions %}. For more information, see "[Publishing Docker images](/actions/publishing-packages/publishing-docker-images)" and "[Publishing Node.js packages](/actions/publishing-packages/publishing-nodejs-packages)."
|
||||
|
||||
## Accessing images stored in other container registries
|
||||
|
||||
If you are accessing a container image from a registry that isn't {% data variables.product.prodname_dotcom %} Container Registry, {% data variables.product.prodname_codespaces %} checks for the presence of three secrets, which define the server name, username, and personal access token (PAT) for a container registry. If these secrets are found, {% data variables.product.prodname_github_codespaces %} will make the registry available inside your codespace.
|
||||
If you are accessing a container image from a registry that isn't {% data variables.product.prodname_ghcr_or_npm_registry %}, {% data variables.product.prodname_codespaces %} checks for the presence of three secrets, which define the server name, username, and personal access token (PAT) for a container registry. If these secrets are found, {% data variables.product.prodname_github_codespaces %} will make the registry available inside your codespace.
|
||||
|
||||
- `<*>_CONTAINER_REGISTRY_SERVER`
|
||||
- `<*>_CONTAINER_REGISTRY_USER`
|
||||
|
|
|
@ -18,6 +18,7 @@ featuredLinks:
|
|||
guideCards:
|
||||
- '{% ifversion docker-ghcr-enterprise-migration %}/packages/working-with-a-github-packages-registry/migrating-to-the-container-registry-from-the-docker-registry{% endif %}'
|
||||
- '{% ifversion fpt or ghec or ghes > 3.4 %}/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 %}'
|
||||
- '{% ifversion packages-npm-v2 %}/packages/working-with-a-github-packages-registry/working-with-the-npm-registry{% endif %}'
|
||||
- /packages/working-with-a-github-packages-registry/working-with-the-rubygems-registry
|
||||
changelog:
|
||||
label: packages
|
||||
|
|
|
@ -18,20 +18,22 @@ The permissions for packages are either repository-scoped or user/organization-s
|
|||
|
||||
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. {% ifversion fpt or ghec %}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:
|
||||
The {% data variables.product.prodname_registry %} registries below **only** use repository-scoped permissions:
|
||||
|
||||
{% ifversion not fpt or ghec %}- Docker registry (`docker.pkg.github.com`){% endif %}
|
||||
- npm registry
|
||||
{% ifversion packages-npm-v2 %}{% else %}- npm registry{% endif %}
|
||||
- RubyGems registry
|
||||
- Apache Maven registry
|
||||
- NuGet registry
|
||||
|
||||
{% ifversion packages-npm-v2 %}For {% data variables.product.prodname_ghcr_and_npm_registry %}, you can choose to allow packages to be scoped to a user, an organization, or linked to a repository.{% endif %}
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
## Granular permissions for user/organization-scoped packages
|
||||
|
||||
Packages with granular permissions are scoped to a personal user or organization account. You can change the access control and visibility of the package separately from a repository that is connected (or linked) to a package.
|
||||
|
||||
Currently, only the {% data variables.product.prodname_container_registry %} offers granular permissions for your container image packages.
|
||||
Currently, the {% data variables.product.prodname_ghcr_and_npm_registry %} offer granular permissions for your container image packages.
|
||||
|
||||
## Visibility and access permissions for container images
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ shortTitle: Access control & visibility
|
|||
|
||||
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, 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.{% ifversion docker-ghcr-enterprise-migration %} For more information about migration to the {% data variables.product.prodname_container_registry %}, see "[Migrating to the {% data variables.product.prodname_container_registry %} from the Docker registry](/packages/working-with-a-github-packages-registry/migrating-to-the-container-registry-from-the-docker-registry)."{% endif %}
|
||||
Currently, you can only use granular permissions with the {% data variables.product.prodname_ghcr_and_npm_registry %}. Granular permissions are not supported in our other package registries, such as the RubyGems registry.{% ifversion docker-ghcr-enterprise-migration %} For more information about migration to the {% data variables.product.prodname_container_registry %}, see "[Migrating to the {% data variables.product.prodname_container_registry %} from the Docker registry](/packages/working-with-a-github-packages-registry/migrating-to-the-container-registry-from-the-docker-registry)."{% endif %}
|
||||
|
||||
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)."
|
||||
|
||||
|
@ -105,7 +105,7 @@ To further customize access to your container image, see "[Configuring access to
|
|||
{% ifversion fpt or ghec %}
|
||||
## Ensuring {% data variables.product.prodname_codespaces %} access to your package
|
||||
|
||||
By default, a codespace can seamlessly access certain packages in the {% data variables.product.prodname_dotcom %} Container Registry, such as those published in the same repository with the **Inherit access** option selected. For more information on which access is automatically configured, see "[Accessing images stored in {% data variables.product.prodname_dotcom %} Container Registry](/codespaces/codespaces-reference/allowing-your-codespace-to-access-a-private-image-registry#accessing-images-stored-in-github-container-registry)."
|
||||
By default, a codespace can seamlessly access certain packages in the {% data variables.product.prodname_ghcr_and_npm_registry %}, such as those published in the same repository with the **Inherit access** option selected. For more information on which access is automatically configured, see "[Allowing your codespace to access a private image registry](/codespaces/codespaces-reference/allowing-your-codespace-to-access-a-private-image-registry#accessing-images-stored-in-container-registry-and-npm-registry)."
|
||||
|
||||
Otherwise, to ensure that a codespace has access to your package, you must grant access to the repository where the codespace is being launched.
|
||||
|
||||
|
|
|
@ -23,12 +23,12 @@ On {% data variables.product.prodname_dotcom %} if you have the required access,
|
|||
- an entire private package
|
||||
- an entire public package, if there's not more than 5000 downloads of any version of the package
|
||||
- a specific version of a private package
|
||||
- a specific version of a public package, if the package version doesn't have more than 5000 downloads
|
||||
- a specific version of a public package, if the package version doesn't have more than 5,000 downloads
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:**
|
||||
- You cannot delete a public package if any version of the package has more than 5000 downloads. In this scenario, contact [GitHub support](https://support.github.com/contact?tags=docs-packages) for further assistance.
|
||||
- You cannot delete a public package if any version of the package has more than 5,000 downloads. In this scenario, contact [GitHub support](https://support.github.com/contact?tags=docs-packages) for further assistance.
|
||||
- When deleting public packages, be aware that you may break projects that depend on your package.
|
||||
|
||||
{% endnote %}
|
||||
|
@ -46,7 +46,7 @@ You can use the REST API to manage your packages. For more information, see the
|
|||
|
||||
{% endif %}
|
||||
|
||||
For packages that inherit their permissions and access from repositories, you can use GraphQL to delete a specific package version.{% ifversion fpt or ghec %} The {% data variables.product.prodname_registry %} GraphQL API does not support containers or Docker images that use the package namespace `https://ghcr.io/OWNER/PACKAGE-NAME`.{% endif %} For more information about GraphQL support, see "[Deleting a version of a repository-scoped package with GraphQL](#deleting-a-version-of-a-repository-scoped-package-with-graphql)."
|
||||
For packages that inherit their permissions and access from repositories, you can use GraphQL to delete a specific package version.{% data reusables.package_registry.no-graphql-to-delete-packages %} For more information about GraphQL support, see "[Deleting a version of a repository-scoped package with GraphQL](#deleting-a-version-of-a-repository-scoped-package-with-graphql)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
|
@ -54,18 +54,19 @@ For packages that inherit their permissions and access from repositories, you ca
|
|||
|
||||
For packages that inherit their access permissions from repositories, you can delete a package if you have admin permissions to the repository.
|
||||
|
||||
Repository-scoped packages on {% data variables.product.prodname_registry %} include these packages:
|
||||
- npm
|
||||
- RubyGems
|
||||
- maven
|
||||
- Gradle
|
||||
- NuGet
|
||||
{% ifversion not fpt or ghec %}- Docker images at `docker.pkg.github.com/OWNER/REPOSITORY/IMAGE-NAME`{% endif %}
|
||||
The {% data variables.product.prodname_registry %} registries below **only** use repository-scoped permissions:
|
||||
|
||||
{% ifversion not fpt or ghec %}- Docker images at `docker.pkg.github.com/OWNER/REPOSITORY/IMAGE-NAME`{% endif %}
|
||||
{% ifversion packages-npm-v2 %}{% else %}- npm{% endif %}
|
||||
- RubyGems registry
|
||||
- Apache Maven registry
|
||||
- NuGet registry
|
||||
|
||||
{% ifversion packages-npm-v2 %}For {% data variables.product.prodname_ghcr_and_npm_registry %}, you can choose to allow packages to be scoped to a user, an organization, or linked to a repository.{% endif %}
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
|
||||
To delete a package that has granular permissions separate from a repository, such as container images stored at `https://ghcr.io/OWNER/PACKAGE-NAME`, you must have admin access to the package.
|
||||
For more information, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages)."
|
||||
To delete a package that has granular permissions separate from a repository, such as container images stored at `https://ghcr.io/OWNER/PACKAGE-NAME` or `https://npm.pkg.github.com/OWNER/PACKAGE-NAME`, you must have admin access to the package. For more information, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
|
@ -89,9 +90,7 @@ To delete a version of a repository-scoped package, you must have admin permissi
|
|||
|
||||
For packages that inherit their permissions and access from repositories, you can use the GraphQL to delete a specific package version.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
For containers or Docker images at `ghcr.io`, GraphQL is not supported but you can use the REST API. For more information, see the "[{% data variables.product.prodname_registry %} API](/rest/reference/packages)."
|
||||
{% endif %}
|
||||
{% data reusables.package_registry.no-graphql-to-delete-packages %}{% ifversion fpt or ghec %} You can however use the REST API. For more information, see the "[{% data variables.product.prodname_registry %} API](/rest/reference/packages)."{% endif %}
|
||||
|
||||
Use the `deletePackageVersion` mutation in the GraphQL API. You must use a token with the `read:packages`, `delete:packages`, and `repo` scopes. For more information about tokens, see "[About {% data variables.product.prodname_registry %}](/packages/publishing-and-managing-packages/about-github-packages#authenticating-to-github-packages)."
|
||||
|
||||
|
|
|
@ -51,7 +51,7 @@ For more information about the configuration of {% data variables.product.prodna
|
|||
|
||||
| | |
|
||||
|--------------------|--------------------|
|
||||
| Permissions | {% ifversion fpt or ghec %}The permissions for a package are either inherited from the repository where the package is hosted or, for packages in the {% data variables.product.prodname_container_registry %}, they can be defined for specific user or organization accounts. For more information, see "[Configuring a package’s access control and visibility](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)." {% else %}Each package inherits the permissions of the repository where the package is hosted. <br> <br> For example, anyone with read permissions for a repository can install a package as a dependency in a project, and anyone with write permissions can publish a new package version.{% endif %} |
|
||||
| Permissions | {% ifversion fpt or ghec %}The permissions for a package are either inherited from the repository where the package is hosted or, for packages in the {% data variables.product.prodname_ghcr_and_npm_registry %}, they can be defined for specific user or organization accounts. For more information, see "[Configuring a package’s access control and visibility](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)." {% else %}Each package inherits the permissions of the repository where the package is hosted. <br> <br> For example, anyone with read permissions for a repository can install a package as a dependency in a project, and anyone with write permissions can publish a new package version.{% endif %} |
|
||||
| Visibility | {% data reusables.package_registry.public-or-private-packages %} |
|
||||
|
||||
For more information, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages)."
|
||||
|
@ -101,7 +101,9 @@ For more information about Docker and the {% data variables.product.prodname_con
|
|||
## Managing packages
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
You can delete a package in the {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.product.product_location %}{% endif %} user interface or using the REST API. For more information, see the "[{% data variables.product.prodname_registry %} API](/rest/reference/packages)."
|
||||
You can delete a package in the {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.product.product_location %}{% endif %} user interface or using the REST API. For more information, see "[Deleting and restoring a package](/packages/learn-github-packages/deleting-and-restoring-a-package)" and the "[{% data variables.product.prodname_registry %} API](/rest/reference/packages)."
|
||||
|
||||
{% data reusables.package_registry.no-graphql-to-delete-packages %}
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghes %}
|
||||
|
@ -112,7 +114,9 @@ You can delete a private or public package in the {% data variables.product.prod
|
|||
You can delete a version of a package in the {% data variables.product.product_name %} user interface or using the GraphQL API.
|
||||
{% endif %}
|
||||
|
||||
When you use the GraphQL API to query and delete private packages, you must use the same token you use to authenticate to {% data variables.product.prodname_registry %}. For more information, see "[Deleting and restoring a package](/packages/learn-github-packages/deleting-and-restoring-a-package)" and "[Forming calls with GraphQL](/graphql/guides/forming-calls-with-graphql)."
|
||||
When you use the GraphQL API to query and delete private packages, you must use the same token you use to authenticate to {% data variables.product.prodname_registry %}.
|
||||
|
||||
For more information, see {% ifversion ghes or ghae %}"[Deleting and restoring a package](/packages/learn-github-packages/deleting-and-restoring-a-package)" and {% endif %}"[Forming calls with GraphQL](/graphql/guides/forming-calls-with-graphql)."
|
||||
|
||||
You can configure webhooks to subscribe to package-related events, such as when a package is published or updated. For more information, see the "[`package` webhook event](/webhooks/event-payloads/#package)."
|
||||
|
||||
|
|
|
@ -21,17 +21,17 @@ versions:
|
|||
|
||||
## About package views
|
||||
|
||||
Your ability to view a package depends on several factors. By default, you can view all packages you have published.
|
||||
Your ability to view a package depends on several factors. By default, you can view all packages you have published.
|
||||
|
||||
Repository-scoped packages inherit their permissions and visibility from the repository that owns the package. The registries below use this type of permissions:{% ifversion not fpt or ghec %}
|
||||
Repository-scoped packages inherit their permissions and visibility from the repository that owns the package. The registries below **only** use this type of permissions:{% ifversion not fpt or ghec %}
|
||||
- Docker registry (`docker.pkg.github.com`){% endif %}
|
||||
- npm registry
|
||||
{% ifversion packages-npm-v2 %}{% else %}- npm registry{% endif %}
|
||||
- RubyGems registry
|
||||
- Apache Maven registry
|
||||
- NuGet registry
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
The Container registry offers you the option of granular permissions and visibility settings that can be customized for each package owned by a personal user or organization account. You can choose to use granular permissions or connect the package to a repository and inherit it's permissions. For more information, see "[Connecting a repository to a package](/packages/learn-github-packages/connecting-a-repository-to-a-package)."
|
||||
The {% data variables.product.prodname_ghcr_and_npm_registry %} offer you the option of granular permissions and visibility settings that can be customized for each package owned by a personal user or organization account. You can choose to use granular permissions or connect the package to a repository and inherit it's permissions. For more information, see "[Connecting a repository to a package](/packages/learn-github-packages/connecting-a-repository-to-a-package)."
|
||||
{% endif %}
|
||||
|
||||
For more information, see "[About permissions for GitHub Packages](/packages/learn-github-packages/about-permissions-for-github-packages){% ifversion fpt or ghec %}" and "[Configuring a package's access control and visibility](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility){% endif %}."
|
||||
|
|
|
@ -24,9 +24,9 @@ shortTitle: Publish & install with Actions
|
|||
You can extend the CI and CD capabilities of your repository by publishing or installing packages as part of your workflow.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
### Authenticating to the {% data variables.product.prodname_container_registry %}
|
||||
### Authenticating to the {% data variables.product.prodname_ghcr_and_npm_registry %}
|
||||
|
||||
{% data reusables.package_registry.authenticate_with_pat_for_container_registry %}
|
||||
{% data reusables.package_registry.authenticate_with_pat_for_v2_registry %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
|
@ -40,7 +40,7 @@ You can reference the `GITHUB_TOKEN` in your workflow file using the {% raw %}`{
|
|||
|
||||
{% note %}
|
||||
|
||||
**Note:** Repository-owned packages include RubyGems, npm, Apache Maven, NuGet, {% ifversion fpt or ghec %}and Gradle. {% else %}Gradle, and Docker packages that use the package namespace `docker.pkg.github.com`.{% endif %}
|
||||
**Note:** Some registries, such as RubyGems, {% ifversion packages-npm-v2 %}{% else %}npm, {% endif %}Apache Maven, NuGet, {% ifversion fpt or ghec %}and Gradle{% else %}Gradle, and Docker packages that use the package namespace `docker.pkg.github.com`{% endif %}, only allow repository-owned packages. With {% data variables.product.prodname_ghcr_and_npm_registry_full %} you can choose to allow packages to be owned by a user, an organization, or linked to a repository.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
|
@ -49,11 +49,11 @@ When you enable GitHub Actions, GitHub installs a GitHub App on your repository.
|
|||
{% data variables.product.prodname_registry %} allows you to push and pull packages through the `GITHUB_TOKEN` available to a {% data variables.product.prodname_actions %} workflow.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
## About permissions and package access for {% data variables.product.prodname_container_registry %}
|
||||
## About permissions and package access for {% data variables.product.prodname_ghcr_and_npm_registry %}
|
||||
|
||||
The {% data variables.product.prodname_container_registry %} (`ghcr.io`) allows users to create and administer containers as free-standing resources at the organization level. Containers can be owned by an organization or personal account and you can customize access to each of your containers separately from repository permissions.
|
||||
The {% data variables.product.prodname_ghcr_and_npm_registry_full %} allows users to create and administer packages as free-standing resources at the organization level. Packages can be owned by an organization or personal account and you can customize access to each of your packages separately from repository permissions.
|
||||
|
||||
All workflows accessing the {% data variables.product.prodname_container_registry %} should use the `GITHUB_TOKEN` instead of a personal access token. For more information about security best practices, see "[Security hardening for GitHub Actions](/actions/learn-github-actions/security-hardening-for-github-actions#using-secrets)."
|
||||
All workflows accessing the {% data variables.product.prodname_ghcr_and_npm_registry %} should use the `GITHUB_TOKEN` instead of a personal access token. For more information about security best practices, see "[Security hardening for GitHub Actions](/actions/learn-github-actions/security-hardening-for-github-actions#using-secrets)."
|
||||
|
||||
## Default permissions and access settings for containers modified through workflows
|
||||
|
||||
|
@ -484,9 +484,9 @@ Installing packages hosted by {% data variables.product.prodname_registry %} thr
|
|||
{% data reusables.package_registry.actions-configuration %}
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
## Upgrading a workflow that accesses `ghcr.io`
|
||||
## Upgrading a workflow that accesses a registry using a PAT
|
||||
|
||||
The {% data variables.product.prodname_container_registry %} supports the `GITHUB_TOKEN` for easy and secure authentication in your workflows. If your workflow is using a personal access token (PAT) to authenticate to `ghcr.io`, then we highly recommend you update your workflow to use the `GITHUB_TOKEN`.
|
||||
The {% data variables.product.prodname_ghcr_and_npm_registry %} support the `GITHUB_TOKEN` for easy and secure authentication in your workflows. If your workflow is using a personal access token (PAT) to authenticate to the registry, then we highly recommend you update your workflow to use the `GITHUB_TOKEN`.
|
||||
|
||||
For more information about the `GITHUB_TOKEN`, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow#using-the-github_token-in-a-workflow)."
|
||||
|
||||
|
@ -504,9 +504,9 @@ Using the `GITHUB_TOKEN` instead of a PAT, which includes the `repo` scope, incr
|
|||
{% endnote %}
|
||||
1. Optionally, using the "role" drop-down menu, select the default access level that you'd like the repository to have to your container image.
|
||||
![Permission access levels to give to repositories](/assets/images/help/package-registry/repository-permission-options-for-package-access-through-actions.png)
|
||||
1. Open your workflow file. On the line where you log in to `ghcr.io`, replace your PAT with {% raw %}`${{ secrets.GITHUB_TOKEN }}`{% endraw %}.
|
||||
1. Open your workflow file. On the line where you log in to the registry, replace your PAT with {% raw %}`${{ secrets.GITHUB_TOKEN }}`{% endraw %}.
|
||||
|
||||
For example, this workflow publishes a Docker image using {% raw %}`${{ secrets.GITHUB_TOKEN }}`{% endraw %} to authenticate.
|
||||
For example, this workflow publishes a Docker image to the {% data variables.product.prodname_container_registry %} and uses {% raw %}`${{ secrets.GITHUB_TOKEN }}`{% endraw %} to authenticate.
|
||||
|
||||
```yaml{:copy}
|
||||
name: Demo Push
|
||||
|
|
|
@ -42,7 +42,9 @@ When installing or publishing a Docker image, the {% data variables.product.prod
|
|||
|
||||
## Authenticating to the {% data variables.product.prodname_container_registry %}
|
||||
|
||||
{% data reusables.package_registry.authenticate_with_pat_for_container_registry %}
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
To authenticate to the {% data variables.product.prodname_container_registry %} (`ghcr.io`) within a {% data variables.product.prodname_actions %} workflow, use the `GITHUB_TOKEN` for the best security and experience. {% data reusables.package_registry.authenticate_with_pat_for_v2_registry %}
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghes %}Ensure that you replace `HOSTNAME` with {% data variables.product.product_location_enterprise %} hostname or IP address in the examples below.{% endif %}
|
||||
|
||||
|
|
|
@ -21,6 +21,8 @@ shortTitle: npm registry
|
|||
|
||||
{% data reusables.package_registry.admins-can-configure-package-types %}
|
||||
|
||||
{% ifversion packages-npm-v2 %}
|
||||
{% else %}
|
||||
## Limits for published npm versions
|
||||
|
||||
If you publish over 1,000 npm package versions to {% data variables.product.prodname_registry %}, you may see performance issues and timeouts occur during usage.
|
||||
|
@ -28,12 +30,17 @@ If you publish over 1,000 npm package versions to {% data variables.product.prod
|
|||
In the future, to improve performance of the service, you won't be able to publish more than 1,000 versions of a package on {% data variables.product.prodname_dotcom %}. Any versions published before hitting this limit will still be readable.
|
||||
|
||||
If you reach this limit, consider deleting package versions or contact Support for help. When this limit is enforced, our documentation will be updated with a way to work around this limit. For more information, see "[Deleting and restoring a package](/packages/learn-github-packages/deleting-and-restoring-a-package)" or "[Contacting Support](/packages/learn-github-packages/about-github-packages#contacting-support)."
|
||||
{% endif %}
|
||||
|
||||
## Authenticating to {% data variables.product.prodname_registry %}
|
||||
|
||||
{% data reusables.package_registry.authenticate-packages %}
|
||||
|
||||
{% data reusables.package_registry.authenticate-packages-github-token %}
|
||||
{% ifversion packages-npm-v2 %}
|
||||
{% data reusables.package_registry.authenticate_with_pat_for_v2_registry %}
|
||||
|
||||
You can also choose to give access permissions to packages independently for {% data variables.product.prodname_codespaces %} and {% data variables.product.prodname_actions %}. For more information, see "[Ensuring Codespaces access to your package](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-codespaces-access-to-your-package) and [Ensuring workflow access to your package](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-workflow-access-to-your-package)."
|
||||
{% endif %}
|
||||
|
||||
### Authenticating with a personal access token
|
||||
|
||||
|
@ -94,12 +101,24 @@ $ npm login --scope=@<em>OWNER</em> --registry=https://<em>HOSTNAME</em>/_regist
|
|||
|
||||
{% endnote %}
|
||||
|
||||
{% ifversion packages-npm-v2 %}
|
||||
The {% data variables.product.prodname_registry %} registry stores npm packages within your organization or personal account, and allows you to associate a package with a repository. You can choose whether to inherit permissions from a repository, or set granular permissions independently of a repository.
|
||||
{% endif %}
|
||||
|
||||
By default, {% data variables.product.prodname_registry %} publishes a package in the {% data variables.product.prodname_dotcom %} repository you specify in the name field of the *package.json* file. For example, you would publish a package named `@my-org/test` to the `my-org/test` {% data variables.product.prodname_dotcom %} repository. If you're running [npm v8.5.3](https://github.com/npm/cli/releases/tag/v8.5.3) or later, you can add a summary for the package listing page by including a *README.md* file in your package directory. For more information, see "[Working with package.json](https://docs.npmjs.com/getting-started/using-a-package.json)" and "[How to create Node.js Modules](https://docs.npmjs.com/getting-started/creating-node-modules)" in the npm documentation.
|
||||
|
||||
You can publish multiple packages to the same {% data variables.product.prodname_dotcom %} repository by including a `URL` field in the *package.json* file. For more information, see "[Publishing multiple packages to the same repository](#publishing-multiple-packages-to-the-same-repository)."
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
When a package is published, it isn't automatically linked to a repository. You can however choose to link your published package to a repository using the user interface or command line. For more information, see "[Connecting a repository to a package](/packages/learn-github-packages/connecting-a-repository-to-a-package)."
|
||||
{% endif %}
|
||||
|
||||
You can set up the scope mapping for your project using either a local *.npmrc* file in the project or using the `publishConfig` option in the *package.json*. {% data variables.product.prodname_registry %} only supports scoped npm packages. Scoped packages have names with the format of `@owner/name`. Scoped packages always begin with an `@` symbol. You may need to update the name in your *package.json* to use the scoped name. For example, `"name": "@codertocat/hello-world-npm"`.
|
||||
|
||||
{% ifversion packages-npm-v2 %}
|
||||
When you first publish a package, the default visibility is private. When a package is linked to repository, the package visibility is dependent on the repository's visibility. To change the visibility or set access permissions, see "[Configuring a package's access control and visibility](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)."
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.package_registry.viewing-packages %}
|
||||
|
||||
### Publishing a package using a local *.npmrc* file
|
||||
|
|
|
@ -0,0 +1,5 @@
|
|||
# Issue 7039
|
||||
# npm Package Registry Improvements (v2) GA
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
|
@ -4,4 +4,4 @@ You can use a personal access token (PAT) to authenticate to {% data variables.p
|
|||
|
||||
To authenticate to a {% data variables.product.prodname_registry %} registry within a {% data variables.product.prodname_actions %} workflow, you can use:
|
||||
- `GITHUB_TOKEN` to publish packages associated with the workflow repository.
|
||||
- a PAT to install packages associated with other private repositories (which `GITHUB_TOKEN` can't access).
|
||||
- a PAT with at least `packages:read` scope to install packages associated with other private repositories (which `GITHUB_TOKEN` can't access).
|
||||
|
|
|
@ -1,11 +0,0 @@
|
|||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
|
||||
To authenticate to the {% data variables.product.prodname_container_registry %} within a {% data variables.product.prodname_actions %} workflow, use the `GITHUB_TOKEN` for the best security and experience. If your workflow is using a personal access token (PAT) to authenticate to `{% data reusables.package_registry.container-registry-hostname %}`, then we highly recommend you update your workflow to use the `GITHUB_TOKEN`.
|
||||
|
||||
{% ifversion fpt or ghec %}For guidance on updating your workflows that authenticate to `{% data reusables.package_registry.container-registry-hostname %}` with a personal access token, see "[Upgrading a workflow that accesses `ghcr.io`](/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions#upgrading-a-workflow-that-accesses-ghcrio)."{% endif %}
|
||||
|
||||
For more information about the `GITHUB_TOKEN`, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow#using-the-github_token-in-a-workflow)."
|
||||
|
||||
If you're using the {% data variables.product.prodname_container_registry %} in actions, follow our security best practices at "[Security hardening for GitHub Actions](/actions/getting-started-with-github-actions/security-hardening-for-github-actions#considering-cross-repository-access)."
|
||||
|
||||
{% endif %}
|
|
@ -0,0 +1,7 @@
|
|||
If your workflow is using a personal access token (PAT) to authenticate to a registry, then we highly recommend you update your workflow to use the `GITHUB_TOKEN`.
|
||||
|
||||
{% ifversion fpt or ghec %}For guidance on updating your workflows that authenticate to a registry with a personal access token, see "[Upgrading a workflow that accesses a registry using a PAT](/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions#upgrading-a-workflow-that-accesses-a-registry-using-a-pat)."{% endif %}
|
||||
|
||||
For more information about the `GITHUB_TOKEN`, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow#using-the-github_token-in-a-workflow)."
|
||||
|
||||
For more information about the best practises when using a registry in actions, see "[Security hardening for GitHub Actions](/actions/getting-started-with-github-actions/security-hardening-for-github-actions#considering-cross-repository-access)."
|
|
@ -0,0 +1 @@
|
|||
{% ifversion fpt or ghec %} The {% data variables.product.prodname_registry %} GraphQL API does not support containers or Docker images that use the package namespace `https://ghcr.io/OWNER/PACKAGE-NAME`, or npm images that use the package namespace `https://npm.pkg.github.com/OWNER/PACKAGE-NAME`.{% endif %}
|
|
@ -139,6 +139,10 @@ prodname_registry: 'GitHub Packages'
|
|||
prodname_container_registry: 'Container registry'
|
||||
prodname_docker_registry_namespace: '{% ifversion fpt or ghec %}`docker.pkg.github.com`{% elsif ghes or ghae %}<code>docker.<em>HOSTNAME</em></code>{% endif %}'
|
||||
prodname_container_registry_namespace: '{% ifversion fpt or ghec %}`ghcr.io`{% elsif ghes or ghae %}<code>containers.<em>HOSTNAME</em></code>{% endif %}'
|
||||
prodname_npm_registry: 'npm registry'
|
||||
prodname_ghcr_and_npm_registry: '{% data variables.product.prodname_container_registry %}{% ifversion packages-npm-v2 %} and {% data variables.product.prodname_npm_registry %}{% endif %}'
|
||||
prodname_ghcr_or_npm_registry: '{% data variables.product.prodname_container_registry %}{% ifversion packages-npm-v2 %} or {% data variables.product.prodname_npm_registry %}{% endif %}'
|
||||
prodname_ghcr_and_npm_registry_full: '{% data variables.product.prodname_container_registry %} (`ghcr.io`){% ifversion packages-npm-v2 %} and {% data variables.product.prodname_npm_registry %} (`npm.pkg.github.com`){% endif %}'
|
||||
|
||||
# GitHub Insights
|
||||
prodname_insights: 'GitHub Insights'
|
||||
|
|
Загрузка…
Ссылка в новой задаче