jprdonnelly/docs
1
0
Fork 0
mirror of synced 2025-12-25 02:17:36 -05:00
Code Issues Projects Releases Wiki Activity

Hack week 2025: remove unneeded FBV instances (17) (#53992)

Browse Source 
Co-authored-by: Felicity Chapman <felicitymay@github.com>
This commit is contained in:
mc
2025-01-17 17:07:14 +00:00
committed by GitHub
parent dc4227ccdc
commit 56fc8371a5
16 changed files with 14 additions and 65 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
content/packages/learn-github-packages/viewing-packages.md
View File

@@ -21,17 +21,10 @@ versions:
Your ability to view a package depends on several factors. By default, you can view all packages you have published.
{% ifversion packages-registries-v2 %}
Repository-scoped packages inherit their permissions and visibility from the repository in which the package is published. Some registries **only** support repository-scoped packages. For a list of these registries, see [AUTOTITLE](/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 scoped to a personal account or organization. You can choose to use granular permissions or connect the package to a repository and inherit the repository's permissions. For more information, see [AUTOTITLE](/packages/learn-github-packages/connecting-a-repository-to-a-package) and [AUTOTITLE](/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 [AUTOTITLE](/packages/learn-github-packages/about-permissions-for-github-packages).
{% endif %}
{% data reusables.package_registry.package-page-info %}
## Viewing a repository's packages

20
content/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions.md
View File

@@ -22,8 +22,6 @@ layout: inline
You can extend the CI and CD capabilities of your repository by publishing or installing packages as part of your workflow.
{% ifversion packages-registries-v2 %}
### Authenticating to package registries with granular permissions
Some {% data variables.product.prodname_registry %} registries support granular permissions. This means you can choose to allow packages to be scoped to a user or an organization, or linked to a repository. For the list of registries that support granular permissions, see [AUTOTITLE](/packages/learn-github-packages/about-permissions-for-github-packages#granular-permissions-for-userorganization-scoped-packages).
@@ -32,18 +30,14 @@ Some {% data variables.product.prodname_registry %} registries support granular
### Authenticating to package registries with repository-scoped permissions
{% endif %}
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 [AUTOTITLE](/packages/learn-github-packages/about-permissions-for-github-packages#permissions-for-repository-scoped-packages).
{% 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 [AUTOTITLE](/packages/learn-github-packages/about-permissions-for-github-packages#permissions-for-repository-scoped-packages).
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 [AUTOTITLE](/actions/security-guides/automatic-token-authentication).
If you want your workflow to access a {% data variables.product.prodname_registry %} registry that does not support granular permissions, then 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 [AUTOTITLE](/actions/security-guides/automatic-token-authentication).
You can reference the `GITHUB_TOKEN` in your workflow file using the {% raw %}`${{ secrets.GITHUB_TOKEN }}`{% endraw %} context. For more information, see [AUTOTITLE](/actions/security-guides/automatic-token-authentication).
## About permissions and package access
{% ifversion packages-registries-v2 %}
### Packages scoped to users or organizations
Registries that support granular permissions allow users to create and administer packages as free-standing resources at the organization level. Packages can be scoped to an organization or personal account and you can customize access to each of your packages separately from repository permissions.
@@ -52,14 +46,10 @@ All workflows accessing registries that support granular permissions should use
### 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 [AUTOTITLE](/actions/security-guides/automatic-token-authentication#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 packages-registries-v2 %}
## Default permissions and access settings for packages modified through workflows
For packages in registries that support granular permissions, when you create, install, modify, or delete a package through a workflow, there are some default permission and access settings used to ensure admins have access to the workflow. You can adjust these access settings as well. For the list of registries that support granular permissions, see [AUTOTITLE](/packages/learn-github-packages/about-permissions-for-github-packages#granular-permissions-for-userorganization-scoped-packages).
@@ -78,8 +68,6 @@ These are more examples of how default permissions work for workflows that manag
You can also adjust access to packages in a more granular way or adjust some of the default permissions behavior. For more information, see [AUTOTITLE](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility).
{% endif %}
## Publishing a package using an action
You can use {% data variables.product.prodname_actions %} to automatically publish packages as part of your continuous integration (CI) flow. This approach to continuous deployment (CD) allows you to automate the creation of new package versions, if the code meets your quality standards. For example, you could create a workflow that runs CI tests every time a developer pushes code to a particular branch. If the tests pass, the workflow can publish a new package version to {% data variables.product.prodname_registry %}.
@@ -192,8 +180,6 @@ Installing packages hosted by {% data variables.product.prodname_registry %} thr
{% data reusables.package_registry.actions-configuration %}
{% ifversion packages-registries-v2 %}
## Upgrading a workflow that accesses a registry using a {% data variables.product.pat_generic %}
{% 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`.
@@ -268,5 +254,3 @@ jobs:
docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
docker push $IMAGE_ID:$VERSION
```
{% endif %}

3
content/packages/working-with-a-github-packages-registry/working-with-the-container-registry.md
View File

@@ -54,14 +54,11 @@ When installing or publishing a Docker image, the {% data variables.product.prod
{% data reusables.package_registry.authenticate-packages %}
{% ifversion packages-registries-v2 %}
### Authenticating in a {% data variables.product.prodname_actions %} workflow
This registry supports granular permissions. {% data reusables.package_registry.authenticate_with_pat_for_v2_registry %}
{% data reusables.package_registry.v2-actions-codespaces %}
{% endif %}
### Authenticating with a {% data variables.product.pat_v1 %}