When resolving security alerts for vulnerable transitive npm dependencies, it is possible that updating a direct dependency will remove the vulnerable transitive dependency from the tree. Dependabot can now resolve these security alerts by creating a pull request that removes the unnecessary transitive dependency.
You can now display your local timezone on your profile to give others an idea of when to expect responses to pull requests or issues from you. You can opt into this feature by navigating to Settings > Public Profile and checking Display current local time. You can also update this information directly from your profile by clicking 'Edit Profile' under your avatar.
This will display your timezone in the left sidebar of your profile as well as your timezone's current deviation from UTC. When other users see your profile or user hovercard, they'll see your timezone as well as how many hours behind or ahead they are from your local time.
You can now programmatically view and act on Dependabot alerts via the REST API. New endpoints to view, list, and update Dependabot alerts are available in a public beta.
For more information, see Dependabot alerts in the REST API reference or learn more about Dependabot alerts in our documentation.
Node 12 has been out of support since April 2022, as a result we have started the deprecation process of Node 12 for GitHub Actions. We plan to migrate all actions to run on Node16 by Summer 2023. We will monitor the progress of the migration and listen to the community for how things are going before we define a final date.
To raise awareness of the upcoming change, we are adding a warning into workflows which contain Actions running on Node 12. This will come into effect starting on September 27th.
What you need to do
For Actions maintainers: Update your actions to run on Node 16 instead of Node 12 (Actions configuration settings)
For Actions users: Update your workflows with latest versions of the actions which runs on Node 16 (Using versions for Actions)
We have started creating and storing CodeQL databases for the most popular open-source projects on GitHub.com. If you use CodeQL for security research, you can now obtain these databases easily and directly through the CodeQL extension for Visual Studio Code, which makes it much easier to write and run your own custom CodeQL queries.
The CodeQL engine powers GitHub code scanning: it analyses source code and flags up potential security problems (for example, in pull requests). By default, code scanning runs a large set of open source queries that are able to identify the most important and common security problems.
CodeQL is also a powerful tool for variant analysis and other types of security research. CodeQL treats source code as data, and anyone can write custom CodeQL queries to explore a codebase and identify vulnerabilities. Like code search on steroids!
The first step of any CodeQL analysis is extracting the source code into a CodeQL database. This database contains a relational representation of the source code — including elements like the abstract syntax tree, the data flow graph, and the control flow graph. You can create CodeQL databases yourself using the CodeQL CLI, but with the feature we shipped today, it's much quicker to get started: you can download a ready-built CodeQL database from GitHub.com.
To download a CodeQL database for use in the CodeQL extension in VS Code:
owner/repo identifier of the public repository you'd like to analyze.
Once you've downloaded a CodeQL database, you're ready to start your research. Find more information in the CodeQL documentation.
We currently store databases for over 200,000 repositories on GitHub.com. That list is constantly growing and evolving to make sure that it includes the most interesting codebases for security research.
We create and store databases for all of the languages that we support in CodeQL code scanning. For more information, see About code scanning with CodeQL.
Yes, you can also download CodeQL databases using the GitHub REST API. For more information, see Downloading databases from GitHub.com in the CodeQL CLI documentation.
If there is a repository that you'd like to analyze, but a CodeQL database is not available yet, then you can trigger the creation (and storing) of a database by enabling GitHub code scanning with the CodeQL engine. Alternatively, you could fork the repository and enable code scanning on the fork. For more information, see the code scanning documentation.
Today, we're adding support for users to create a GitHub Sponsors profile and choose to receive sponsorship payouts via a fiscal host. This will give maintainers more flexibility and choice in how they receive funding. This has already been possible for organizations creating a GitHub Sponsors profile, and that remains unchanged. Users and organizations can still choose to use a Stripe Connect account instead of a fiscal host if they prefer. Learn more about signing up for a GitHub Sponsors profile using a fiscal host.
GitHub Mobile can no longer connect to GitHub Enterprise Server 3.1. To enable connections from GitHub Mobile to GitHub Enterprise Server, a site administrator must upgrade to GitHub Enterprise Server 3.2 or later. Newer versions of GitHub Enterprise Server improve performance, enhance security, and provide new features. For more information, see "GitHub Enterprise Server releases" and "Upgrading GitHub Enterprise Server."
Read more about GitHub Mobile and send us your feedback to help us improve.
We recently released the ability to use web based authentication for the npm login and npm publish commands with the --auth-type=web flag. Now we are extending this feature to all the other commands that require authentication or OTP verification.
This feature is available from CLI version 8.19.1
A month ago we shared an update about the help.github.com URL. Starting today help.github.com will start redirecting to GitHub's Support Portal at support.github.com
Users should continue to use docs.github.com to reach GitHub Docs.
Any links starting with 'help.github.com/' will continue to work as expected.
Enterprise administrators can now choose to redirect signed-out Enterprise Managed Users to their company's single sign-on (SSO) page. This feature is available as a public beta.
By default, enterprises with Managed Users enabled are hidden, showing a 404 error page any time an enterprise resource is visited by a user that isn't already signed in to the enterprise.
If you enable this feature for your enterprise, visitors to resources in your enterprise, org, or user namespaces will immediately be presented with an SSO redirect if not already signed in to your enterprise.
This redirect helps users sign in to the correct account, rather than giving them the impression that the link they were given no longer works.
You can find this setting in the Authentication security section of your Enterprise Settings, below the single sign-on configuration sections.
Read more about this settings at "Automatic redirection for Enterprise Managed Users".
The author of the Git commit created when squash merging a pull request is now shown before merging. Previously, the commit author was only shown when merging with a merge commit.
Also, if the user merging the pull request also opened it and has multiple email addresses configured, a drop-down now lets them choose a different email address to use for the commit's author.
These improvements are designed to ensure Git commits created by squash merging are associated with the correct email address.
Learn more about merging a pull request.
In order to streamline sponsoring maintainers, we're changing the custom amount settings for GitHub Sponsors. Starting October 3rd, 2022, all Sponsors profiles will have custom amounts enabled by default.
Introducing “Edit File” within pull requests on GitHub for iOS! Make quick updates to existing pull requests to fix those pesky typos or add that missing method before merging.
File editing for pull requests within GitHub for Android is coming later this year.
When GitHub creates merge commits, like to test whether a pull request can be merged cleanly or to actually merge a pull request, it now uses the merge-ort strategy. merge-ort is a relatively new Git merge strategy that is significantly faster (for example, complex merge commits that previously took 5 or more seconds to create are now created in less than 200 milliseconds) and addresses subtle correctness issues found in the merge-recursive strategy. And because merge-ort is the default merge strategy in the latest releases of Git, merge results are now more predictable and consistent between your local machine and GitHub.
Learn more about the Git merge-ort strategy and merge methods for pull requests.
GitHub's audit log allows admins to quickly review the actions performed by members of their Enterprise. It includes details such as who performed the action, what the action was, and when it was performed. To ensure the audit log can be used as an effective security and compliance tool, GitHub is constantly evaluating new audit log events and ensuring those events have the necessary fields to provide meaningful context. GitHub has made the following enhancements to the Enterprise audit logs:
business.sso_response and org.sso_response events will be displayed in the REST API and audit log streaming payloads for GitHub Enterprise Cloud (GHEC) and GitHub Enterprise Server (GHES) version 3.8 or later. repo.rename, project.rename, and protected_branch.update_name events will now include the old_name field make clear the current and past name of renamed repos, projects, and protected branches.Customers will now be able to use the GITHUB_TOKEN with workflow_dispatch and repository_dispatch events to trigger workflows. Prior to this change, events triggered by GITHUB_TOKEN would not create a new workflow run. This was done to prevent the accidental trigger of endless workflows. This update makes an exception for workflow_dispatch and repository_dispatch events since they are explicit calls made by the customer and not likely to end up in a loop.
name: Create Workflow Dispatch
on:
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Trigger Workflow
uses: actions/github-script@v6
with:
script: |
github.rest.actions.createWorkflowDispatch({
owner: context.repo.owner,
repo: context.repo.repo,
workflow_id: 'test.yml',
ref: 'main',
})For more details see
Triggering a workflow from a workflow.
For questions, visit the GitHub Actions community.
To see what’s next for Actions, visit our public roadmap.
Your GitHub repositories with Dependabot alerts enabled and Dependabot security updates enabled will automatically generate Dependabot pull requests for vulnerable npm transitive dependencies.
Previously, Dependabot couldn't generate a security update for a transitive dependency when its parent dependency required incompatible specific version range. In this locked state, developers had to manually upgrade the parent and transitive dependencies.
Now, Dependabot will be able to create pull requests for npm projects that upgrade both the parent and child dependencies together.
For example, if a vulnerability for the transitive dependency node-forge triggers a Dependabot alert and allows a PR to be created:
Prior to this change Dependabot would fail to create a Dependabot security update for transitive dependencies :confused:. But not anymore! 😀 Now, Dependabot will unlock the node-forge security update by bumping the parent webpack-dev-server version in addition to patching the `node-forge dependency within the same Pull Request!
This change will apply to pull requests generated by Dependabot that update vulnerable npm packages.
Custom repository roles enable Enterprise organization administrators to define and assign least-privilege roles for their repositories, beyond the standard Read, Triage, Write, Maintain, and Admin roles.
Now, REST API endpoints to create and update custom repository roles are available in a public beta for GitHub Enterprise Cloud customers. These new endpoints build on the existing custom repository role APIs that allow assignment of those roles to a team or user. The endpoints accept PATs from organization admins, as well as calls from properly authorized OAuth and GitHub apps.
These REST APIs will be supported in GitHub Enterprise Server 3.8, after they reach general availability in GitHub Enterprise Cloud.
Find out more about programmatically creating custom repository roles.
We'd love to get your feedback through your account team, or in our community Discussions board topic.
In the Development section of an issue, you can now link existing branches (or pull requests) to that issue. Learn more about manually linking branches to an issue.
When opening a pull request from a comparison that only includes one commit, GitHub defaults the title and description to the subject line and body of that commit's message. Authors who write detailed git commit messages that adhere to the widely accepted convention of wrapping at 72 characters per line may have noticed that this can result in strange formatting because of how GitHub Flavored Markdown treats newlines.
We now take and automatically reformat the commit message when suggesting the pull request description, making it look just as good as the commit message it came from when viewed on github.com, GitHub Mobile, and other tools.
