packages

Subscribe to all “packages” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

Changes to token permission on packages

Announcing changes to permissions for packages.

We are restricting the refs REST API endpoint from accepting POSTs from users and apps that only have the permission to read and write packages. Previously, this endpoint accepted updates to both tags and branches.

If that ability is critical to your development flows you will now be required to add explicit contents permissions to create refs.

A small cohort of customers relying on this flow have been notified of these changes and will have additional time to remediate.

We appreciate your feedback in GitHub's public feedback discussions.

See more

Packages: Fine-grained permissions and organization-level publishing are now available for the GitHub Packages RubyGems registry

The GitHub Packages RubyGems registry now runs on a new architecture, unlocking great new capabilities:

Publishing packages at organization level with GitHub Packages

Previously, RubyGems packages published to GitHub Packages were closely coupled to their repositories. Now packages can be published at an organization level. They can still be linked to a repository at any time, if needed.

Learn more about connecting a repository to a package.

Fine grained permissions for RubyGems packages published to GitHub Packages

You can now configure Actions and Codespaces repository access on the package's settings page, or invite other users to access the package. Additionally, RubyGems packages published to GitHub Packages can still be configured to automatically inherit all permissions from a linked repository.

Learn more about configuring a package's access control.

Internal visibility

In addition to public and private, a package's visibility can now also be set to internal. It is then visible for all members of the GitHub organization.

These new features are now available to all users on github.com.

Read more about working with the GitHub RubyGems registry

We appreciate your feedback on these new changes in GitHub's public community discussions!

See more

Packages: Fine-grained permissions and organization-level publishing are now available for the GitHub Packages NuGet registry

The GitHub Packages NuGet registry now runs on a new architecture, unlocking great new capabilities:

Publishing packages at organization level with GitHub Packages

Previously, NuGet packages published to GitHub Packages were closely coupled to their repositories. Now packages can be published at an organization level. They can still be linked to a repository at any time, if needed.

Learn more about connecting a repository to a package.

Fine grained permissions for NuGet packages published to GitHub Packages

You can now configure Actions and Codespaces repository access on the package's settings page, or invite other users to access the package. Additionally, NuGet packages published to GitHub Packages can still be configured to automatically inherit all permissions from a linked repository.

Learn more about configuring a package's access control.

Internal visibility

In addition to public and private, a package's visibility can now also be set to internal. It is then visible for all members of the GitHub organization.

These new features are now available to all users on github.com.

Read more about working with the GitHub NuGet registry

We appreciate your feedback on these new changes in GitHub's public community discussions!

See more

Packages: Consolidated owner and admin role

Previously, the original publisher of a package in GitHub Packages had the owner attribute, which granted them admin privileges for the package. The current package admin role has the exact same privileges.

As of today the two roles with identical privileges are being merged and the admin role can be used as the ultimate authority. By default, both the original publisher and the organization owner will have admin privileges on that package.

In addition to uploading and downloading a package, admins can manage a package, read and write package metadata and grant package permissions.

As part of this change, the owner badge is no longer shown next to the package publisher's username.

Learn more about permissions for packages

See more

Packages: Fine-grained permissions and organization-level publishing are now available for the GitHub Packages npm registry

The GitHub Packages npm registry now runs on a new architecture, unlocking great new capabilities:

Publishing packages at organization level with GitHub Packages

Previously, npm packages published to GitHub packages were closely coupled to their repositories. Now packages can be published at an organization level. They can still be linked to a repository at any time, if needed.

Learn more about connecting a repository to a package.

Fine grained permissions for npm packages published to GitHub Packages

You can now configure Actions and Codespaces repository access on the package’s settings page, or invite other users to access the package. Additionally, npm packages published to GitHub packages can still be configured to automatically inherit all permissions from a linked repositories.

Learn more about configuring a package’s access control.

Internal visibility

In addition to public and private, a package’s visibility can now also be set to internal. It is then visible for all members of the GitHub organization.

These new features are now available to all users on github.com.

Read more about working with the GitHub npm registry

We appreciate your feedback on these new changes in GitHub’s public community discussions!

See more

Deprecation Notice: GraphQL for Packages

GitHub Packages is being re-platformed, unlocking great capabilities such as fine-grained permissions, org-level publishing and increased performance.

Package registries on the new GitHub Packages architecture, including container registry and npm packages, no longer expose data through the GraphQL API. We recommend using the REST API instead.

In the coming months we will be migrating our other GitHub Package registries to this new architecture deprecating the GraphQL API for those registries as well.

If you have any questions, please contact GitHub Support.

See more

GitHub Packages Container registry is generally available!

GitHub Packages Container registry, ghcr.io, is now generally available! Container registry provides the best developer experience for publishing, managing, and consuming containers on GitHub. For more information, check out the Container registry general availability blog post.

Learn more about GitHub Container registry

For questions, visit the GitHub Packages community

To see what's next for Packages, visit our public roadmap

See more

Packages: ghcr.io maintenance mode on 2021-06-05

On June 5th, 2021 the GitHub Container Registry, ghcr.io, will be put into maintenance mode. The maintenance window will occur from 16:00 – 17:30 UTC. During this short time pushes to the service will be blocked, however pulls or downloads will remain available. For more detailed status information during maintenance, please refer to https://githubstatus.com

Learn more about GitHub Container Registry

For questions, visit the GitHub Packages community

To see what's next for Packages, visit our public roadmap

See more

Packages: Container registry now supports GITHUB_TOKEN

You can now use GITHUB_TOKEN to authenticate with the Packages Container registry in your Actions workflows. Say goodbye to all those PATs (delete them from your profile too!), and say hello to using the GITHUB_TOKEN in your workflows to read, create, update, and delete containers. 

      - name: Login to Packages Container registry
        uses: docker/login-action@v1 
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
-          password: ${{ secrets.PAT }}
+          password: ${{ secrets.GITHUB_TOKEN }}

Write and read access of Actions to containers can be managed in the container settings.

manage actions access animation

Learn more about authenticating to Container registry with GitHub Actions

For questions, visit the GitHub Packages community

To see what's next for Packages, visit our public roadmap

See more

Packages: internal visibility now available for Container registry

The GitHub Packages Container registry can now create and use containers set with Internal visibility. Internal visibility allows all members of an organization and all organizations within an enterprise read access to the container to more easily share data with your teammates.

This feature is generally available today on GitHub Enterprise Cloud. Navigate to your organization's Packages settings and click the option for Internal visibility to enable.

image

Learn more about configuring visibility for container images

For questions, visit the GitHub Packages community

To see what's next for Packages, visit our public roadmap

See more

Packages: time has been dropped from npm package metadata responses

The Packages npm registry no longer returns a time value in metadata responses. This was done to allow for substantial performance improvements. We continue to have all the data necessary to return a time value as part of the metadata response and will resume returning this value in the future once we have solved the existing performance issues.

Learn more about the Packages npm registry

For questions, visit the GitHub Packages community

To see what's next for Packages, visit our public roadmap

Note: This post originally inaccurately referred to time as not being returned in the “official npm specification”. While an “official npm specification” does not exist, time is referred to in the registry package-metadata documentation and used for some commands.

See more

Packages: delete and restore for all packages

You can now delete and restore any package type within GitHub Packages, even publicly visible packages. Any package or package version of yours can now be deleted through the github.com website or REST APIs. The ability to delete any package will help you manage the packages you want to keep in your account. Any package deleted within the last 30 days can also be restored to undo a delete and bring the package back to its original state.

Learn more about deleting and restoring packages and Packages REST APIs

For questions, visit the GitHub Packages community

To see what's next for Packages, visit our public roadmap

See more

Packages can filter for tagged and untagged containers

As more and more versions of containers are published it can become harder to find the tagged images in between a long list of untagged images which create a lot of noise. Now when you visit the version list page of a container, like the super-linter versions, you'll see options for listing tagged, untagged, and all images. We default to showing only the tagged images on the version list page to keep the list limited to the most important images.

This filtering is only available for GitHub Packages containers (beta).

See more

Packages container support is an opt-in beta

You can now more easily opt-in to the public beta of GitHub Packages' improved containers experience. New users and organizations can opt-in to the beta for their organization using either organization settings, or for their user account using user feature preview.

Current organizations and users of the Packages containers beta will be automatically opted-in for continued access to service.

See Enabling improved container support for more information.

See more
View more changes