GitHub Enterprise Cloud customers can access IP addresses for audit log entries for enterprise owned assets

The ability for GitHub Enterprise Cloud owners to display members’ IP addresses for all audit logs events for private repositories and other enterprise assets, such as issues and projects, is generally available.

These IP addresses can be used to improve threat analyses and further secure your software. Note, IP addresses will continue to not be displayed for activity related to public repositories.

For additional information, read about displaying IP addresses in the audit log for your enterprise.

Comments on individual commits made outside a pull request no longer appear in the pull request timeline

Code review on GitHub has evolved a lot since we introduced the ability to comment on an individual commit in 2008. Users today can propose a change using a pull request, which provides a first-class experience for reviewing, discussing, evolving, and ultimately accepting or rejecting a change. While pull requests are the recommended way to review and discuss proposed changes, commenting on individual commits is still currently supported.

We recently rolled out a change to no longer show comments added to individual commits (comments added outside the context of a pull request) on the pull request timeline. Previously, if a pull request happened to include a commit that had commit comments, those comments would appear on that pull request’s timeline. Users often reported that these comments were irrelevant to the pull request or caused confusion when added by someone not involved in the review.

Note: this change does not impact the ability for users to comment on individual commits or review a pull request one commit at a time.

Comparing commit comments and review comments

To help understand this change, let’s compare commit comments with pull request review comments.

A commit comment is a comment added by a GitHub user to an individual commit or to a line of a file changed in a commit. Commit comments are stored on GitHub and surface in various places in the GitHub UI, including at the bottom of the commit page (/:org/:repo/commit/:sha):

image

A commit comment is associated with a commit. A commit comment cannot be added from the pull request page and cannot be replied to or resolved like a pull request review comment because it does not belong to the pull request. A commit comment can be indirectly associated with a pull request if that pull request includes the commit.

A pull request review comment is a comment added by a GitHub user to a changed line (or the lines surrounding it) in a pull request. Review comments are usually added from the Files changed or Commits tab of the pull request page and are directly associated with the pull request.

image

Unlike commit comments, pull request review comments do not surface outside the context of the pull request since they belong to the pull request.

What changed

Prior to this change, comments on individual commits (made outside the context of the pull request) would appear in the timeline of any pull request that included that commit:

image

With this change, commit comments (like the highlighted 029541b comment) no longer appear in the pull request timeline.

The timeline events REST and GraphQL APIs also no longer return commit comments associated with any commits included in the pull request.

What did not change

This change did not impact a user’s ability to add, view, or manage comments on individual commits.

  • Users can still add comments to individual commits or changed lines in a commit
    image
  • Users can still review pull requests one commit at a time and add review comments
  • Commit comments still surface on the commits listing page
    image
  • Commit comments still surface at the bottom of the commit page
  • Commit comments are still accessible from the Commits tab of the pull request page
    image
  • Commits pushed to a pull request head branch still surface in the timeline and on the Commits tab of the pull request page

There was also no impact to commit messages, i.e. the message stored with the Git commit. Commit messages continue to surface everywhere they previously surfaced, including on the pull request page.

We want to hear from you

If you have feedback or questions about this change, let us know here: https://github.com/orgs/community/discussions/28924

See more

Introducing the new npm Dependency Selector Syntax

npm query is a new top-level command as of npm v8.16.0 which accepts a Dependency Selector (as defined in the Dependency Selector Syntax Specification) & returns a filtered JSON Array/NodeList of dependencies from your project. We believe this capability has been a missing piece of the package management ecosystem; With its introduction we hope to unlock the potential for developers to self-serve in asking new, complex questions about their dependencies, their relationships & associative metadata.

For many JavaScript developers, the Dependency Selector Syntax will look very familiar as it is actually an adapted form of CSS. We leveraged this existing, known language & its operators to make disparate package information broadly accessible.

Example Uses:

If I wanted to list all of my dependencies (similar to npm list --all) I can run:

npm query "*"

If I wanted to find every version of react & lodash in my project I can run:

npm query "#react, #lodash"

If I wanted to find all react versions not-defined as a peer dependency I can run:

npm query "#react:not(.peer)"

If I wanted to find all the dependencies in my project that used an MIT license I'd change that query to be:

npm query "[license=MIT]"

If I wanted to find all the git dependencies in my project I can run:

npm query ":type(git)"

If I wanted to find out which of my transitive dependencies used a postinstall script I could run:

npm query ":attr(scripts, [postinstall]):not(:root > *)"

Programmatic Usage

We know many developers in the ecosystem will also want to leverage this new syntax themselves, so we've built it right into the programmatic brain of the CLI. Under the hood, we’ve added a new .querySelectorAll() method to the existing Node Class we use in the @npmcli/arborist library. Tooling authors can now load up & query their dependencies just like we do.

// index.js
const Arborist = require('@npmcli/arborist')
const arb = new Arborist({})

arb.loadActual((tree) => {
  // query all workspaces
  const results = await tree.querySelectorAll('.workspace')
  console.log(results)
})

You can learn more about the syntax & usage in our documentation here: https://docs.npmjs.org/cli/v8/using-npm/dependency-selectors

What's next?

Looking ahead we’ve got work planned to add new pseudo states & selectors based on registry metadata that should unlock another host of capabilities aimed at auditing (examples include: :outdated :deprecated :vulnerable :cve() & :cwe()). As documented in the original RFC proposal we will also consider supporting a query flag or reading from stdin to existing commands.

See more
View all changes