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

Incremental improvements to the security coverage enablement slide-out panel

We've recently released a few improvements to the slide-out enablement panel on the security coverage page in security overview:

  • Active committers for the repository are now visible, providing insight into the number of Advanced Security licenses being utilized. For repositories where Advanced Security is not enabled, the number indicates the number of licenses required to enable the feature.
  • Unsaved changes are now clearly labeled with a "Modified" tag. Additionally, the "Save security settings" button now displays the total number of enablement changes being made.
  • While a security feature is being enabled, the coverage page will show a status of "Updating…" to keep you informed of the ongoing process.

    Security coverage slide-out panel

These improvements have shipped to GitHub.com and will be available in GitHub Enterprise Server 3.9.

Learn more security overview and send us your feedback

Learn more about GitHub Advanced Security

See more

Organization APIs for fine-grained PATs management

Organization owners can now automate the approval and auditing of fine-grained personal access tokens (PATs) in their organization using a GitHub app. New APIs and webhook events allow a GitHub app to be notified of new PAT requests in an organization, review the request, and then approve or deny the PAT. They also provide a view of all approved fine-grained PATs for an organization, with the ability to revoke their authorization as well. These APIs and events are part of the ongoing fine-grained PAT public beta that launched last year.

Mermaid diagram indicating how a request from a user triggers a webhook event to an app, who can then review the request and choose to approve it. Later, the application can review all approved PATs, and choose to revoke one, resulting in an email notification to the user who created the PAT.

Details included in the webhook event and API listings include the repositories and permissions requested, the expiration time of the token, and the user's explanation for what they plan to do with the PAT. The personal_access_token_request events are generated when a request is created, approved or denied by an administrator or application, or cancelled by the requesting user.

Only a GitHub app is able to call these APIs, either acting on its own or on behalf of a signed-in organization administrator.
The organization_personal_access_tokens permission is needed to manage the active tokens, while the organization_personal_access_token_requests permission enables the app to recieve webhooks about requests and call the request management APIs.

Organizations must have the personal access token approval flow enabled in order to manage these requests, otherwise fine-grained personal access tokens are automatically approved for the organization (which generates a personal_access_token_request: approved event).

To learn more about these APIs, see "List requests to access organization resources with fine-grained PATs" and the "personal_access_token_request webhook event". To learn more about fine-grained PATs, and how to enable them for your organization, see "Setting a personal access token policy for your organization".

If you have feedback or bugs to report about fine-grained PATs, please let us know in the dedicated feedback discussion.

See more

GitHub Actions: The setup-go Action now enables caching by default

Enabling caching by default has demonstrated improved workflow performance, and can reduce build times by 20-40% for repositories with dependencies greater than 100 MB! This change has been made to the latest setup-go Action(V4). Developers no longer have to specify the cache: true parameter in their YAML file to obtain the benefits of caching. For more information on building, testing, and caching dependencies with Go, check out the docs here!

See more

GitHub Actions: SBOMs are now attached to hosted runner image releases for macOS

In addition to Ubuntu & Windows, GitHub Actions now attaches a SBOM (Software Bill of Materials) to hosted runner image releases for macOS. In the context of GitHub Actions hosted runners, an SBOM details the software pre-installed on the virtual machine that is running your Actions workflows. This is useful in the situation where there is a vulnerability detected, you will be able to quickly tell if you are affected or not. If you are building artifacts, you can include this SBOM in your bill of materials for a comprehensive list of everything that went into creating your software.

To check out the new files, head over to the runner-images repository release page now or check out our docs for more information.

See more

Introducing the GitHub Classroom CLI extension for the GitHub CLI

We're thrilled to introduce the GitHub Classroom CLI extension for the GitHub CLI, designed to simplify the lives of teachers everywhere. With this powerful new tooling, teachers can create their own personalized workflows, as well as streamline any custom solutions they've already built.

To get started, ensure you have the GitHub CLI installed, then install the extension with the following command:
gh extension install github/gh-classroom

Command your Classroom

The GitHub Classroom CLI extension provides a suite of commands to help you navigate your classrooms and assignments with ease. Here's a quick overview of its capabilities:

  • gh classroom list: List all your unarchived classrooms
  • gh classroom view: Show the details of a classroom, such as its name, description, URL, and roster
  • gh classroom assignments: Display a list of assignments for a classroom
  • gh classroom assignment: Show the details of an assignment, such as its title, type, deadline, starter code URL, and number of submissions
  • gh classroom accepted-assignments: List your students' accepted assignments
  • gh classroom clone starter-repo: Clone the starter code for an assignment
  • gh classroom clone student-repos: Clone all your students' submissions for an assignment (a scriptable alternative to the Classroom Assistant desktop application)

To target a specific classroom, use the -c flag with each subcommand (retrieve a classroom's ID through selecting it in gh classroom ls or gh classroom view). In the absence of the -c flag, an interactive picker navigable with arrow keys will help you select the target classroom.

This collections of subcommands marks the beginning of our journey to deliver power features that save you time and enhance your workflows.

You can report issues or request features on our public repository, where we look forward to open sourcing the code in the coming weeks.

Share what you build with the GitHub Classroom CLI in our Global Campus for Teachers Discussions forum!

See more

Fixed bug that allowed private issues and pull request titles to be shown in search results

GitHub Security was notified about an issue where private issue and pull request titles would be displayed in search results. Our Security team investigated potential instances and determined that this only occurred when the author of the commit was authorized to view the issue or pull request and the commit was titled as a link to the private issue or pull request. Additionally, this only happened while using the new code search (beta). This issue was introduced when the new code search (beta) launched and was fixed on January 17, 2023. As this issue has been addressed, there is no further action that is required by any user.

See more

Roadmaps in Projects are now generally available

Today we are announcing the general availability (GA) of roadmaps in GitHub Projects! 🎉

🗺 Roadmaps for all

Since we announced the public beta of roadmaps earlier this year, we've shipped exciting updates that allow you to quickly adjust your roadmaps and visualize and track work with important milestones and dates, alongside lots of bug fixes and improvements. Thank you to everyone who participated in the beta for all of the feedback! 💖

To get started with a roadmap, select the roadmap layout when creating a new project, or create a new roadmap in an existing project by selecting "Roadmap" in the view options menu.

📍 Track important dates with roadmap markers

If you are using milestones to track progress for larger bodies of work, iteration fields to plan out your weeks and months, or date fields for important deadlines, roadmap markers help you and your team keep track of important upcoming dates. Configure these from the Markers menu to make sure all of your important dates are visible on your roadmap.
Roadmap with markers

⚡ Quickly adjust roadmap items

Plans often change, and so can your roadmaps! Quickly make edits to your roadmap items by dragging and dropping them to a different date or iteration, or moving them to another status or team.

✨ Other enhancements

  • Create a roadmap from the Select a template dialog when creating a new project
  • Edit item titles directly from the table
  • Use arrow keys for navigating table items
  • Use the floating + Add items bar when there is no 'Group' field selected
  • Resize the table using keyboard navigation

✍ Tell us what you think!

We want to hear from you! Be sure to drop a note in the discussion and let us know how we can improve. Check out the documentation for more details.

✨ Bug fixes and improvements

  • Enabled vertical scrolling in the Workflows page
  • Fixed a bug where the New column menu was appearing again when adding a new board column
  • Fixed a bug where the Add selected items button was out of view in the bulk-add pane
  • Updated the github-project-automation link in the issue timeline to redirect to Automating your project documentation
  • Moved reactions on issues and pull requests to the bottom left of the comment box, making it easier to respond after reading and creating consistency with discussions
  • (Tasklists Private Beta) "Convert to Issue" is now more discoverable on the tasklist item versus in the three-dot menu
  • (Tasklists Private Beta) Fixed a bug where some repository names were getting cut off

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

Block ambiguous branch and tag names

GitHub blocks branch and tag names which begin with refs/.

Under the hood, all Git refs begin with a prefix (refs/heads/ for branches and refs/tags/ for tags). In typical use, though, users rarely see these prefixes, so they're silently handled by GitHub, the Git client, and other tools. When a similar string is used as the beginning of the visible part of the branch or tag name, this results in ambiguity: did the user intend refs/heads/feature or refs/heads/refs/heads/feature? In nearly all cases, refs/ in front of a branch or tag name is accidental and becomes a problematic surprise later.

This change blocks new introductions of such names. Repositories with existing branches named this way can still push updates to those branches.

See more

Code scanning API to enable default setup with CodeQL on a repository

Code scanning have shipped an API for repositories to programmatically enable code scanning default setup with CodeQL.

The API can be used to:

  • Onboard a repository to default setup: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f state=configured
  • Specify which CodeQL query suite to use in the default setup configuration: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f query_suite=extended
  • View the current default setup configuration for a repository: gh api /repos/[org]/[repo-name]/code-scanning/default-setup
  • Offboard a repository from default setup: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f state=configured

When you onboard a repository via the API, you will recieve a workflow run ID which can be used to monitor the setup progress. This can be used to see the status and conclusion of the run: gh api repos/[org-name]/[repo-name]/actions/runs/[run-id] --jq '.status, .conclusion'

{
  "state": "configured",
  "languages": ["javascript", "ruby"],
  "query_suite": "default", 
  "updated_at": "2023-02-24T20:00:42Z"
}

For more information, see "Get the code scanning default setup configuration" and "Update the code scanning default setup configuration".

See more

General availability of granular access token on npm

Today we are making the granular access token feature on npm generally available.

Granular access token, allows you to:

  • Restrict token access to specific packages and/or scopes
  • Grant tokens access to specific organizations for org and user management
  • Set a token expiration date
  • Limit token access based on IP address ranges
  • Select between read and/or write access for the token

We recommend using granular access tokens with least privileges for automating your publishing and org management activities. You can allow your package to be published without 2FA using granular access tokens from your trusted CI/CD systems. Additionally, you can also configure your package to require 2FA when publishing from a local machine to defend against account hijacking.

Read more about creating a granular access token here.

See more

You can now use the “security extended” query suite in code scanning default setup with CodeQL

You can now enable the "security extended" query suite for repositories using code scanning default setup with CodeQL. This query suite can be selected during set up, or changed at any time by viewing and editing the CodeQL configuration.

Code scanning's default query suites have been carefully designed to ensure that they look for the security issues most relevant to developers, whilst also minimizing the occurrence of false positive results. However, if you and you developers are interested in seeing a wider range of alerts you can enable the security extended query suite. This suite includes the same queries as in the default query suite, plus:

  • extra queries with slightly lower severity and precision.
  • extra experimental queries.

If you enable the security extended suite you may see more CodeQL alerts in your repository and on pull requests. For more information, see "About code scanning alerts".

Code scanning default setup query suites

Code scanning default setup view configuration

Read more about code scanning default setup.

See more

Enable code scanning default setup with CodeQL at the organization level (public beta)

Enabling CodeQL analysis with code scanning default setup for eligible repositories in your organization is now as easy as a single click from the organization's settings page or a single API call.

Code scanning enable all default setup button on the organization's 'Settings' page

You can use code scanning default setup to enable CodeQL analysis for pull requests and pushes on eligible repositories without committing any workflow files. Currently, this feature is only available for repositories that use GitHub Actions and it supports analysis of JavaScript/TypeScript, Python and Ruby. We plan to add support for additional languages soon.

To help you identify which repositories are eligible for the "enable all" feature, two new security coverage filters have been added:

  • code-scanning-default-setup: returns a list of enabled, eligible or not eligible repositories
  • advanced-security: returns a list of repositories with GitHub Advanced Security enabled or not enabled

This feature has been released as a public beta on GitHub.com and will also be available as a public beta on GitHub Enterprise Server 3.9.

Learn more about configuring code scanning at scale using CodeQL and the "Enable or disable a security feature for an organization" REST API

Learn more about GitHub Advanced Security

See more

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
View more changes