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

This week, we’ve shipped a new experience for creating issues directly from Projects, improved sorting by custom fields across all layouts, and fixed a few bugs.

📝 Create issues in a snap with the new issue creation dialog

Create new issues quickly and easily by clicking the + icon on the omnibar and selecting Create new issue. Add labels, select a milestone, and assign to a teammate without ever leaving your project.

🗂 Sorting by field values on the board layout

Sort by field values on the board layout to easily organize your work items within your board columns. Select a sorting field from the view configuration menu to reorder items within each column, and move your items freely between columns while still maintaining the sorted order.

✅ Tasklists (Private Beta) improvements & bug fixes

Tasklists is currently in Private Beta but we’re letting folks in as fast as we can, join the waitlist!

We’ve recently shipped a major refactor to tasklists, so bear with us and help us by reporting problems you run into!

🐛Tasklists bug fixes

  • Fixed a bug where transferring Issues broke tasklists
  • Stopped inserting superfluous newlines around tasklists
  • Stopped showing duplicate labels on tasklists

✨ Tasklists enhancements

  • Edit history now reflects the changes made to the tasklists in Markdown
  • Tasklists preserve inserted Markdown instead of callously disposing of all “non-tasks”
    Support for bold, italicize, ~~strike text out~~, link and code formatting
  • Ability to @ mention people in tasks
See more

Organization admins and security managers can now enable private vulnerability reporting for all public repositories within an organization at once.

With this enhancement, you no longer have to enable the feature for each repository individually.

Find this option under your organization's "Settings" tab under "Code security and analysis".

Private vulnerability reporting

See more

Starting today, when linking to a Dependabot alert in an issue and or pull requests, anyone with permissions to view the alert will see a rich Dependabot alert mention, with detailed hovercard and a prettified link with the title of the alert.

Card details include:

  • Alert title, repository, and description
  • Date that the alert was opened
  • Alert severity and status (fixed, dismissed, or open).

Dependabot alerts - prettified links and hovercard example

Learn more about Dependabot alerts

See more

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Twilio Segment to scan for their tokens and help secure our mutual users on all public repositories, and private repositories with GitHub Advanced Security. Twilio Segment tokens allow users to programmatically manage their workspaces. GitHub will forward access tokens found in public repositories to Twilio Segment, who will immediately revoke the token and notify workspace owners. You can learn more about Twilio Segment tokens here.

GitHub Advanced Security customers can also block Twilio Segment tokens from entering their private and public repositories with push protection.

Learn more about secret scanning
Partner with GitHub on secret scanning

See more

gif of adding note to blocked user

You can now add a note to describe why the blocking of a user took place, to provide projects and teams with the context around privacy and safety decisions. Notes on blocked users at the organization level will be visible to the owners and moderators of that organization. Notes on blocked users from your personal account will be visible just to you.

See more

Secret scanning users can now view the validity of detected GitHub tokens by clicking into the related alert's UI page. The alert page will tell you whether the GitHub token is still active and able to be used.

Secret scanning alerts are available for free on public repositories and as part of GitHub Advanced Security on private repositories.

See more

GitHub and the Rust Foundation are collaborating to help protect you from leaked crates.io keys.

From today, GitHub will scan every commit to a public repository for exposed crates.io keys. We will forward any tokens we find to crates.io, who will automatically disable the tokens and notify their owners. The end-to-end process takes only a few seconds.

Crates.io is the latest GitHub secret scanning integrator; since 2018, GitHub has partnered with over 100 token issuers to help keep our mutual customers safe. We continue to welcome new partners for public repository secret scanning. In addition, GitHub Advanced Security customers can scan their private repositories for leaked secrets.

We'd like to thank Joel Mercey for his work on crates.io that made our collaboration with Rust possible.

Learn more about secret scanning
Partner with GitHub on secret scanning

See more

We're back again with the ability to make a copy of your project and a new automation for Enterprise accounts.

🖨️ Get started faster by copying your project’s views, custom fields and draft issues

Whether you’ve spotted a project that seems to have everything you want for your next endeavor or your team has an optimized project you want to use on repeat, ‘Make a copy’ is here to help. Quickly copy the views, custom fields and draft issues of any existing project over to a new one. We’d love your feedback; drop us a line in our discussion.

🤖 Automatically add project items (Enterprise accounts only)

Let the robots take care of adding your relevant issues and PRs to your project! Configure the auto-add workflow to automatically add new items as they are created or updated in a repository and filter to just the items you want with is, label, assignee, and reason support.

At this time, auto-add will not bulk-add items that match the filter when the workflow is enabled and is only available for Enterprise accounts. We'd love to hear your feedback as you try it out!

✨ Bug fixes and improvement

  • Enabled sorting in board view
  • Stopped resetting the omnibar when focus is lost
  • Updated the + button to add a column in board view

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

Organizations and enterprises using branch protections may see false-alert flags in their security log for protected_branch.policy_override and protected_branch.rejected_ref_update events between January 6 and January 11, 2023.
These events were improperly emitted due to a change in the underlying logic that checks if branch protection criteria have been met.

No action is required from impacted users with regards to these events. GitHub has a policy to not delete security log events, even ones generated in error. For this reason, we are adding flags to signal that these events are false-alerts.

an audit log entry with the flash message displayed above it

See more

In the spirit of continuing to improve our invitation experience, we are bringing a few more enhancements to the UI and APIs to better support invitation management experiences. From today onward, the following will apply:

  • Enterprise owners can view all failed user invitations across their enterprise;
  • Enterprise and Organization owners can take bulk actions on their corresponding "People" pages in order to delete or retry failed invitations;
  • Outside collaborators will now be reflected within the failed invitation pages;
  • Enterprise owners can add multiple existing enterprise members to organizations via the UI at https://github.com/enterprises/<enterprise>/people; and
  • Invitation pages within organization and enterprise "People" pages will display invitation source information.

To learn more, read about inviting users in an organization.

See more

On March 30, 2022, we released CodeQL Action v2, which runs on the Node.js 16 runtime. In April 2022, we announced that CodeQL Action v1 would be deprecated at the same time as GitHub Enterprise Server (GHES) 3.3.
This deprecation period has elapsed and starting January 18, 2023, CodeQL Action v1 is now discontinued.
It will no longer be updated or supported, and while we will not be deleting it except in the case of a security vulnerability, workflows using it may eventually break.
New CodeQL analysis capabilities will only be available to users of v2.

For more information about this deprecation, please see the original deprecation announcement from April 2022.

How does this affect me?

If you use code scanning with CodeQL on any of the following platforms, you should update your workflow file(s) to use CodeQL Action v2 as soon as possible:

  • GitHub.com (including open source repositories, users of GitHub Teams and GitHub Enterprise Cloud)
  • GHES 3.4.13 and later

Users of GHES 3.4.12 or earlier: please read this section in the original deprecation announcement.

What do I need to change in my workflow?

To upgrade to the CodeQL Action v2, open your CodeQL workflow file(s) in the .github/workflows directory of your repository and look for references to:

  • github/codeql-action/init@v1
  • github/codeql-action/autobuild@v1
  • github/codeql-action/analyze@v1
  • github/codeql-action/upload-sarif@v1

These entries need to be replaced with their v2 equivalents:

  • github/codeql-action/init@v2
  • github/codeql-action/autobuild@v2
  • github/codeql-action/analyze@v2
  • github/codeql-action/upload-sarif@v2

If you use a pinned version of the CodeQL Action in your workflows, for example github/codeql-action/init@32be38e, check the latest Actions workflow run summary on your repository.
If you see a warning stating that you are running CodeQL Action v1, then please update your workflow to reference v2 or alternatively the latest github/codeql-action commit tagged v2.

Can I use Dependabot to help me with this upgrade?

All users on GitHub.com, and GHES customers using GitHub Advanced Security with a local copy of github/codeql-action, can use Dependabot to automatically upgrade their Actions dependencies.
For more details on how to set this up, please see this page.

GHES customers should also make sure:

See more

In security overview, when you select a team from the Team dropdown or filter by team in either the security risk or the security coverage views, results include repositories where the team has write privileges. Previously, results only included repositories where the team had admin privileges or had been granted access to security alerts.

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

Learn more about the team filter and send us your feedback

Learn more about GitHub Advanced Security

See more

Today’s Changelog brings you the addition of project events to Issue and Pull Request timelines, Issue forms for private repositories, and more!

👀 Project events in item timelines (Public Beta)

Actions related to adding and deleting Issues or Pull Requests from a project or changing the status of an Issue or Pull Request inside a project are now included as part of the items timeline alongside existing events.
image

📝 Issue forms for private repositories (Public Beta)

Previously we released Issue forms for public repositories, helping maintainers provide more context on the information useful to them.

Today we are releasing Issue forms for private repositories. Issue forms for private repositories use the same YAML syntax as public repositories but do not support required fields, helping to keep your issue creation process streamlined.
image

✨ Bug fixes and improvements

  • Added a note that closing a project will disable all associated workflows
  • Added a tooltip text over the unsaved view indicator
  • Accessibility improvements in the project settings pages

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

What's new?

Starting today, Dependabot will pause automated pull request activity if you haven't merged, closed, or otherwise interacted with Dependabot for over 90 days. To resume activity when you're ready, simply interact with Dependabot.

This change will help Dependabot be more focused to the repositories you care about.

When will Dependabot become paused?

This change only applies to repositories where Dependabot pull requests exist but remain untouched. If no Dependabot pull requests have been opened, Dependabot will never become paused.

The following must be true for at least 90 days:

  • Has not had a Dependabot PR merged
  • Has not had changes made to the Dependabot config file
  • Has not had any @dependabot comment-ops performed
  • Has not had any Dependabot PRs closed by the user
  • Has received at least one Dependabot PR before the 90 day window
  • Has at least one Dependabot PR open at the end of the 90 day window
  • Has had Dependabot enabled for this entire period

How will Dependabot let me know?

Dependabot will add a notice to the body of all open Dependabot pull requests and add a dependabot-paused label to them. Dependabot will also add a banner notice in the UI of your repository settings page (under “Dependabot”) as well as your Dependabot alerts page (if Dependabot security updates are affected).

Who can use this feature?

This change does not apply to Dependabot alerts or subsequent notifications. So, only repositories that have automated Dependabot version updates or security updates, but haven't interacted with these pull requests for a while, will be affected.

This change will start to roll out today, expanding through January 2023 to include all repositories owned by individuals and by organizations with free and Team plans.

Later, it will roll out to GitHub Enterprise Cloud and GitHub Enterprise Server customers, where this improvement has the added benefit of enhanced efficiency with your self-hosted GitHub Actions runners.

Learn more about this change.

See more

GitHub.com users who set up two-factor authentication will see a prompt after 28 days, asking them to perform 2FA and confirm their second factor settings. This prompt helps avoid account lockout due to misconfigured authenticator applications (TOTP apps), especially those that failed to save the TOTP secret after validating it during set up.

This prompt appears in existing sessions if you haven't already performed 2FA as part of a sudo prompt or signing in on another device. If you find that you can't perform 2FA, you'll be presented with a shortcut that allows you to reset your 2FA setup.

image

All users that enable 2FA will be eligible for this prompt, including users required to enable it by their organization or GitHub itself.

To learn more about two-factor authentication, see "Configuring two-factor authentication".

See more

OpenID Connect (OIDC) support in GitHub Actions enables secure cloud deployments using short-lived tokens that are automatically rotated for each deployment.
Each OIDC token includes standard claims like the audience, issuer, subject and many more custom claims that uniquely define the workflow job that generated the token. These claims can be used to define fine grained trust policies to control the access to specific cloud roles and resources.

  • We now support more custom claims within the token : actor_id, repository_id, repository_owner_id
    workflow_ref, workflow_sha and job_workflow_sha – to help uniquely verify the source of a workflow job, even if the job references a reusable workflow.
  • We are also adding these new attributes as default environment variables and also to github context

These changes enable developers to define more advanced access policies using OpenID connect and do more secure cloud deployments at scale with GitHub Actions.

Learn more about Security hardening your GitHub Workflows using OpenID Connect.

See more

The GitHub Packages RubyGems registry now runs on a new architecture, unlocking great new capabilities:

Publishing packages at organization level with GitHub Packages

Previously, RubyGems packages published to GitHub Packages were closely coupled to their repositories. Now packages can be published at an organization level. They can still be linked to a repository at any time, if needed.

Learn more about connecting a repository to a package.

Fine grained permissions for RubyGems packages published to GitHub Packages

You can now configure Actions and Codespaces repository access on the package's settings page, or invite other users to access the package. Additionally, RubyGems packages published to GitHub Packages can still be configured to automatically inherit all permissions from a linked repository.

Learn more about configuring a package's access control.

Internal visibility

In addition to public and private, a package's visibility can now also be set to internal. It is then visible for all members of the GitHub organization.


These new features are now available to all users on github.com.

Read more about working with the GitHub RubyGems registry

We appreciate your feedback on these new changes in GitHub's public community discussions!

See more

GitHub Enterprise Cloud admins can now display critical announcements to members of their enterprise or specific organizations. GitHub Enterprise Server already has this capability.

With this enhancement, Enterprise Cloud admins can display a critical message on all pages of their enterprise or in specific organizations. For example, you could announce a release cutoff date or an upcoming permission change. Announcements are displayed at the tops of pages as shown here:

An image showing how an announcement message appears on GitHub

To publish an announcement, you must be an enterprise owner or organization owner. Open your enterprise or organization settings and select Announcement. Enter your announcement message, an optional expiration when the announcement should be automatically unpublished, and select whether to allow users to dismiss the announcement when they see it. Click Publish announcement to publish it.

An image showing configuration of an announcement

For the best user experience, we recommend publishing only critical announcements and keeping the message brief to occupy less display space on each page. Link the message to a discussion for more context, guidance, and optional conversation. For non-critical messages or extended announcements, use a discussion instead.

For more details, see Customizing user messages for your enterprise in the GitHub Enterprise Cloud documentation.

See more