зеркало из https://github.com/github/docs.git
[2022-12-07]: Improvements to NuGet registry (#32240)
Co-authored-by: Vanessa <vgrl@github.com>
This commit is contained in:
Isaac Brown
GitHub
Родитель
65b581fe53
Коммит
c3f5734495
|
|
@ -1,120 +0,0 @@
|
|||
---
|
||||
title: Allowing your codespace to access a private image registry
|
||||
intro: 'You can use secrets to allow {% data variables.product.prodname_github_codespaces %} to access a private image registry'
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Codespaces
|
||||
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_container_registry %}, {% data variables.product.prodname_npm_registry %}, Azure Container Registry, or DockerHub.
|
||||
|
||||
{% data variables.packages.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_github_codespaces %} to access images stored in that registry.
|
||||
|
||||
## Accessing images stored in {% data variables.packages.prodname_ghcr_and_npm_registry %}
|
||||
|
||||
{% data variables.packages.prodname_ghcr_and_npm_registry %} provide the easiest way for {% data variables.product.prodname_github_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)" 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.packages.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.packages.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.packages.prodname_ghcr_or_npm_registry %} using a {% data variables.product.pat_generic %}.
|
||||
|
||||
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)."
|
||||
|
||||
### Accessing an image published to the organization a codespace will be launched in
|
||||
|
||||
If you want a container image to be accessible to all codespaces in an organization, we recommend that you publish the container image with internal visibility. This will automatically make the image visible to all codespaces within the organization, unless the repository the codespace is launched from is public.
|
||||
|
||||
If the codespace is being launched from a public repository referencing an internal or private image, you must manually allow the public repository access to the internal container image. This prevents the internal image from being accidentally leaked publicly. 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)."
|
||||
|
||||
### Accessing a private container from a subset of repositories in an organization
|
||||
|
||||
If you want to allow a subset of an organization's repositories to access a container image, or allow an internal or private image to be accessed from a codespace launched in a public repository, you can manually add repositories to a container <span class="x x-first x-last">image's</span> access settings. 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)<span class="x x-first x-last">.</span>"
|
||||
|
||||
### Publishing a container image from a codespace
|
||||
|
||||
Seamless access from a codespace to {% data variables.packages.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 {% data variables.product.pat_v1 %} 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)" 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.packages.prodname_ghcr_or_npm_registry %}, {% data variables.product.prodname_github_codespaces %} checks for the presence of three secrets, which define the server name, username, and {% data variables.product.pat_generic %} 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`
|
||||
- `<*>_CONTAINER_REGISTRY_PASSWORD`
|
||||
|
||||
You can store secrets at the user, repository, or organization-level, allowing you to share them securely between different codespaces. When you create a set of secrets for a private image registry, you need to replace the "<*>" in the name with a consistent identifier. For more information, see "[Managing encrypted secrets for your codespaces](/codespaces/managing-your-codespaces/managing-encrypted-secrets-for-your-codespaces)" and "[Managing encrypted secrets for your repository and organization for {% data variables.product.prodname_github_codespaces %}](/codespaces/managing-codespaces-for-your-organization/managing-encrypted-secrets-for-your-repository-and-organization-for-github-codespaces)."
|
||||
|
||||
If you are setting the secrets at the user or organization level, make sure to assign those secrets to the repository you'll be creating the codespace in by choosing an access policy from the dropdown list.
|
||||
|
||||
|
||||
|
||||
### Example secrets
|
||||
|
||||
For a private image registry in Azure, you could create the following secrets:
|
||||
|
||||
```
|
||||
ACR_CONTAINER_REGISTRY_SERVER = mycompany.azurecr.io
|
||||
ACR_CONTAINER_REGISTRY_USER = acr-user-here
|
||||
ACR_CONTAINER_REGISTRY_PASSWORD = <PERSONAL_ACCESS_TOKEN>
|
||||
```
|
||||
|
||||
For information on common image registries, see "[Common image registry servers](#common-image-registry-servers)." Note that accessing AWS Elastic Container Registry (ECR) is different.
|
||||
|
||||
|
||||
|
||||
Once you've added the secrets, you may need to stop and then start the codespace you are in for the new environment variables to be passed into the container. For more information, see "[Suspending or stopping a codespace](/codespaces/codespaces-reference/using-the-command-palette-in-codespaces#suspending-or-stopping-a-codespace)."
|
||||
|
||||
#### Accessing AWS Elastic Container Registry
|
||||
|
||||
To access AWS Elastic Container Registry (ECR), you can provide an AWS access key ID and secret key, and {% data variables.product.prodname_dotcom %} can retrieve an access token for you and log in on your behalf.
|
||||
|
||||
```
|
||||
*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
|
||||
*_CONTAINER_REGISTRY_USER = <AWS_ACCESS_KEY_ID>
|
||||
*_CONTAINER_REGISTRY_PASSWORD = <AWS_SECRET_KEY>
|
||||
```
|
||||
|
||||
You must also ensure you have the appropriate AWS IAM permissions to perform the credential swap (e.g. `sts:GetServiceBearerToken`) as well as the ECR read operation (either `AmazonEC2ContainerRegistryFullAccess` or `ReadOnlyAccess`).
|
||||
|
||||
Alternatively, if you don't want GitHub to perform the credential swap on your behalf, you can provide an authorization token fetched via AWS's APIs or CLI.
|
||||
|
||||
```
|
||||
*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
|
||||
*_CONTAINER_REGISTRY_USER = AWS
|
||||
*_CONTAINER_REGISTRY_PASSWORD = <TOKEN>
|
||||
```
|
||||
|
||||
Since these tokens are short lived and need to be refreshed periodically, we recommend providing an access key ID and secret.
|
||||
|
||||
While these secrets can have any name, so long as the `*_CONTAINER_REGISTRY_SERVER` is an ECR URL, we recommend using `ECR_CONTAINER_REGISTRY_*` unless you are dealing with multiple ECR registries.
|
||||
|
||||
For more information, see AWS ECR's "[Private registry authentication documentation](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry_auth.html)."
|
||||
|
||||
### Common image registry servers
|
||||
|
||||
Some of the common image registry servers are listed below:
|
||||
|
||||
- [DockerHub](https://docs.docker.com/engine/reference/commandline/info/) - `https://index.docker.io/v1/`
|
||||
- [GitHub Container Registry](/packages/working-with-a-github-packages-registry/working-with-the-container-registry) - `ghcr.io`
|
||||
- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/) - `<registry name>.azurecr.io`
|
||||
- [AWS Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html) - `<aws_account_id>.dkr.ecr.<region>.amazonaws.com`
|
||||
- [Google Cloud Container Registry](https://cloud.google.com/container-registry/docs/overview#registries) - `gcr.io` (US), `eu.gcr.io` (EU), `asia.gcr.io` (Asia)
|
||||
|
||||
## Debugging private image registry access
|
||||
|
||||
If you are having trouble pulling an image from a private image registry, make sure you are able to run `docker login -u <user> -p <password> <server>`, using the values of the secrets defined above. If login fails, ensure that the login credentials are valid and that you have the apprioriate permissions on the server to fetch a container image. If login succeeds, make sure that these values are copied appropriately into the right {% data variables.product.prodname_github_codespaces %} secrets, either at the user, repository, or organization level and try again.
|
||||
|
|
@ -0,0 +1,124 @@
|
|||
---
|
||||
title: Allowing your codespace to access a private registry
|
||||
intro: 'You can allow {% data variables.product.prodname_github_codespaces %} to access container images or other packages in a private registry.'
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Codespaces
|
||||
redirect_from:
|
||||
- /codespaces/codespaces-reference/allowing-your-codespace-to-access-a-private-image-registry
|
||||
shortTitle: Access a private registry
|
||||
---
|
||||
|
||||
## About private registries and {% data variables.product.prodname_github_codespaces %}
|
||||
|
||||
A registry is a secure space for storing, managing, and fetching container images or other packages. There are many examples of registries, such as:
|
||||
- {% data variables.product.company_short %}'s {% data variables.product.prodname_container_registry %}, the Azure Container Registry, and DockerHub for container images
|
||||
- The {% data variables.product.prodname_npm_registry %} for Node.js packages.
|
||||
|
||||
Certain {% data variables.product.prodname_registry %} registries, including the {% data variables.product.prodname_container_registry %}, can be configured to allow packages to be pulled seamlessly into {% data variables.product.prodname_github_codespaces %} during codespace creation, without having to provide any authentication credentials.
|
||||
|
||||
To access other container image registries, you can create secrets in {% data variables.product.prodname_dotcom %} to store the access details, which will allow {% data variables.product.prodname_github_codespaces %} to access images stored in that registry.
|
||||
|
||||
## Accessing packages stored in registries with granular permissions
|
||||
|
||||
{% data variables.product.prodname_registry %} registries that support granular permissions, including the {% data variables.product.prodname_container_registry %}, provide the easiest way for {% data variables.product.prodname_github_codespaces %} to consume packages. For the list of {% data variables.product.prodname_registry %} registries that support granular permissions and seamless {% data variables.product.prodname_github_codespaces %} access, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages#granular-permissions-for-userorganization-scoped-packages)."
|
||||
|
||||
### Accessing a package published to the same repository as the codespace
|
||||
|
||||
If you publish a package in the same repository that the codespace is being launched in, you will automatically be able to fetch that package on codespace creation. You won't have to provide any additional credentials, unless the **Inherit access from repo** option was unselected when the package was published.
|
||||
|
||||
#### Inheriting access from the repository from which a package was published
|
||||
|
||||
By default, the package inherits the access setting of the repository from which it was published. For example, if the repository is public, the package is also public. If the repository is private, the package 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 a registry using a {% data variables.product.pat_generic %}.
|
||||
|
||||
If the **Inherit access from repo** option was not selected when the package was published, you can manually add the repository to the published package'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)."
|
||||
|
||||
### Accessing a package published to the organization a codespace will be launched in
|
||||
|
||||
If you want a package to be accessible to all codespaces in an organization, we recommend that you publish the package with internal visibility. This will automatically make the package visible to all codespaces within the organization, unless the repository the codespace is launched from is public.
|
||||
|
||||
If the codespace is being launched from a public repository referencing an internal or private package, you must manually allow the public repository access to the internal package. This prevents the internal package from being accidentally leaked publicly. 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)."
|
||||
|
||||
### Accessing a private package from a subset of repositories in an organization
|
||||
|
||||
If you want to allow a subset of an organization's repositories to access a package, or allow an internal or private package to be accessed from a codespace launched in a public repository, you can manually add repositories to a package's access settings. 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)."
|
||||
|
||||
### Publishing a package from a codespace
|
||||
|
||||
Seamless access from a codespace to a registry is limited to pulling packages. If you want to publish a package from inside a codespace, you must use a {% data variables.product.pat_v1 %} with the `write:packages` scope.
|
||||
|
||||
We recommend publishing packages 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 registries
|
||||
|
||||
You can define secrets to allow {% data variables.product.prodname_github_codespaces %} to access container image registries other than {% data variables.product.company_short %}'s {% data variables.product.prodname_container_registry %}. If you are accessing a container image from a registry that doesn't support seamless access, {% data variables.product.prodname_github_codespaces %} checks for the presence of three secrets, which define the server name, username, and {% data variables.product.pat_generic %} for a 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`
|
||||
- `<*>_CONTAINER_REGISTRY_PASSWORD`
|
||||
|
||||
You can store secrets at the user, repository, or organization-level, allowing you to share them securely between different codespaces. When you create a set of secrets for a private image registry, you need to replace the "<*>" in the name with a consistent identifier. For more information, see "[Managing encrypted secrets for your codespaces](/codespaces/managing-your-codespaces/managing-encrypted-secrets-for-your-codespaces)" and "[Managing encrypted secrets for your repository and organization for {% data variables.product.prodname_github_codespaces %}](/codespaces/managing-codespaces-for-your-organization/managing-encrypted-secrets-for-your-repository-and-organization-for-github-codespaces)."
|
||||
|
||||
If you are setting the secrets at the user or organization level, make sure to assign those secrets to the repository you'll be creating the codespace in by choosing an access policy from the dropdown list.
|
||||
|
||||
|
||||
|
||||
### Example secrets
|
||||
|
||||
For a private image registry in Azure, you could create the following secrets:
|
||||
|
||||
```
|
||||
ACR_CONTAINER_REGISTRY_SERVER = mycompany.azurecr.io
|
||||
ACR_CONTAINER_REGISTRY_USER = acr-user-here
|
||||
ACR_CONTAINER_REGISTRY_PASSWORD = <PERSONAL_ACCESS_TOKEN>
|
||||
```
|
||||
|
||||
For information on common image registries, see "[Common image registry servers](#common-image-registry-servers)." Note that accessing AWS Elastic Container Registry (ECR) is different.
|
||||
|
||||
|
||||
|
||||
Once you've added the secrets, you may need to stop and then start the codespace you are in for the new environment variables to be passed into the container. For more information, see "[Suspending or stopping a codespace](/codespaces/codespaces-reference/using-the-command-palette-in-codespaces#suspending-or-stopping-a-codespace)."
|
||||
|
||||
#### Accessing AWS Elastic Container Registry
|
||||
|
||||
To access AWS Elastic Container Registry (ECR), you can provide an AWS access key ID and secret key, and {% data variables.product.prodname_dotcom %} can retrieve an access token for you and log in on your behalf.
|
||||
|
||||
```
|
||||
*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
|
||||
*_CONTAINER_REGISTRY_USER = <AWS_ACCESS_KEY_ID>
|
||||
*_CONTAINER_REGISTRY_PASSWORD = <AWS_SECRET_KEY>
|
||||
```
|
||||
|
||||
You must also ensure you have the appropriate AWS IAM permissions to perform the credential swap (e.g. `sts:GetServiceBearerToken`) as well as the ECR read operation (either `AmazonEC2ContainerRegistryFullAccess` or `ReadOnlyAccess`).
|
||||
|
||||
Alternatively, if you don't want GitHub to perform the credential swap on your behalf, you can provide an authorization token fetched via AWS's APIs or CLI.
|
||||
|
||||
```
|
||||
*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
|
||||
*_CONTAINER_REGISTRY_USER = AWS
|
||||
*_CONTAINER_REGISTRY_PASSWORD = <TOKEN>
|
||||
```
|
||||
|
||||
Since these tokens are short lived and need to be refreshed periodically, we recommend providing an access key ID and secret.
|
||||
|
||||
While these secrets can have any name, so long as the `*_CONTAINER_REGISTRY_SERVER` is an ECR URL, we recommend using `ECR_CONTAINER_REGISTRY_*` unless you are dealing with multiple ECR registries.
|
||||
|
||||
For more information, see AWS ECR's "[Private registry authentication documentation](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry_auth.html)."
|
||||
|
||||
### Common image registry servers
|
||||
|
||||
Some of the common image registry servers are listed below:
|
||||
|
||||
- [DockerHub](https://docs.docker.com/engine/reference/commandline/info/) - `https://index.docker.io/v1/`
|
||||
- [GitHub Container Registry](/packages/working-with-a-github-packages-registry/working-with-the-container-registry) - `ghcr.io`
|
||||
- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/) - `<registry name>.azurecr.io`
|
||||
- [AWS Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html) - `<aws_account_id>.dkr.ecr.<region>.amazonaws.com`
|
||||
- [Google Cloud Container Registry](https://cloud.google.com/container-registry/docs/overview#registries) - `gcr.io` (US), `eu.gcr.io` (EU), `asia.gcr.io` (Asia)
|
||||
|
||||
## Debugging private image registry access
|
||||
|
||||
If you are having trouble pulling an image from a private image registry, make sure you are able to run `docker login -u <user> -p <password> <server>`, using the values of the secrets defined above. If login fails, ensure that the login credentials are valid and that you have the appropriate permissions on the server to fetch a container image. If login succeeds, make sure that these values are copied appropriately into the right {% data variables.product.prodname_github_codespaces %} secrets, either at the user, repository, or organization level and try again.
|
||||
|
|
@ -5,7 +5,7 @@ versions:
|
|||
fpt: '*'
|
||||
ghec: '*'
|
||||
children:
|
||||
- /allowing-your-codespace-to-access-a-private-image-registry
|
||||
- /allowing-your-codespace-to-access-a-private-registry
|
||||
- /using-github-copilot-in-github-codespaces
|
||||
- /using-the-github-codespaces-plugin-for-jetbrains
|
||||
- /using-the-vs-code-command-palette-in-codespaces
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ You can add encrypted secrets to your personal account that you want to use in y
|
|||
- Access tokens to cloud services
|
||||
- Service principals
|
||||
- Subscription identifiers
|
||||
- [Credentials for a private image registry](/codespaces/codespaces-reference/allowing-your-codespace-to-access-a-private-image-registry)
|
||||
- Credentials for a private image registry (for more information, see "[Allowing your codespace to access a private registry](/codespaces/codespaces-reference/allowing-your-codespace-to-access-a-private-registry)")
|
||||
|
||||
You can choose which repositories should have access to each secret. Then, you can use the secret in any codespace you create for a repository that has access to the secret. To share a secret with a codespace created from a template, you will need to publish the codespace to a repository on {% data variables.product.prodname_dotcom %}, then give that repository access to the secret.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,31 +10,40 @@ versions:
|
|||
shortTitle: About permissions
|
||||
---
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
The permissions for packages are either repository-scoped or user/organization-scoped.
|
||||
{% endif %}
|
||||
{% ifversion packages-registries-v2 %}
|
||||
The permissions for packages can be scoped either to a user or an organization or to a repository.
|
||||
|
||||
## 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. {% 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 **only** use repository-scoped permissions:
|
||||
|
||||
{% ifversion not fpt or ghec %}- Docker registry (`docker.pkg.github.com`){% endif %}
|
||||
{% ifversion packages-npm-v2 %}{% else %}- npm registry{% endif %}
|
||||
- RubyGems registry
|
||||
- Apache Maven registry
|
||||
- NuGet registry
|
||||
|
||||
{% ifversion packages-npm-v2 %}For {% data variables.packages.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, the {% data variables.packages.prodname_ghcr_and_npm_registry %} offer granular permissions for your container image packages.
|
||||
The following {% data variables.product.prodname_registry %} registries support granular permissions.
|
||||
|
||||
- {% data variables.product.prodname_container_registry %}
|
||||
{% ifversion packages-npm-v2 %}- npm registry{% endif %}
|
||||
{% ifversion packages-nuget-v2 %}- NuGet registry{% endif %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Permissions for {% ifversion packages-registries-v2 %}repository-scoped {% endif %}packages
|
||||
|
||||
A {% ifversion packages-registries-v2 %}repository-scoped {% endif %}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 %}
|
||||
|
||||
{% ifversion packages-registries-v2 %}
|
||||
The following {% data variables.product.prodname_registry %} registries **only** support repository-scoped permissions.
|
||||
|
||||
{% ifversion not fpt or ghec %}- Docker registry (`docker.pkg.github.com`){% endif %}
|
||||
{% ifversion packages-npm-v2 %}{% else %}- npm registry{% endif %}
|
||||
- RubyGems registry
|
||||
- Apache Maven registry
|
||||
- Gradle registry
|
||||
{% ifversion packages-nuget-v2 %}{% else %}- NuGet registry{% endif %}
|
||||
|
||||
For {% ifversion ghes %}the {% data variables.product.prodname_container_registry %}{% else %}other registries{% endif %}, you can choose to allow packages to be scoped to a user or an organization, or linked to a repository. {% ifversion docker-ghcr-enterprise-migration %}For 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 %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% ifversion packages-registries-v2 %}
|
||||
## Visibility and access permissions for container images
|
||||
|
||||
{% data reusables.package_registry.visibility-and-access-permissions %}
|
||||
|
|
|
|||
|
|
@ -11,18 +11,22 @@ versions:
|
|||
ghes: '*'
|
||||
shortTitle: Access control & visibility
|
||||
---
|
||||
{% data reusables.package_registry.container-registry-ghes-beta %}
|
||||
{% data reusables.package_registry.container-registry-ghes-beta %}{% ifversion packages-registries-v2 %}
|
||||
|
||||
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.packages.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 %}
|
||||
Some registries only support repository-scoped permissions. For the list of these registries, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages#permissions-for-repository-scoped-packages)."
|
||||
|
||||
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)."
|
||||
{% else %}A package inherits the permissions and visibility of the repository that owns the package.{% endif %} For more information about permissions for 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)."
|
||||
|
||||
{% ifversion packages-registries-v2 %}
|
||||
|
||||
## Visibility and access permissions for container images
|
||||
|
||||
{% data reusables.package_registry.visibility-and-access-permissions %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Configuring access to container images for your personal account
|
||||
|
||||
If you have admin permissions to a container image that's owned by a personal account, you can assign read, write, or admin roles to other users. For more information about these permission roles, see "[Visibility and access permissions for container images](#visibility-and-access-permissions-for-container-images)."
|
||||
|
|
@ -105,7 +109,7 @@ To further customize access to your container image, see "[Configuring access to
|
|||
{% ifversion fpt or ghec %}
|
||||
## Ensuring {% data variables.product.prodname_github_codespaces %} access to your package
|
||||
|
||||
By default, a codespace can seamlessly access certain packages in the {% data variables.packages.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)."
|
||||
By default, a codespace can seamlessly access certain packages in registries that support granular permissions, such as packages published in the same repository with the **Inherit access** option selected. For the list of {% data variables.product.prodname_registry %} registries that support granular permissions and seamless {% data variables.product.prodname_github_codespaces %} access, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages#granular-permissions-for-userorganization-scoped-packages)."
|
||||
|
||||
Otherwise, to ensure that a codespace has access to your package, you must grant access to the repository where the codespace is being launched.
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,6 @@ On {% data variables.product.prodname_dotcom %}, you can also restore an entire
|
|||
- You restore the package within 30 days of its deletion.
|
||||
- The same package namespace is still available and not used for a new package.
|
||||
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
## Packages API support
|
||||
|
||||
{% data reusables.package_registry.packages-classic-pat-only %}
|
||||
|
|
@ -48,35 +47,30 @@ 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.{% 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 %}
|
||||
{% data reusables.package_registry.about-graphql-support %}
|
||||
|
||||
## Required permissions to delete or restore a package
|
||||
|
||||
{% ifversion packages-registries-v2 %}
|
||||
With registries that support granular permissions, you can choose to allow packages to be scoped to a user or an organization, or linked to a repository.
|
||||
|
||||
To delete a package that has granular permissions separate from a repository, such as container images stored at {% ifversion ghes %}`https://containers.HOSTNAME/OWNER/PACKAGE-NAME`{% else %}`https://ghcr.io/OWNER/PACKAGE-NAME`{% endif %}{% ifversion packages-npm-v2 %} or packages stored at `https://npm.pkg.github.com/OWNER/PACKAGE-NAME`{% endif %}, 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)."
|
||||
|
||||
For packages that inherit their access permissions from repositories, you can delete a package if you have admin permissions to the repository.
|
||||
|
||||
The {% data variables.product.prodname_registry %} registries below **only** use repository-scoped permissions:
|
||||
Some registries **only** support repository-scoped packages. For a list of these registries, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages#permissions-for-repository-scoped-packages)."
|
||||
|
||||
{% 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
|
||||
{% else %}
|
||||
|
||||
{% ifversion packages-npm-v2 %}For {% data variables.packages.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` 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)."
|
||||
You can delete a package if you have admin permissions to the repository to which the package is published.
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Deleting a package version
|
||||
|
||||
### Deleting a version of a repository-scoped package on {% data variables.product.prodname_dotcom %}
|
||||
### Deleting a version of a {% ifversion packages-registries-v2 %}repository-scoped {% endif %}package on {% data variables.product.prodname_dotcom %}
|
||||
|
||||
To delete a version of a repository-scoped package, you must have admin permissions to the repository that owns the package. For more information, see "[Required permissions](#required-permissions-to-delete-or-restore-a-package)."
|
||||
To delete a version of a {% ifversion packages-registries-v2 %}repository-scoped {% endif %}package, you must have admin permissions to the repository that owns the package. For more information, see "[Required permissions](#required-permissions-to-delete-or-restore-a-package)."
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.package_registry.packages-from-code-tab %}
|
||||
|
|
@ -88,11 +82,9 @@ To delete a version of a repository-scoped package, you must have admin permissi
|
|||
|
||||
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
### Deleting a version of a repository-scoped package with GraphQL
|
||||
### Deleting a version of a {% ifversion packages-registries-v2 %}repository-scoped{% endif %} package with GraphQL
|
||||
|
||||
For packages that inherit their permissions and access from repositories, you can use the GraphQL to delete a specific package version.
|
||||
|
||||
{% 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 %}
|
||||
{% data reusables.package_registry.about-graphql-support %}{% ifversion fpt or ghec %} For information on using the REST API instead, see the "[{% data variables.product.prodname_registry %} API](/rest/reference/packages)."{% endif %}
|
||||
|
||||
Use the `deletePackageVersion` mutation in the GraphQL API. You must use a {% data variables.product.pat_v1 %} with the `read:packages`, `delete:packages`, and `repo` scopes. For more information about {% data variables.product.pat_v1_plural %}, see "[About {% data variables.product.prodname_registry %}](/packages/publishing-and-managing-packages/about-github-packages#authenticating-to-github-packages)."
|
||||
|
||||
|
|
|
|||
|
|
@ -51,11 +51,9 @@ 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.packages.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 %} |
|
||||
| Permissions | {% ifversion packages-registries-v2 %}The permissions for a package are either inherited from the repository where the package is hosted, or can be defined for specific user or organization accounts. Some registries only support permissions inherited from a repository. For a list of these registries, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages#permissions-for-repository-scoped-packages)." For more information on package access, 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)."
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
## About billing for {% data variables.product.prodname_registry %}
|
||||
|
||||
|
|
@ -100,19 +98,7 @@ 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.location.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 %}
|
||||
You can delete a private or public package in the {% data variables.product.product_name %} user interface. Or for repo-scoped packages, you can delete a version of a private package using GraphQL.
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghae %}
|
||||
You can delete a version of a package in the {% data variables.product.product_name %} user interface or using the GraphQL API.
|
||||
{% endif %}
|
||||
You can delete a package in the {% data variables.product.product_name %} user interface{% ifversion fpt or ghec %} 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)."{% else %}.{% endif %} {% data reusables.package_registry.about-graphql-support %}
|
||||
|
||||
When you use the GraphQL API to query and delete private packages, you must use the same {% data variables.product.pat_v1 %} you use to authenticate to {% data variables.product.prodname_registry %}.
|
||||
|
||||
|
|
|
|||
|
|
@ -23,19 +23,17 @@ versions:
|
|||
|
||||
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 **only** use this type of permissions:{% ifversion not fpt or ghec %}
|
||||
- Docker registry (`docker.pkg.github.com`){% endif %}
|
||||
{% ifversion packages-npm-v2 %}{% else %}- npm registry{% endif %}
|
||||
- RubyGems registry
|
||||
- Apache Maven registry
|
||||
- NuGet registry
|
||||
{% ifversion packages-registries-v2 %}
|
||||
Repository-scoped packages inherit their permissions and visibility from the repository that owns the package. Some registries **only** support repository-scoped packages. For a list of these registries, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages#permissions-for-repository-scoped-packages)."
|
||||
|
||||
Other registries 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 the repository's permissions. For more information, see "[Connecting a repository to a package](/packages/learn-github-packages/connecting-a-repository-to-a-package)" and "[Configuring a package's access control and visibility](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)."
|
||||
|
||||
{% else %}
|
||||
|
||||
Packages inherit their permissions and visibility from the repository on which they are hosted. For more information, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages)."
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
The {% data variables.packages.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 %}."
|
||||
|
||||
{% data reusables.package_registry.package-page-info %}
|
||||
|
||||
## Viewing a repository's packages
|
||||
|
|
|
|||
|
|
@ -23,37 +23,40 @@ 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.packages.prodname_ghcr_and_npm_registry %}
|
||||
{% ifversion packages-registries-v2 %}
|
||||
### Authenticating to package registries with granular permissions
|
||||
|
||||
{% data reusables.package_registry.authenticate_with_pat_for_v2_registry %}
|
||||
|
||||
### Authenticating to package registries with repository-scoped permissions
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Authenticating to package registries on {% data variables.product.prodname_dotcom %}
|
||||
{% ifversion packages-registries-v2 %}Some {% data variables.product.prodname_registry %} registries only support repository-scoped permissions, and do not support granular permissions. For a list of these registries, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages#permissions-for-repository-scoped-packages)."
|
||||
|
||||
{% ifversion fpt or ghec %}If you want your workflow to authenticate to {% data variables.product.prodname_registry %} to access a package registry other than the {% data variables.product.prodname_container_registry %} on {% data variables.location.product_location %}, then{% else %}To authenticate to package registries on {% data variables.product.product_name %},{% endif %} we recommend using the `GITHUB_TOKEN` that {% data variables.product.product_name %} automatically creates for your repository when you enable {% data variables.product.prodname_actions %} instead of a {% data variables.product.pat_generic %} for authentication. You should set the permissions for this access token in the workflow file to grant read access for the `contents` scope and write access for the `packages` scope. For forks, the `GITHUB_TOKEN` is granted read access for the parent repository. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
|
||||
If you want your workflow to access a {% data variables.product.prodname_registry %} registry that does not support granular permissions, then{% else %}To authenticate to package registries on {% data variables.product.product_name %},{% endif %} we recommend using the `GITHUB_TOKEN` that {% data variables.product.product_name %} automatically creates for your repository when you enable {% data variables.product.prodname_actions %}. You should set the permissions for this access token in the workflow file to grant read access for the `contents` scope and write access for the `packages` scope. For forks, the `GITHUB_TOKEN` is granted read access for the parent repository. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
|
||||
|
||||
You can reference the `GITHUB_TOKEN` in your workflow file using the {% raw %}`{{secrets.GITHUB_TOKEN}}`{% endraw %} context. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token)."
|
||||
|
||||
## About permissions and package access for repository-owned packages
|
||||
## About permissions and package access
|
||||
|
||||
{% note %}
|
||||
{% ifversion packages-registries-v2 %}
|
||||
|
||||
**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.packages.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.
|
||||
### Packages scoped to users or organizations
|
||||
|
||||
{% endnote %}
|
||||
Registries that support granular permissions allow 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 registries that support granular permissions should use the `GITHUB_TOKEN` instead of a {% data variables.product.pat_generic %}. For more information about security best practices, see "[Security hardening for GitHub Actions](/actions/learn-github-actions/security-hardening-for-github-actions#using-secrets)."
|
||||
|
||||
### Packages scoped to repositories
|
||||
|
||||
{% endif %}
|
||||
|
||||
When you enable GitHub Actions, GitHub installs a GitHub App on your repository. The `GITHUB_TOKEN` secret is a GitHub App installation access token. You can use the installation access token to authenticate on behalf of the GitHub App installed on your repository. The token's permissions are limited to the repository that contains your workflow. For more information, see "[Permissions for the GITHUB_TOKEN](/actions/reference/authentication-in-a-workflow#about-the-github_token-secret)."
|
||||
|
||||
{% 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.packages.prodname_ghcr_and_npm_registry %}
|
||||
|
||||
The {% data variables.packages.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.packages.prodname_ghcr_and_npm_registry %} should use the `GITHUB_TOKEN` instead of a {% data variables.product.pat_generic %}. For more information about security best practices, see "[Security hardening for GitHub Actions](/actions/learn-github-actions/security-hardening-for-github-actions#using-secrets)."
|
||||
{% ifversion packages-registries-v2 %}
|
||||
|
||||
## Default permissions and access settings for containers modified through workflows
|
||||
|
||||
|
|
@ -483,14 +486,14 @@ Installing packages hosted by {% data variables.product.prodname_registry %} thr
|
|||
|
||||
{% data reusables.package_registry.actions-configuration %}
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
{% ifversion packages-registries-v2 %}
|
||||
## Upgrading a workflow that accesses a registry using a {% data variables.product.pat_generic %}
|
||||
|
||||
The {% data variables.packages.prodname_ghcr_and_npm_registry %} support the `GITHUB_TOKEN` for easy and secure authentication in your workflows. If your workflow is using a {% data variables.product.pat_generic %} to authenticate to the registry, then we highly recommend you update your workflow to use the `GITHUB_TOKEN`.
|
||||
{% data variables.product.prodname_registry %} supports the `GITHUB_TOKEN` for easy and secure authentication in your workflows. If you're using a registry that supports granular permissions, and your workflow is using a {% data variables.product.pat_generic %} 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)."
|
||||
|
||||
Using the `GITHUB_TOKEN` instead of a {% data variables.product.pat_v1 %}, which includes the `repo` scope, increases the security of your repository as you don't need to use a long-lived {% data variables.product.pat_generic %} that offers unnecessary access to the repository where your workflow is run. For more information about security best practices, see "[Security hardening for GitHub Actions](/actions/learn-github-actions/security-hardening-for-github-actions#using-secrets)."
|
||||
Using the `GITHUB_TOKEN`, instead of a {% data variables.product.pat_v1 %} with the `repo` scope, increases the security of your repository as you don't need to use a long-lived {% data variables.product.pat_generic %} that offers unnecessary access to the repository where your workflow is run. For more information about security best practices, see "[Security hardening for GitHub Actions](/actions/learn-github-actions/security-hardening-for-github-actions#using-secrets)."
|
||||
|
||||
1. Navigate to your package landing page.
|
||||
1. In the left sidebar, click **Actions access**.
|
||||
|
|
|
|||
|
|
@ -103,22 +103,16 @@ $ npm login --scope=@OWNER --registry=https://HOSTNAME/_registry/npm/
|
|||
|
||||
{% 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.
|
||||
|
||||
{% data reusables.package_registry.publishing-user-scoped-packages %}
|
||||
{% 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
|
||||
|
|
|
|||
|
|
@ -26,6 +26,10 @@ shortTitle: NuGet registry
|
|||
|
||||
{% data reusables.package_registry.authenticate-packages %}
|
||||
|
||||
{% ifversion packages-nuget-v2 %}
|
||||
You can choose to give access permissions to packages independently for {% data variables.product.prodname_github_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 `GITHUB_TOKEN` in {% data variables.product.prodname_actions %}
|
||||
|
||||
Use the following command to authenticate to {% data variables.product.prodname_registry %} in a {% data variables.product.prodname_actions %} workflow using the `GITHUB_TOKEN` instead of hardcoding a {% data variables.product.pat_generic %} in a nuget.config file in the repository:
|
||||
|
|
@ -45,7 +49,7 @@ To authenticate to {% data variables.product.prodname_registry %} with the `dotn
|
|||
You must replace:
|
||||
- `USERNAME` with the name of your personal account on {% data variables.product.prodname_dotcom %}.
|
||||
- `TOKEN` with your {% data variables.product.pat_v1 %}.
|
||||
- `OWNER` with the name of the user or organization account that owns the repository containing your project.{% ifversion ghes or ghae %}
|
||||
- `OWNER` with the name of the user or organization account that owns {% ifversion packages-nuget-v2 %}the package you want to install, or to which you want to publish a package{% else %}the repository containing your project{% endif %}.{% ifversion ghes or ghae %}
|
||||
- `HOSTNAME` with the host name for {% data variables.location.product_location %}.{% endif %}
|
||||
|
||||
{% ifversion ghes %}If your instance has subdomain isolation enabled:
|
||||
|
|
@ -91,6 +95,16 @@ If your instance has subdomain isolation disabled:
|
|||
|
||||
You can publish a package to {% data variables.product.prodname_registry %} by authenticating with a *nuget.config* file, or by using the `--api-key` command line option with your {% data variables.product.prodname_dotcom %} {% data variables.product.pat_v1 %}.
|
||||
|
||||
{% ifversion packages-nuget-v2 %}
|
||||
|
||||
The NuGet registry stores packages within your organization or personal account, and allows you to associate packages with a repository. You can choose whether to inherit permissions from a repository, or set granular permissions independently of a repository.
|
||||
|
||||
{% data reusables.package_registry.publishing-user-scoped-packages %}
|
||||
|
||||
If you specify a `RepositoryURL` in your `nuget.config` file, the published package will automatically be connected to the specified repository. For more information, see "[Publishing a package using a `nuget.config` file](/packages/working-with-a-github-packages-registry/working-with-the-nuget-registry#publishing-a-package-using-a-nugetconfig-file)." For information on linking an already-published package to a repository, see "[Connecting a repository to a package](/packages/learn-github-packages/connecting-a-repository-to-a-package)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Publishing a package using a GitHub {% data variables.product.pat_generic %} as your API key
|
||||
|
||||
If you don't already have a PAT to use for your account on {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.location.product_location %}{% endif %}, see "[Creating a {% data variables.product.pat_generic %}](/github/authenticating-to-github/creating-a-personal-access-token)."
|
||||
|
|
@ -121,8 +135,8 @@ When publishing, you need to use the same value for `OWNER` in your *csproj* fil
|
|||
dotnet new console --name OctocatApp
|
||||
```
|
||||
3. Add your project's specific information to your project's file, which ends in *.csproj*. You must replace:
|
||||
- `OWNER` with the name of the user or organization account that owns the repository containing your project.
|
||||
- `REPOSITORY` with the name of the repository containing the package you want to publish.
|
||||
- `OWNER` with the name of the user or organization account that owns the repository to which you want to connect your package.
|
||||
- `REPOSITORY` with the name of the repository to which you want to connect your package.
|
||||
- `1.0.0` with the version number of the package.{% ifversion ghes or ghae %}
|
||||
- `HOSTNAME` with the host name for {% data variables.location.product_location %}.{% endif %}
|
||||
``` xml
|
||||
|
|
@ -155,7 +169,7 @@ When publishing, you need to use the same value for `OWNER` in your *csproj* fil
|
|||
|
||||
## Publishing multiple packages to the same repository
|
||||
|
||||
To publish multiple packages to the same repository, you can include the same {% data variables.product.prodname_dotcom %} repository URL in the `RepositoryURL` fields in all *.csproj* project files. {% data variables.product.prodname_dotcom %} matches the repository based on that field.
|
||||
To connect multiple packages to the same repository, you can include the same {% data variables.product.prodname_dotcom %} repository URL in the `RepositoryURL` fields in all *.csproj* project files. {% data variables.product.prodname_dotcom %} matches the repository based on that field.
|
||||
|
||||
For example, the *OctodogApp* and *OctocatApp* projects will publish to the same repository:
|
||||
|
||||
|
|
|
|||
|
|
@ -20,6 +20,6 @@ To use this API, you must authenticate using a {% data variables.product.pat_v1
|
|||
- To delete packages and package versions, your token must include the `read:packages` and `delete:packages` scopes.
|
||||
- To restore packages and package versions, your token must include the `read:packages` and `write:packages` scopes.
|
||||
|
||||
If your `package_type` is `npm`, `maven`, `rubygems`, or `nuget`, then your token must also include the `repo` scope since your package inherits permissions from a {% data variables.product.prodname_dotcom %} repository. If your package is in the {% data variables.product.prodname_container_registry %}, then your `package_type` is `container` and your token does not need the `repo` scope to access or manage this `package_type`. `container` packages offer granular permissions separate from a repository. For more information, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries)."
|
||||
If your package is in a registry that supports granular permissions, then your token does not need the `repo` scope to access or manage this package. If your package is in a registry that only supports repository-scoped permissions, then your token must also include the `repo` scope since your package inherits permissions from a {% data variables.product.prodname_dotcom %} repository. For a list of registries that only support repository-scoped permissions, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages#permissions-for-repository-scoped-packages)."
|
||||
|
||||
If you want to use the {% data variables.product.prodname_registry %} API to access resources in an organization with SSO enabled, then you must enable SSO for your {% data variables.product.pat_v1 %}. For more information, see "[Authorizing a {% data variables.product.pat_generic %} for use with SAML single sign-on](/github/authenticating-to-github/authorizing-a-personal-access-token-for-use-with-saml-single-sign-on){% ifversion fpt %}" in the {% data variables.product.prodname_ghe_cloud %} documentation.{% else %}."{% endif %}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
# Issue 7874
|
||||
# npm NuGet Registry Improvements (v2) Public Beta
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
# Feature flag for versions that have at least one "v2" GitHub Packages registry.
|
||||
# We use this feature flag when we refer generically to granular permissions
|
||||
# and user/organization-scoped packages, without mentioning specific registries.
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>=3.5'
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
{% ifversion packages-registries-v2 %}For certain registries, you{% else %}You{% endif %} can use GraphQL to delete a version of a private package.
|
||||
|
||||
{% data reusables.package_registry.no-graphql-to-delete-packages %}
|
||||
|
|
@ -1,6 +1,8 @@
|
|||
If your workflow is using a {% data variables.product.pat_generic %} to authenticate to a registry, then we highly recommend you update your workflow to use the `GITHUB_TOKEN`.
|
||||
Some {% data variables.product.prodname_registry %} registries support granular permissions. This means you can choose to allow packages to be owned by a user or an organization, or linked to a repository. For the list of registries that support granular permissions, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages#granular-permissions-for-userorganization-scoped-packages)."
|
||||
|
||||
{% ifversion fpt or ghec %}For guidance on updating your workflows that authenticate to a registry with a {% data variables.product.pat_generic %}, see "[Upgrading a workflow that accesses a registry using a {% data variables.product.pat_generic %}](/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-personal-access-token)."{% endif %}
|
||||
For registries that support granular permissions, if your workflow is using a {% data variables.product.pat_generic %} to authenticate to a registry, then we highly recommend you update your workflow to use the `GITHUB_TOKEN`.
|
||||
|
||||
For guidance on updating your workflows that authenticate to a registry with a {% data variables.product.pat_generic %}, see "[Upgrading a workflow that accesses a registry using a {% data variables.product.pat_generic %}](/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-personal-access-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)."
|
||||
|
||||
|
|
|
|||
|
|
@ -1 +1,3 @@
|
|||
{% 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 %}
|
||||
{% ifversion packages-registries-v2 %}
|
||||
You cannot use the {% data variables.product.prodname_registry %} GraphQL API with registries that support granular permissions. For the registries that **only** support repository-scoped permissions, and can be used with the GraphQL API, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages#permissions-for-repository-scoped-packages)."
|
||||
{% endif %}
|
||||
|
|
@ -0,0 +1 @@
|
|||
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)."
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
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 %}'
|
||||
Загрузка…
Ссылка в новой задаче