Changelog

Subscribe to all Changelog 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

Custom repository roles are now GA

Custom repository roles are now GA for GitHub.com and Enterprise Server 3.5.

Organization admins can create custom repository roles available to all repositories in their organization. Roles can be configured from a set of 35 fine grained permissions covering discussions, issues, pull requests, repos, and security alerts. Once a role is created, repository admins can assign a custom role to any individual or team in their repository.

Custom repository roles can be managed in the Repository roles tab of your Organization settings:

image

Custom repository roles are also supported in the GitHub REST APIs. The Custom Roles API can be used to list all custom repository roles in an organization, and the existing APIs for granting repository access to individuals and teams support custom repository roles.

To get started with custom repository roles, read the docs.

See more

Improvements for community contributions

In February 2022, we launched a new feature called community contributions to security advisories.

We have made a handful of changes to the UX based on your feedback:

  • Fixed the breadcrumb on unreviewed advisories to more clearly display they are unreviewed.
  • Hid the link to submit a community contribution when it is not possible due to OSV constraints.
  • Added an information icon clarifying that not all ecosystems are supported.
  • Updated the auto-generated PR title to the format "[GHSA-####-####-####] Advisory Name" to be clearer on which advisory its for.
  • Fixed a bug that was adding unnecessary noise to the PR diff.
  • Added function to auto-post an affirming comment when a contribution is accepted.
  • Learn more about the GitHub Advisory Database
  • Learn more about GitHub community contributions
See more

Dependency graph adds vulnerability alerting support for Rust

The dependency graph now supports detecting Rust (Cargo.{toml,lock}) files. These will be displayed within the dependency graph section in the Insights tab. Users will receive Dependabot alerts and updates for vulnerabilities associated with their Rust dependencies. Package metadata, including mapping packages to repositories, will be added at a later date.

Learn more about the dependency graph.

See more

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

GitHub Enterprise Cloud owners now have the ability to opt-in to display enterprise members’ IP addresses for all
events involving enterprise-owned private repositories and enterprise-owned assets, such as issues and projects, in your
audit log.
This additional information 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.

See more

Enable Dependabot version updates from the repository settings page

Dependabot version updates help you keep your dependencies up-to-date by opening pull requests automatically when new versions are available.

With this release, you can now more easily enable and configure Dependabot version updates from your repository’s settings page. Within the "Dependabot" section of the "Code security and analysis" tab, you can choose to enable Dependabot version updates, which will prompt you to create a dependabot.yml config file. If a dependabot.yml file exists, you can access that from the repository settings page.

Note: you still need to configure Dependabot version updates with a dependabot.yml file to enable it.

For more information, learn more about Dependabot version updates and how to configure a dependabot.yml file.

See more

The new GitHub Issues – June 2nd update

Today's Changelog brings you the release of project webhooks, a first exploration into templates and a host of improvements to GitHub Issues.

☁️🪝 Automate more with project webhooks

The first release of webhooks for projects (beta) is now available for Organizations and GitHub Apps. 🤩

Once configured and enabled, webhooks will transmit events for any action taken on project items within your organization. This includes changes made (via projects) to status, assignee, labels, and even draft issue titles and descriptions!

You can find webhooks for projects (beta) in the "Webhooks" section of your organization settings page under the title Projects v2 Items. For more information, including technical specifications, check out the docs.

🦻 We're still developing webhooks, and we'd love to hear your feedback; drop us a line in our Feedback Discussion.

🎨 Get started with templates

When you create a new project, you now have the option of multiple templates to choose from. Start with either the default table or board, or explore one we've created for you with our team backlog or feature templates.

Stay tuned for more with templates in the future. 💖

Select a starting template

🧭 Improved navigation via project header

Quickly understand which organization or user a project belongs to and easily navigate via the breadcrumbs in the project header. We've got more to do here, so please let us know what you think.
Projects Compact Header

✨ Bug fixes & improvements

Other changes include:

  • Bug fix so projects (beta) insights retain URL parameters when switching to custom date ranges.
  • REST API, GraphQL API and webhook support for closed issue reasons.
  • The emoji menu on milestone creation now loads in the correct place.
  • Users trying to upload large files now receive the correct 'file too large' error, not a 'file type not supported' error.
  • Bug fix when converting a task list item to an issue, the ` character is now correctly formatted.
  • When transferring an issue between repositories, if no search results are found there is new UI to help you understand why some repositories are excluded.
  • Using the assignee filter menu on the issues index page, you now have the option to filter by the current user instantly, without having to wait for all possible assignees to load.

See how to use GitHub for project planning with GitHub Issues, check out what's on the roadmap, and learn more in the docs.

See more

Users can view and comment on code scanning alerts on the Conversation tab in a pull request

Code scanning flags up potential security vulnerabilities in pull requests — well before code is merged and deployed. Starting today, such alerts will be more visible: they will appear as a review on the pull request Conversation tab. As with any review, developers can then have a conversation about specific areas of the code that was changed.

And of course, from the code review by the GitHub code scanning bot, you can dive deeper into the alert: view the details, check the data flow paths, and dismiss an alert.

Code scanning alert

Code scanning and branch protection rules

Users were already able to configure code scanning as a required check in the branch protection settings in a repository.

With the new code scanning functionality, developers can start a conversation about code scanning alerts. Branch protection rules that require all conversations to be resolved before a PR can be merged apply equally to conversations about code scanning alerts: as soon as a code reviewer comments on a code scanning alert, the PR can not be merged until the conversation is marked as resolved. This helps ensure comments made on alerts are addressed prior to merging.

As you'd expect, when an alert is fixed, the conversation around the alert gets resolved and the PR can be merged.

PR merge blocked because of unresolved conversation

Learn more about GitHub Advanced Security and code scanning.

See more

Users can now add a comment when dismissing code scanning alerts

Users can now add a comment when dismissing a code scanning alert.
Add a dismissal comment to a code scanning alert

It is optional to provide a dismissal comment. Dismissal comments are recorded in the alert timeline. They can also be set via the code scanning REST API when updating an alert, and retrieved through the new dismissed_comment attribute.

This feature is now available to all users on GitHub.com and will be released in GHES 3.6.

See more

Azure AD OIDC and Conditional Access support for GHEC EMUs

Enterprises that use Enterprise Managed Users (EMUs) to authenticate their accounts via Azure Active Directory can now use Azure AD location-based Conditional Access policies to protect the use of PATs and SSH keys. This requires the use of a new OpenID Connect-based application rather than a SAML integration. To learn more, read about enforcing Azure AD Conditional Access for PATs and SSH keys.

Note: this feature is currently in public beta for new and existing Azure AD EMU enterprises.

For more information:

See more

GitHub Enterprise Server 3.5 is now generally available

image

You can now download the latest version of GitHub Enterprise Server. This new release introduces GitHub Container registry and continues the strong emphasis on security. Your teams will be able to take advantage of the full complement of Dependabot capabilities and use GitHub Advanced Security with even greater language coverage and better protection for your secrets. You can read a detailed summary of new features for this release in the GitHub blog or you can take a look at all the changes in the release notes. You can check out a few of these highlights:

  • Container Registry, containers supporting OCI, granular permissions and anonymous downloads #118
  • Actions self-hosted runner group restrictions #255
  • Actions re-usable workflows are now generally available! #256
  • CodeQL detects more security issues and supports new language versions #460 Read more

New and of particular interest to administrators:

  • IP exception list for post-maintenance validation #448
  • 41 GitHub Enterprise Server Metrics for insight into platform usage #497 Read more
  • Audit Log now includes git events #322

To learn more about all the new features in GitHub Enterprise Server 3.5, read the release notes or download it today. Are you using the latest GitHub Enterprise Server version? Use the Upgrade Assistant to find the upgrade path from your current version of GitHub Enterprise Server to your desired version.

See more

Improved verification of historic Git commit signatures

GitHub will now verify Git commit signatures and show commits as "Verified" even if their public GPG signing keys are expired or revoked (but not compromised). You can also upload GPG keys that are expired or revoked to your GitHub user profile.

Using GPG or S/MIME, you can sign Git commits. These commits are marked "Verified" in GitHub's web interface, giving others confidence that they come from a trusted source because they carry their committer's signature.

GPG keys often expire or are revoked when no longer used. Previously, when a public GPG key stored in a GitHub user profile was expired or revoked, all commits that had ever been signed with that key would be shown as "Unverified" on GitHub. That raised unnecessary concern since the commits were validly signed before their key was expired or revoked. Now, when a user's GPG key expires or is revoked for a reason other than being compromised, GitHub will continue showing commits that were previously signed with that key as "Verified." You can also upload GPG keys that are expired or revoked. Besides maintaining trust in commits’ sources, this allows GPG keys to be added or rotated for greater security without losing the “Verified” status of previously signed commits.

An image of GitHub showing a commit's signature as verified even though its public GPG key is expired

For more information, visit About commit signature verification in the GitHub documentation.

We appreciate feedback on this and other topics in GitHub's public feedback discussions.

See more

Easily discover and navigate to multiple licenses in repositories

We’ve made it easier to discover multiple licenses within an open source repository. First, navigate to the **About** sidebar on the repository page to see if the repository contains any licenses. If it does, they’ll be listed underneath the README file.

sidebar-view-of-licenses

If only one license is detected, the link will take you directly to that license file. If more than one license is present, click on the list of licenses to display a dialog containing all of the licenses available at the root level of the repository. Then you can select from the dialog which license you’d like to navigate to.

dialog-of-multiple-licenses

With the use of an open source Ruby gem called Licensee, we detect license files and compare them to a short list of known licenses. Learn more about how repositories on GitHub are licensed.

Adding an open source license to your repository ensures that others can use, copy, modify and contribute back to your project. If your repository doesn’t have an open source license and you want others to get involved, you can learn more about adding one here. The dialog will match any top-level licenses with a variation of LICENSE, COPYING, OFL and PATENTS, including file extensions (i.e. LICENSE-MIT, LICENSE-GPL).

See more

Secret scanning alert events now in the audit log

The enterprise and organization level audit logs now record an event when a secret scanning alert is created, closed, or reopened. This data helps GitHub Advanced Security customers understand actions taken on their secret scanning alerts for security and compliance audits.

See more

GitHub Actions: Re-run jobs with debug logging

You can now enable debug logging when you re-run jobs in a GitHub Actions workflow run. This gives you additional information about the job's execution and its environment which can help you diagnose failures.

To enable debug logging, select "Enable debug logging" in the re-run dialog.

Re-run dialog screenshot

You can also enable debug logging using the API or the command-line client.

For more details see
Re-running workflows and jobs.

For questions, visit the GitHub Actions community.

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

See more

Actions can now run in a Node.js 16 runtime

Actions authors can now specify that their action can run in Node.js 16 by specifying runs.using as node16 in the action's action.yml. This is in addition to the existing Node.js 12 support; actions can continue to specify runs.using: node12 to use the Node.js 12 runtime.

Runners supporting Node.js 16 actions are available on all GitHub-hosted runners and in GitHub Enterprise Server 3.4 and newer. GitHub Enterprise Server 3.3 and newer can manually install a newer runner to add support for Node.js 16 based actions.

As a result, actions authors who move from targeting Node.js 12 to Node.js 16 should release with a new major version number to communicate that there is a possible breaking change for GitHub Enterprise Server 3.3 and earlier.

See more

Updates to Markdown pasting on GitHub

We've made some updates to how paste formatting works in Markdown-enabled fields on GitHub. For example, in code editors and on gists, you'll now be able to paste URLs on selected texts that will render as Markdown links like [...](https://...) by using the keyboard shortcut cmd|ctrl + v.

The following paste formatting changes have been made to pull requests, issue comments and wikis:

  • Spreadsheet cells and HTML tables will render as Markdown tables
  • Any copied text containing links will render the links in Markdown

All of this formatting can be disabled when pasting using the keyboard shortcut: cmd|ctl + shift + v or cmd|ctl + shift + Alt + v.

markdown formatting demo gif

Learn more about writing and formatting at GitHub.

See more
View more changes