The GitHub Advisory Database now includes curated security advisories for vulnerabilities on GitHub Actions. This brings the Advisory Database to ten supported ecosystems, including: Composer, Go, Hex, Maven, npm, NuGet, pip, RubyGems and Rust.
If you have a dependency on any vulnerable GitHub Actions, GitHub will send Dependabot alerts over the coming days.
Ubuntu 22.04 is now generally available on GitHub-hosted runners. To use it now, simply add runs-on: ubuntu-22.04 in your workflow file. Otherwise, our recommendation is to use ubuntu-latest, which currently utilizes Ubuntu 20.04 but will begin running on Ubuntu 22.04 in the near future. This will ensure your workflows are always using a recent OS and removes the need to constantly update workflow files with image versions.
jobs:
build:
runs-on: ubuntu-22.04
steps:
- uses: actions/checkout@v2
- uses: actions/setup-dotnet@v1
- name: Build
run: dotnet build
- name: Run tests
run: dotnet testThe Ubuntu 22.04 runner image has different tools and tool versions than Ubuntu 20.04.
Read more on available runner images and beta images terms of use in our documentation.
The Ubuntu 18.04 Actions runner image started our deprecation process on 8/8/22 and will be fully unsupported by 12/1/22. To raise awareness of the upcoming removal, jobs using Ubuntu 18.04 will temporarily fail during scheduled time periods defined below:
What you need to do
Workflows using the ubuntu-18.04 YAML workflow label should be updated to ubuntu-20.04, ubuntu-22.04, or ubuntu-latest. You can always get up-to-date information on our tools by reading about the software in GitHub Actions virtual environments. Please contact GitHub Support if you run into any problems or need help.
Actions runner support for Apple silicon hardware, such as the M1 chip, is now generally available. This provides teams with the capability to run self-hosted macOS workflows in a macOS ARM64 runtime. Now the Actions runner supports M1 and the ARM64 runtime meaning developers can run it on their own M1 or M2 hardware.
Based on initial testing, there are currently two issues to be aware of:
setup-python. The fix for that can be tracked here.For additional information on how to set up a self-hosted macOS ARM64 runner, please refer to our documentation. If you have any feedback or questions for Actions self-hosted Apple silicon support, you can submit an issue in the runner repository.
When users access an organization with SAML SSO, GitHub stores a link between the SAML identity and the user's GitHub account. This link is used by SCIM and team synchronization to grant access within your organization or enterprise. If you break this link by signing into that organization with a different SAML identity, you are likely to lose access to resources inside that organization.
Starting gradually today and being fully rolled out tomorrow, users will see a warning message if they attempt to sign in with a different SAML account and change their linked identity. They'll have the option to go back to their IdP to sign in with a different account, which is usually the correct option. If they really intend to break the link to their previous SAML account and link to a new one, they can choose to continue.
Learn more by reading "About Authentication with SAML SSO".
We’ve expanded access to GitHub’s security overview pages in two ways:
Security overview provides a centralized view of risk for application security teams, engineering leaders, and developers who work across many repositories. It displays code scanning, Dependabot, and secret scanning alerts across every repository you have access to in an organization or enterprise. The security overview also shows you where you have unknown risks because security features haven’t been enabled.
Learn more about security overview and send us your feedback
The repository that houses the images installed on GitHub-hosted runners has been renamed from actions/virtual-environments to actions/runner-images. These images are maintained by GitHub and used by GitHub Actions.
If you have forked this repository you will not be affected by this change.
All git clone, git fetch, or git push operations targeting the previous location will continue to function as if made on the new location. However, to reduce confusion, you should update any existing local clones to point to the new repository URL.
For more information and updates you can visit the newly improved runner images repository.
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.
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.
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):
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.
Unlike commit comments, pull request review comments do not surface outside the context of the pull request since they belong to the pull request.
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:
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.
This change did not impact a user’s ability to add, view, or manage comments on individual commits.
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.
If you have feedback or questions about this change, let us know here: https://github.com/orgs/community/discussions/28924
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.
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 > *)"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
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.
Previously we retained self-hosted GitHub Action runners in the GitHub Actions UI for 30 days after they were last seen to connect. With the growth in the use of ephemeral runners and the scale of use of self-hosted, this is becoming hard for users to manage. As a result, we are making the following changes to the time we retain offline runners for.
A non-ephemeral self-hosted Actions runner is automatically removed from GitHub if we have not seen it connect to GitHub for more than 14 days.
An ephemeral self-hosted Actions runner is automatically removed from GitHub if we have not seen it connect to GitHub for more than one day.
Learn more about self-hosted runners in GitHub Actions
[August 2, 2022] Update: In order to better reach and improve the web experience for enterprise users, we are adding non-essential web cookies to certain subdomains that specifically market our products to businesses. These cookies will provide analytics to help us improve and deliver a better site experience for our enterprise customers, and enable us to further our support for enterprises through personalized content and marketing around our enterprise solutions.
The developer community remains the heart of GitHub, and we’re committed to respecting the privacy of developers using our product. We also recognize that we need to improve the developer experience for enterprise users and make it easier for businesses to find our enterprise solutions. This change is only on subdomains where GitHub markets products and services to enterprise customers, and all other GitHub subdomains will continue to operate as-is.
You can learn more and give feedback on our privacy policy here for the next 30 days, after which the change will go into effect.
Organizations participating in the security manager role public beta may now manage security manager teams via the GitHub REST API. In addition, legacy organizations can now participate in the public beta.
Learn more about the security manager REST API and send us your feedback
It's now easier to debug CodeQL analysis problems in code scanning: click Re-run jobs from the GitHub Actions workflow run page, check the Enable debug logging box, and hit the Re-run jobs button.
The data will be uploaded as an Actions artifact named debug-artifacts, attached to the workflow run. Such artifacts contain CodeQL logs, CodeQL databases, and the SARIF files that were produced.
These artifacts will help you when you're debugging problems with CodeQL code scanning. When contacting GitHub support, you might be asked for this data.
As part of the analysis, CodeQL extracts your source code into a relational database format. The debug artifacts include more detailed information about CodeQL extraction errors and warnings that occurred during database creation. If you want to permanently enable debug logging for the CodeQL analysis, or would like more information about troubleshooting CodeQL, please follow these instructions.
This feature is now available to all users on GitHub.com and will also be available in GitHub Enterprise Server 3.7.
GitHub Enterprise Cloud (GHEC) customers can now participate in a private beta enabling audit log streaming to a Datadog endpoint. Audit log streaming to Datadog not only allows enterprises to satisfy long-term data retention goals but also analyze GitHub audit log data using the tools offered by Datadog.
GHEC administrators interested in participating in the private beta should reach out to your GitHub account manager or contact our sales team to make the feature available for your enterprise. Once enabled, administrators can follow the instructions for setting up streaming to Datadog and provide feedback on their experience at the audit log streaming to Datadog community discussion.
You can now manage Actions cache from your terminal by installing the new GitHub CLI extension for Actions cache:
gh extension install actions/gh-actions-cache This extension is built on top of GitHub APIs for cache management and enables you to get:
Learn more about dependency caching to speed up your Actions workflows.
The GitHub Enterprise Server 3.6 Release Candidate is available and contains exciting updates and additions across the board.
Release Candidates are a way for you to try the latest features at the earliest time, and they help us gather feedback early to ensure the release works in your environment. They should be tested on non-production environments. Here are some highlights for this release.
Read about these features and more in the full GitHub Enterprise Server 3.6 release notes. We look forward to hearing your feedback! Contact our Support team with any questions.
Dependabot alerts will now show more information on an alert's activity. In the details page for a Dependabot alert, you will see a timeline of events (e.g. opened, fixed, reopened). Events will also show additional metadata when available, like relevant pull requests.
For more information, see our documentation for Dependabot alerts.
The repository file finder is a convenient way to jump to a specific file by typing part of its path. It can be accessed by pressing t or using the “Go to file” button.
The file finder hides files in directories like vendor/ and build/ by default. These exclusions can now by customized using linguist attributes in a .gitattributes file. For example:
vendor/** linguist-vendored=false
build/** linguist-generated=false
Learn more about the file finder
Learn more about .gitattributes
The new "For you" feed (Public Beta) is now sorted in chronological order.
For questions or feedback, visit the GitHub Feed feedback.