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

You can now easily find all alerts associated with a specific language with the new language filter on the code scanning alerts page.

To show all the code scanning alerts for a language, type 'language:javascript' in the Filter alerts text box.

Language filter

You can also use a file path filter to see all the alerts located in specific files or directories to sort and manage them efficiently by focusing on a specific part of the code related to the project.
This can be useful to manage lots of alerts on big repositories (monorepos) to review all alerts specific to the part of the code you are responsible for faster.

To apply the file path filter, type 'path:' and the path to the file or directory in the Filter alerts text box.

Path filter

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

Learn more about filtering code scanning alerts.

See more

Starting today, you will now receive Dependabot alerts for vulnerabilities associated with your Swift dependencies.

The GitHub Advisory Database now includes curated Swift advisories. This brings the Advisory Database to twelve supported ecosystems, including: Composer (PHP), Erlang, GitHub Actions, Go, Maven, npm, NuGet, pip, Pub, RubyGems and Rust.

The dependency graph now supports detecting Package.resolved files. Swift dependencies from these files will be displayed within the dependency graph section in the Insights tab.

Dependabot security updates support will be added at a later date.

See more

For securely enabling OpenID Connect (OIDC) in your reusable workflows, we are now making the permissions more restrictive.

If you need to fetch an OIDC token generated within a reusable (called) workflow that is outside your enterprise/organization, then the permissions setting for id-token should now be explicitly set to write at the caller workflow level or in the specific job that calls the reusable workflow.

permissions:
id-token: write # This is required for requesting the JWT

This change would ensure that the OIDC token generated in the called workflow is allowed to be consumed in the caller workflows only when intended.

Learn more about permission settings to enable OIDC in your workflows

See more

Today's Changelog brings you board column limits, an improved item menu to move your board items and updates to Issue hierarchy powered by tasklists!

🔢 Board column limits

You can now set column limits on the board layout to help you limit your work in progress as well as promote focus on the items that really matter. Column limits are based off of the number of items in a column, and are unique to each board view.

To configure a limit, set the value from the column's ... menu. If you exceed the limit, the value will be highlighted in red.

As always, we'd love to hear from you! Let us know your feedback in our community discussion.

Updated menu to move board items

Following our support for bulk updates and keyboard shortcuts, we've made it even easier to move the items on your boards. Select the item ... menu to move an item to the top or bottom of a column, or to a different column altogether.

➕ Add tasklist button

a picture of the same issue in projects and in issues which shows the new add tasklist button on the bottom left of the issue description

You may have noticed a new button has appeared on issues and the projects side-panel! You can now easily add tasklists to your issues without ever having to enter your issue's Markdown.

📁 Drag and drop improvements in table layout

Items can be dragged into collapsed groups in the table layout. Items can also be dragged and dropped across groups when sorting is enabled.

🏗️ Export project view as a CSV file

You can now download a view by selecting the view menu and clicking Download CSV.

Screenshot 2023-06-15 at 2 42 26 PM

👀 Upcoming change to insights

Historical charts will no longer support group by values. We will be phasing historical charts out over the next couple of months and no new accounts will be added to the existing support.

Bug fixes and improvements

  • Fixed a permissions bug when reordering fields within a group
  • Single select edit option modal updates preview label text
  • Updated icon color of Make a copy icon
  • Fixed visual bug on Delete project and Issue transfer modals
  • Can now delete a project if there is an emoji in the name
  • Issue title created using the Add item bar now populates in the issue create modal
  • Added keyboard shortcuts for metadata edits (improvements to this coming soon!)
  • Tasklists now throw an error (instead of silently failing) when formatting is incorrect
  • Fixed a bug where tasklist name changes were not being persisted
  • Fixed a regression where tasklists did not show the preview title when adding issues
  • Fixed a regression in the tasklist omnibar which broke the autocomplete functionality
  • Fixed a bug preventing users from selecting multiple rows in the table
  • Fixed a bug where users couldn't copy assignees table cells

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

Building upon the success of our organization-level security coverage and risk views, today we're introducing enterprise-level views to offer enhanced visibility into your enterprise's security coverage and risk analysis. The refreshed design provides you with an improved user experience with insights and dynamic filtering to maximize your productivity.

Coverage view

The coverage view allows you to gain visibility into the enablement status of security features across all repositories within your enterprise. Within the coverage view, you can:

  • Monitor the counts and percentages of repositories with GitHub security features enabled or disabled, which update when you apply filters.
  • Track enablement for additional security features, including secret scanning push protection, Dependabot security updates, and code scanning pull request alerts.

Enterprise-level security coverage

Risk view

Complementing the coverage view, the new risk view provides a comprehensive overview of all alerts across your enterprise. In the risk view, you can:

  • View the counts and percentages of repositories with security vulnerabilities, which also update when you apply filters.
  • Access open alerts categorized by severity for both Dependabot and code scanning.

Enterprise-level security risk

Both views are now available as a public beta. In the next few weeks, we will deprecate the enterprise-level overview page in favor of these two new views.

Learn more about the new risk and coverage views and send us your feedback

Learn more about GitHub Advanced Security

See more

Organization administrators can now specify the maximum number of organization-billed codespaces that any member of the organization, or collaborator, can create.

By default, without this new policy, if organization members or collaborators are permitted to create codespaces that are billable to your organization, they can create multiple such codespaces. The number of codespaces someone can create is governed by a limit to the total number of codespaces that they can create across all repositories they can access. This limit is set by GitHub. With this new policy you can now control the maximum number of organization owned codespaces someone can create.

When this policy is applied to an organization, members or collaborators who meet or exceed this limit will be unable to create new codespaces that are billed to the organization. In order to create a new organization-billed codespace, they must first delete existing codespaces owned by the organization to get below the specified limit. The maximum codespaces policy does not impact user-billed codespaces, or codespaces created on repositories that are not owned by the organization. The policy must be applied across the entire organization, and cannot target specific repositories.

This policy, especially when combined with the existing retention period and idle timeout policies, provides organization administrators new ways to control cost within their organization, while encouraging best practices around cleaning up codespaces that are no longer in use.

To get started, review the documentation for how to apply a maximum codespaces per user policy within your organization.

Additional Resources

See more

You can now archive all repositories in an organization with a single click. Archiving an organization will:

  • Archive all repositories in the organization
  • Set a key in the API to indicate the org has been archived
  • Restrict activities in that organization such as creating new repos
  • Display a banner on the organization's profile indicating that it's been archived

To archive an organization, go to the organization's settings page and click the "Archive organization" button in the Danger Zone. This will launch a background job which performs the archiving; once complete, the banner will show up on the organization's profile page.

For more information on organization archiving, including how to un-archive an organization, see "Archiving an organization"

This feature is in public beta. We'd love to hear your feedback on how it works for you.

See more

An image titled "GitHub Global Navigation Beta" that shows the top of a GitHub webpage that has the new navigation UI.

The beta of GitHub’s redesigned site navigation is now enabled for everyone by default and includes additional improvements and bug fixes.

Overview:

In April, the redesigned navigation beta became available to anyone who manually enabled it for their account. The changelog for that release included:

  • Breadcrumbs to provide you with a clear understanding of your location on GitHub.
  • New menus that make your top repositories and teams available from every page on GitHub.
  • A consistent, responsive, and more accessible experience that lets you navigate GitHub using any device and assistive technology.

Today’s release enables the new navigation beta for everyone by default and includes improvements based on feedback:

  • A separate button that opens the left menu, containing links to home, issues, pull requests, and discussions.
  • The GitHub icon links to the home dashboard.
  • Links to issues and pull requests at the upper level of the navigation, available in one click without opening a menu.
  • Improvements to the mobile and responsive experiences.
  • Bug fixes, including accessibility improvements.

Image of the new navigation, with the left menu open, featuring links to repositories and teams

We welcome your feedback on the new navigation beta in the feedback portal.

Note: While in beta, the new navigation can be switched on and off under Global navigation update in Feature preview.

See more

Code scanning now has the option to enable default setup for a subset of languages in a repository. This lets you customize the configuration to suit your repository's needs, for example deselecting a language which is failing the analysis.

Default set up makes it easy to get started with code scanning. The supported languages are currently JavaScript/TypeScript, Python, Ruby and Go and the list is constantly evolving.

When you choose default setup, we automatically tailor a code scanning configuration for the repository. By default we will enable the best CodeQL configuration for all languages in your repository. However, if there is a language that you'd prefer to disable in code scanning, you can now customize the languages in your default setup configuration.

Use the 'edit configuration' page or REST API to edit the default setup configuration for a repository. You can customize the languages and query suites used in the analysis. The configuration can be viewed and edited at any time, during or after set up.

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

For more information on code scanning default setup, see Configuring code scanning automatically.

See more

We've shipped a small fix to improve security around creation of pull requests in public repos.

Prior to this fix and under very specific conditions, a user could create a pull request in a public repo even though they did not have push access to either the base or head branch and were not a member of the repo's organization. Often these pull requests were created by mistake and quickly closed, but could still trigger unexpected GitHub Actions or other CI jobs.

This fix has no impact on the common open source workflow where a user forks a public repo, makes a change in their fork, and then proposes their change using a pull request. This fix also has no impact on pull requests already created.

We want to hear from you! Let us know if you have questions or feedback.

See more

GitHub Enterprise Cloud customers with enterprise managed users (EMU) can now integrate with Ping Federate as a formally supported SSO and SCIM identity provider in public beta. To get started, download the Ping Federate "GitHub EMU Connector 1.0" from the add-ons tab on the download page, under the "SaaS Connectors" heading. Add the connector to your Ping Federate installation and consult the Ping Federate documentation in addition to GitHub's SAML SSO and SCIM documentation for configuration.

PIC-Square-Logo-Primary

The "GitHub EMU Connector" is maintained and supported by our partner, Ping Identity. Ping additionally maintains their own release notes for this connector.

See more

Repositories in the user namespace of enterprise-managed users (EMU) can now be seen and accessed by enterprise administrators. All repositories in the user namespace (e.g. https://github.com/mona_tenantName/scratch) can now be navigated to from the Repositories enterprise policies page: https://github.com/enterprises/<enterprise>/settings/member_privileges. From this new view, administrators can temporarily grant themselves administrative rights to these repositories. This action will trigger alerts to the repository owner as well as audit log events.

This public beta feature set is intended to increase visibility of namespace repositories to administrators while also empowering administrators to audit these repositories as needed.

To learn more, check out our documentation about viewing user-owned repositories in your enterprise and accessing user-owned repositories in your enterprise.

See more

Node12 has been out of support since April 2022. As a result we have started the deprecation process of Node12 for GitHub Actions. We plan to migrate all actions to run on Node16 by Summer 2023.
Following on from our warning in workflows using Node12 we will start enforcing the use of Node16 rather than Node12 on the 14th of June.

To opt out of this and continue using Node12 while it is still available in the runner, you can choose to set ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true
as an 'env' in their workflow or as an environment variable on your runner machine. This will only work until we upgrade the runner removing Node12 later in the summer.

What you need to do

For Actions maintainers: Update your actions to run on Node16 instead of Node12 (Actions configuration settings)
For Actions users: Update your workflows with latest versions of the actions which runs on Node16 (Using versions for Actions)

See more

Enterprise administrators can now disable repository level self-hosted runners across organizations and enterprise user namespaces.

Once this new setting has been enabled users will no longer be able to register new self-hosted runners in a repository and existing runners will not be able to receive new jobs.

Learn more about Disabling or limiting GitHub Actions for your organization

See more

If you manage your node.js dependencies with the pnpm package manager, you can now use Dependabot to keep those dependencies updated with automatic pull requests. You can easily configure this feature by adding or updating your dependabot.yml file in your repository. At this time, Dependabot will not open security alerts against pnpm dependencies.

See more

All eligible GitHub Enterprise accounts can now try GitHub Advanced Security for free for 14 days. GitHub Advanced Security provides integrated security with unparalleled access to curated security intelligence. This unlocks your ability to keep your code, supply chain, and secrets secure before pushing the code to production. During the trial, you can try features such as:

  • Code scanning to help find and remediate security issues in your code
  • Secret scanning to prevent and detect secret exposures across your organization
  • Dependency review to catch vulnerable dependencies before introducing them to your environment

Explore our documentation to learn more about GitHub Advanced Security features and how to deploy them in your organization.
GitHub Advanced Security on Enterprise Cloud

See more

Today, we're launching a new brand new tool for migrating from other code hosting platforms to GitHub and between GitHub products: GitHub Enterprise Importer (GEI).

With GitHub Enterprise Importer, you can migrate to GitHub.com or GitHub Enterprise Cloud and bring your source code and collaboration history (for example code reviews and comments) with you.

We’re publicly launching GitHub Enterprise Importer today — but already, it has been used by over 2,000 customers to migrate more than 400,000 repositories to GitHub Enterprise Cloud.

Today, we support the following migrations paths:

  • Azure DevOps to GitHub.com
  • GitHub Enterprise Server to GitHub.com
  • Moving your existing GitHub.com repos to an enterprise with Enterprise Managed Users enabled

Next up, we'll be launching support for migrations from Bitbucket Server and Bitbucket Data Center. If you're interested, you can sign up for our private beta here.

To learn more, head over to "Using GitHub Enterprise Importer" in the docs and check out our blog post.

See more

GitHub Codespaces plans to release improved access controls for organizations on June 22nd, 2023. These changes will provide organizations additional control over which of their organization’s members or outside collaborators are allowed to use GitHub Codespaces on private and internal repositories. This change will not affect public repository usage.

Today, any user with read access to an org-owned private or internal repository can create a codespace from that repository. The organization may elect not to pay for this Codespace usage, but currently there is no way to block the usage entirely. On June 22nd, GitHub Codespaces will introduce additional Access, Billing, and Ownership settings to more granularly control this behavior. With these new settings, organization admins can decide who within the organization is allowed to create codespaces from private and internal organization-owned repositories, and who owns those created Codespaces:

Some codespace usage may be impacted by this change. Organization owners will receive an email if anyone in their organization has a codespace that will be deleted because it was created from a private or internal repository by an org member or collaborator who will not have the appropriate permissions after this change.

Will I be impacted by this change?

This change will impact organizations that have configured their organization’s billing settings to either “Selected members” or “All members”. If your organization has specified one of those options, members or outside collaborators who are not specified in the list of selected users will lose access to GitHub Codespaces created from impacted internal or private repositories.

Administrators will receive a separate email if anyone in their organization has a codespace that matches these criteria.

What should I do if I am impacted?

Organization administrators should review the list of specific users who are currently allowed to bill codespaces usage to their organization to ensure all members who should have access, continue to have access. This can be done by adding them to the existing billing setting before June 22, 2023 to be migrated over to the new access setting.

Adding new users to this list will automatically transfer codespace ownership to the organization for any existing, personally owned codespaces created by these users on organization owned repositories. Once this happens, these codespaces will no longer be impacted by this change. Before doing this, ensure your spending limit is properly configured.

Users with impacted codespaces should either push any unsaved changes from these codespaces, or export their changes to a new branch. This will ensure that no code is lost as part of this change.

What will happen to existing codespaces impacted by this change?

Codespaces impacted by this change will become inaccessible when the updates are released, and will be permanently deleted 7 days after that.

Details about the change

Today, any organization member or outside collaborator with read access to a repository can create a codespace on that repository. While the organization may elect not to pay for this usage, the member or outside collaborator can still pay for their own usage.

This release will introduce two control mechanisms for access and ownership.

Access will control which users are allowed to create codespaces on private and internal repositories within your organization. There will be four options:

  • Disabled: Codespaces are not enabled within the organization’s private and internal repositories.
  • Specific members: The organization can select specific members who are allowed to create codespaces on the organization’s private and internal repositories.
  • All members: Any full member of the organization is allowed to create codespaces on the organization’s private and internal repositories.
  • All members and outside collaborators: Anyone associated with your organization (full member or outside collaborator) is allowed to create codespaces on the organization’s private and internal repositories.

Ownership and Billing controls who pays for codespace usage, who receives the audit log events from codespace usage, and whose policies are applied to the codespaces. There will be two options:

  • Organization owned: All codespaces created by organization members for organization-owned repositories will be owned by the organization, send events to the organization’s audit log, and apply the organization’s codespace policies.
  • User owned: All codespaces created by organization members on organization-owned repositories will be owned by the creating user, send events to the user’s security log, and apply the user’s codespace policies.

Please contact support if you have any issues.

Additional Resources

See more

The option to use SMS on the sudo page on GitHub.com has been removed. Users can still use other 2FA methods as well as their password to pass the sudo check and take sensitive actions. If your account only has SMS as its 2FA method, you can visit your security settings to enable additional methods such as security keys and TOTP, as well as installing the GitHub Mobile app.

To learn more about the GitHub.com sudo prompt, see "Sudo mode". For details about setting up additional 2FA methods, see "Configuring two-factor authentication".

See more

The "Remove a repository from an app installation" API has been updated to fail early if attempting to remove a repository from an application that is installed on all repositories.

To switch an application InstallationState from the all to some state in your organization, an organization owner or application manager must make this change within the UI, while picking up to 50 repositories for the app to continue to have access to. From there, additional repositories can be added via the UI or the "Add a repository to an app installation" API.

To learn more about managing application installations, see "Modifying repository access". For details on the GitHub App REST API, see "GitHub Apps".

See more