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!

GitHub Enterprise Cloud (GHEC) customers can now participate in a public beta enabling audit log streaming to a Datadog endpoint. Joining this beta allows enterprises to continue to satisfy long-term data retention goals and also analyze GitHub audit log data using the tools offered by Datadog.

GHEC administrators interested in participating in the public beta can enable audit log streaming by following the instructions for setting up streaming to Datadog. Customers can provide feedback on their experience at the audit log streaming to Datadog community discussion.

See more

The default code scanning query suites include checks for the most important security vulnerabilities for each supported language, so that any potential problems can be surfaced to developers before they are committed to their repository. However, in some situations a particular check is not relevant for a codebase and you might prefer to not run that CodeQL query. You can now easily exclude queries using code scanning query filters.

Query filters use the same syntax as CodeQL query suites and you can filter on any CodeQL query metadata property. Query filters must be specified in a custom code scanning configuration file, which you refer to from your code scanning analysis workflow file.

In your code scanning workflow file, use the config-file parameter of the init action to specify the path to the configuration file you want to use:

- uses: github/codeql-action/init@v2
  with:
    config-file: path/to/config/file.yml

In your configuration file, specify the query filters you want to use. For example, to exclude the Unsafe HTML constructed from library input query from the default code scanning query suite for JavaScript you can specify its id in an exclude block:

name: "My code scanning CodeQL config"

query-filters:
- exclude:
     id: js/html-constructed-from-input

For more information about how to use query filters, see Configuring code scanning in the code scanning documentation.

See more