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

Secret scanning changes to how you opt in to notifications

We announced two weeks ago that we are changing how you receive notifications for secret scanning alerts. From today, those changes are in effect.

What action should I take?

If you are a repository administrator, organization owner, security manager, or user with read access to secret scanning alerts:

  • Watch your repositories of interest by choosing "All activity" or "Security alerts." This helps you choose what events GitHub will notify you about.
  • In your user notification settings, you must choose "Email" in the "Watching" section. This tells GitHub how to notify you. Secret scanning only supports email notifications at this time.

If you're a commit author:

As long as you are not ignoring the repository in your watch settings, commit authors always receive notifications for new secrets that are leaked. This means you receive a notification for any secret committed after an initial historical scan has run on the repository.

Learn more

See more

Code scanning shows more accurate and relevant alerts on pull requests

Code scanning is now using a new way of analysing and displaying alerts on pull requests. The change ensures code scanning only shows accurate and relevant alerts for the pull request.

Previously, code scanning presented all alerts unique to the pull request branch, even if they were unrelated to the code changes the pull request introduced. Now, the tool reports only alerts inside the lines of code that the pull request has changed, which makes it easier to fix these contextualised alerts in a timely manner.

code scanning on the slide-out enablement panel on the security coverage page

The complete list of code scanning alerts on the pull request branch can be seen on the Security tab of the repository.

code scanning on the slide-out enablement panel on the security coverage page

In addition, code scanning will no longer show fixed alerts on pull requests. Instead, you can check whether an alert has been fixed by your pull request on the Security tab of the repository by using search filters: pr:111 tool:CodeQL. If you fix an alert in the initial commit in the pull request, it will not be present on the PR branch.

This has shipped to GitHub.com and will be available in GitHub Enterprise Server 3.10.

Learn more about viewing an alert on your pull request.

Learn more about GitHub Advanced Security.

See more

SSH Certificate requirement update

The "Require SSH certificates" policy now allows GitHub apps to call Git APIs using a user-to-server token, bringing them up to parity with OAuth app support.

The SSH certificate requirement mandates that users in your organization call Git APIs using an SSH certificate issued by your organization, in place of their own SSH key or a PAT.
To support automation, it has an exception in place for OAuth apps and GitHub app server-to-server tokens, which allows applications you've approved to call Git APIs for your organization.
With this change, we are extending that exception to GitHub app user-to-server tokens, for when a user has signed into a GitHub app that's installed in your organization.

Screenshot of the SSH Certificate requirement checkbox

This change also applies when the enterprise-level setting requires SSH certificates across all organizations in the enterprise.

To learn more, see "Managing your organization's SSH certificate authorities" or "Managing SSH certificate authorities for your enterprise".

See more

Fixed bug that allowed removed users to retain access to the organization

GitHub Security was notified about an issue where users still had access to organizations after being removed. Our Security team investigated potential instances and determined there were occasional instances where users’ permissions were not fully removed when teams were deleted or they were part of a team when they were removed from the organization. While we investigated the root causes, which stemmed from background job and permissions issues, a manual fix has been implemented since October 20, 2022. We have addressed the underlying issues and the need for the previously implemented manual fix. We have also cleaned up any users that were not removed when they should have been. There is no further action that is required by any organization.

See more

Introducing the GitHub Markdown Helpers Public Beta

GitHub users write a lot of Markdown; so much so that we render 2 billion Markdown files everyday; at peak times, we're processing 1,300 Markdown files a second! Any opportunity we have to shave a few seconds off of the Markdown authoring experience on GitHub is time well-spent.

Introducing Markdown Helpers powered by Slash Commands

To use Markdown Helpers, simply type / on Issues, Pull Requests, or Discussion descriptions/comments and use the subsequent dialog to choose from a number of useful Markdown shortcuts.

Use shortcuts like /table to make Markdown tables a breeze, or /details to make selectively showing content to readers much easier than remembering the HTML formatting.

As part of our first release, we've included 6 out-of-the-box features which we hope will help teams author Markdown faster and with less context switching:

  • Code Block
    • Support for language-specific syntax highlighting
  • Details
    • Specify details that the reader can open and close on demand
  • Saved Replies
  • Table
    • Easily insert Markdown Tables
  • Templates
    • Easily populate your Repository's Issue or Pull Request templates directly from Slash Commands!
  • Tasklist
    • Easily insert a Tasklist
    • Note: Tasklists are currently in Private Beta, only users in organizations added to the Private Beta will see this option)

We'd love to hear from you!

Be sure to check out the official Slash Commands documentation for more details on the commands we're releasing today.

Anything we missed? Got an idea for a great Slash Commands feature?

Please leave us some feedback in our Feedback Discussion about how you'd like to use Slash Commands on GitHub.

See more

Adding the ability to close GitHub Discussions

GitHub Discussions now supports the ability to close a Discussion. Discussions can be closed for one of three reasons: Resolved, Outdated, or Duplicate. Closing a Discussion is much like closing an Issue or a Pull Request. Users can select a reason for closing in the dropdown. A screenshot of the dropdown is shown below:

Dropdown showing Close Discussion options

The reason for closing is visible to users in two places on the page.

First, in the icon at the top of the Discussion:

Icon at the top of Discussions showing that it is closed

Second, on the events timeline:

The event timeline showing a Discussion being closed

Besides the state of the Discussion being visible on the page, we're also now surfacing the state of a Discussion in search. We're adding three new filters:

is:<closed/opened>
filters out open/closed discussions

reason:<resolved/outdated/duplicate>
returns closed discussions that were closed with the provided reason

closed:<date>
returns discussions closed on a certain date. Supports < and > operators to get discussions closed before or after the date.

See more

Comment on files in a pull request (public beta)

Commenting directly on a file in a pull request (not just a specific line) is now available in public beta! 🎉

With this capability you can now comment on deleted, binary (including images), and renamed files in a pull request. You can also comment generally about a changed code file without having to attach the comment to a specific line.

How it works

To comment on any file in a pull request, click the Comment on this file button in the header of the file (next to the Viewed checkbox):
image

Comments on files appear in the Files Changed and Conversation tabs and can be replied to and resolved like regular review comments.
image

Tell us what you think

This feature is currently in public beta, with GitHub Mobile and API support coming soon.

Join the discussion and let us know what you think!

See more

Projects on GitHub Mobile is now generally available

Projects on GitHub Mobile

Projects on GitHub Mobile are now available for iOS and Android! Find the projects you're working on through a repository, organization, or from your user profile. You can also easily change views in a project to browse your issues and pull requests grouped and organized just as you like.

Custom fields and metadata, such as status, category, priority, and iteration, are displayed as an easy-to-read list within a project item. Simply tap on the list to edit the fields, or long-press on a project item for further actions like closing it or previewing its content.

Update your GitHub Mobile apps today from the Android Google Play or iOS App Store.

Read more about GitHub Mobile and send us your feedback to help us improve.

See more

Organization Audit Logs include IP addresses – Public Beta

GitHub organization owners can now opt-in to a public beta to display organization members' IP addresseses in audit logs events. When enabled, IP addresses will be displayed for all audit log events performed by organization members on organization assets other than public repositories, which will be treated differently due to privacy obligations.

The inclusion of IP addresses in audit logs helps software developers and administrators protect their systems and data from potential threats and improve their overall security posture by providing the source of an action or event within a system or network. This information is crucial for troubleshooting issues or investigating security incidents. IP addresses are often used in forensic investigations to trace the origin of cyberattacks, unauthorized access, or other malicious activities.

For additional information and instructions for enabling this feature, read about displaying IP addresses in the audit log for your organization.

See more

Changes to the code search API

We are preparing to bring powerful new code search capabilities to GitHub. As part of that effort, on April 10, 2023, we will make several changes to the code search API:

  • Code search rate limits will be separated from the rate limits for other search types. The separate code search category will have a rate limit of 10 requests per minute.
  • We are deprecating support for sorting code search results. Once these changes take effect, all code search results will be sorted by best match.
  • All code search API endpoints will require authentication. This change only affects repository scoped queries, because all other query types already require authentication.

To prepare for these changes, make sure your code handles rate limiting. And if you’re using code search to track changes or find security vulnerabilities in your codebase, consider using webhooks or GitHub Advanced Security.

These changes will take effect in 30 days, on April 10, 2023.

See more

Delete stale code scanning configurations to close outdated alerts

Code scanning configurations can now be deleted from the code scanning alert page. This could be used to delete stale configurations causing alerts to remain open, or delete old configurations which are no longer used.

Code scanning can be configured to use different tools, target different languages, or even analyze different parts of the codebase in the same repository. In certain circumstances more than one of these configurations may produce the same alert. However, if one of the configurations is no longer used and becomes 'stale' you may find that the alert is fixed in one configuration but not in the stale configuration, which is potentially confusing. Today we are releasing a new feature that allows you to easily delete stale configurations which cause alerts to remain open after they've been fixed.

In the code scanning alert page, the counter in the 'Affected branches' sidebar shows the number of configurations for the branch. Click a branch to view the configuration details, and delete configurations as required. A configuration is deleted for a branch, so may have an impact on the status of other alerts on the same branch. When a configuration is deleted, a timeline entry is recorded on the alert, and repositories in an organization also record an audit log entry. If a configuration is deleted by mistake, re-run the analysis to update the alert and reinstate the configuration.

Delete code scanning configurations

Read more about removing stale code scanning configurations and alerts.

See more

GitHub Actions – Required workflows improvements

Today, we are adding a couple of new improvements to required workflows in GitHub Actions.

  • Blocking direct push: Direct pushes are now blocked on branches of the repositories where required workflows are enforced. To push to a branch where required workflows are enforced at the organizational level, create a pull request to make the necessary changes. If you want to allow direct pushes for a particular repository, you must remove the repository as a target from respective required workflows.

    Block direct push PR

    Block direct push CI

  • Ability to configure required workflows from refs: Required workflows can now be referenced using any branch, tag, or commit SHA from the repository containing the workflow file, during its configuration. This helps you to freeze your required workflow file to a fully validated golden version and gives you the flexibility to move to latest version after testing it thoroughly. The branch, tag, or commit can be specified in the workflow path text field similar to how it is specified for actions within a workflow yaml.

    Required workflows ref

Link to Documentation

Note: Required workflows is currently in beta.

See more

GitHub Issues & Projects – March 9th update

Today's Changelog brings you auto-add and auto-archive workflows for all users to make managing your project a breeze, and tasklists improvements!

🤖 Automatically add and archive project items

We previously announced the public beta of the auto-archive workflow and the auto-add workflow for Enterprise users, and today we are excited to share these are now available to everyone!

From the Workflows page in your project, configure the filter criteria for when you want to automatically archive items from your project via Auto-archive items, as well as automatically adding items from a repository to your project via Auto-add to project.

Note Multi-repository auto-add workflows are only available to Team and Enterprise users

✅ Tasklist improvements

As part of our ongoing Private Beta for Tasklists, we continue to ship weekly improvements! We're letting in new organizations regularly, sign yours up here.

🟣 See completion pills for issues

Issues in your tasklist now have completion pills which indicate whether or not they have children, making it easier to understand how close your tasklist is to completion.

✏️ Edit issue metadata directly from the tasklist

Quickly make edits to assignees, labels and projects straight from a tasklist.

🐞 Tasklist bug fixes and improvements

  • Fixed a bug where labels and assignee meta-data took a very long time to be reflected on tasklists
  • Better support for issue deletion and transfer of issues within tasklists
  • Fixed a visual bug with tasklist drag-and-drop
  • Fixed a bug where long task titles broke tasklists
  • Fixed a bug where empty tasks broke tasklists

✨ Bug fixes and improvements

  • Fixed misaligned field pills on board items
  • Fixed misaligned board columns when grouped by an iteration field
  • Fixed a bug where closed projects were included in the project count

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

Use multi-repository variant analysis (beta) to run CodeQL queries at scale

Today we have released multi-repository variant analysis for CodeQL in public beta to help the OSS security community power up their research with CodeQL.

CodeQL is the static code analysis engine that powers GitHub code scanning. Out of the box, CodeQL is able to find many different types of security vulnerability and flag them up in pull requests.

But one of CodeQL’s superpowers is its versatility and customizability: you can use it to find virtually any pattern in source code. As such, it’s a great tool for finding new types of vulnerabilities – once you’ve identified an interesting pattern, model it as a CodeQL query, and then run it against your repository to find all occurrences of that pattern! But most vulnerabilities are relevant to many codebases. Wouldn’t it be amazing if you could easily run your query against many repos at the same time? Well, now you can with multi-repository variant analysis — which we’ve just shipped in public beta!

Screenshot 2023-02-22 at 16 39 39

This new feature will allow security researchers to run CodeQL analyses against large numbers of repos, straight from the CodeQL extension for VS Code, making it possible to identify new types of security vulnerabilities in the most popular open-source codebases.

Checkout the CodeQL for VS Code documentation to get learn how to get started with multi-repository variant analysis. We'd also love to hear your feedback on this GitHub community discussion.

See more

Increased concurrency for 2-core Linux & Windows Hosted Actions runners for Enterprise Plans

Starting on March 08, 2023, GitHub Enterprise customers using 2-core GitHub-hosted Linux and Windows runners will have the job concurrency on Windows/Linux increased from 180 to 500.

Enterprise customers need to make no changes to take advantage of this increased concurrency. If you require higher concurrency on 2-Core GitHub-hosted Linux and Windows runners than 500, please reach out to GitHub support.

See more
View more changes