The Wayback Machine - https://web.archive.org/web/20230920130718/https://github.blog/changelog/

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

Enterprise managed users support for Ping Federate is now generally available

Now generally available, GitHub Enterprise Cloud customers with enterprise managed users (EMU) can integrate with Ping Federate as a formally supported SSO and SCIM identity provider. 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.

The Ping Identity logo

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

Easily customize code scanning using CodeQL model packs for Java (beta)

With CodeQL model packs for Java, users can improve their code scanning results by ensuring that any custom Java libraries and frameworks used by their codebase are recognised by CodeQL.

The out-of-the-box CodeQL threat models provide great coverage for identifying large numbers of potential vulnerabilities in GitHub repositories using code scanning. We are continually working to improve CodeQL's ability to recognize and track potential sources of untrusted data to potentially-vulnerable locations ('sinks'). To do that, we keep a close eye on the most widely-used open-source libraries and frameworks. That way, CodeQL can recognize untrusted data that enters an application through, for example, commonly-used web frameworks. We are even using advances in AI to boost our threat modeling efforts and help developers write even more secure code.

There will always be cases which are not covered by CodeQL's standard threat models, such as custom-built or inner-sourced frameworks and libraries. Using CodeQL's new model pack functionality for Java (beta), security teams and security-conscious developers can create custom models that help CodeQL detect and flag additional security vulnerabilities. These custom model packs work seamlessly in GitHub code scanning, which means developers get the most relevant code scanning alerts during their day-to-day work.

CodeQL model packs are part of the CodeQL package management ecosystem. The packs contain structured data which describe whether a method within a library is a taint source, sink, or propagator (also known as a flow summary). You can create CodeQL model packs for Java using the CodeQL model editor, a new feature in the CodeQL extension for VS Code. The CodeQL model editor includes support for:

  • identifying methods in your codebase that aren't recognised by the standard CodeQL analysis
  • interactively classifying those methods as a source, sink, or summary
  • automatically generating a CodeQL model pack that can be easily added to code scanning.

For more information about using CodeQL model packs in code scanning, see:

For more information about using the CodeQL model editor, see Using the CodeQL model editor.

See more

Migrate Bitbucket Server and Data Center repos to GitHub.com

After a successful public beta, we're launching support for Bitbucket Server and Bitbucket Data Center migrations in GitHub Enterprise Importer.

You can now easily use GitHub Enterprise Importer to migrate your source code, revision history, pull requests, reviews and comments when moving to GitHub from your self-hosted Bitbucket instance.

To learn more about the benefits of switching from Bitbucket to GitHub, check our our brand new blog post.

For a step-by-step guide on migrating from Bitbucket Server or Bitbucket Data Center, check out "Migrating repositories from Bitbucket Server to GitHub Enterprise Cloud" in the GitHub Docs.

See more

Migrate Bamboo and Bitbucket Pipeline to GitHub Actions

GitHub Actions Importer now supports migrations from Bitbucket, Bamboo Server, and Bamboo Data Center. Companies using those tools can plan, test, and automate the migration of pipelines to GitHub Actions more easily than ever before.

GitHub Actions Importer is available via the GitHub CLI or IssueOps. To get started, please visit our docs. For questions and feedback, check out the GitHub Actions Importer community.

See more

Increased Concurrency Limit for GitHub-Hosted Runners

GitHub-hosted runners now support up to 1000 concurrent jobs for our 4 – 64 vCPU runners, enhancing their capability to handle large-scale CI/CD workloads.

Our runners are designed to automatically scale to meet your needs. The concurrency limit feature allows users to specify the maximum number of jobs that can run simultaneously to execute Actions workflows. Previously capped at 250, we've made backend improvements to now support a maximum of 1000 concurrent jobs for runners within the 4-64 vCPU range for Windows and Linux operating systems.

Enterprise or organization administrators can set this concurrency limit under the Auto-scaling setting. GitHub-hosted runners with 4 or more vCPUs are available on both the GitHub Team and Enterprise plans.

If you have any feedback to help improve this experience, be sure to post it on our GitHub Community Discussion.

See more

Custom auto-triage rules for Dependabot alerts (public beta)

Auto-triage rules are a powerful tool to help you reduce false positives and alert fatigue substantially, while better managing your alerts at scale.

Starting today, you can now create your own custom rules to control how Dependabot auto-dismisses and reopens alerts – so you can focus on the alerts that matter, without worrying about the alerts that don’t.

What’s changing?

For any existing or future alerts that match a custom rule, Dependabot will perform the selected behavior accordingly. You can proactively filter out false positives, snooze alerts until patch release, and – as rules apply to both future and current alerts – manage existing alerts in bulk.

Frequently asked questions

Why is GitHub making this change?

At GitHub, we’ve been thinking deeply about how to responsibly address long-running issues around alert fatigue and false positives. Rather than over-indexing on one criterion like reachability or dependency scope, we believe that a responsibly-designed solution should be able to detect and reason on a rich set of complex, contextual alert metadata.

That’s why, moving forward, we’re releasing a series of ships powered by an underlying, all-new, flexible and powerful alert rules engine. Our first ship – Dependabot presets – leveraged our rules engine with GitHub-curated vulnerability patterns. Today’s ship exposes our rules engine so you can create your own rules, too.

Which criteria are supported?

Rules can be created across the following attributes:

Attribute Description
severity Alert severity, based on CVSS base score, across the following values: low, medium, high, and critical.
scope Scope of the dependency: development (devDependency) or runtime (production).
package-name Packages, listed by package name.
cwe CWEs, listed by CWE ID.
ecosystem Ecosystems, listed by ecosystem name.
manifest Manifest files, listed by manifest path.

What behaviors are supported?

Create or edit a custom rule

Today’s ship covers support for auto-dismissing alerts indefinitely as well as snoozing alerts until patch. Auto-dismissing ensures all activity is easily visible and can be caught by existing reporting systems and workflows, while also ensuring that alerts can be reintroduced if metadata across the alert changes.

How will this activity be reported?

Auto-dismissal activity is shown in webhooks, REST, GraphQL, and the audit log for Dependabot alerts. Alerts are dismissed without a notification or new pull request and appear as a special timeline event. As these alerts are closed, you’ll still be able to review any auto-dismissed alerts with the resolution:auto-dismissed filter.

Who can create and modify rules?

Auto-triage rules are free for open source repositories. Anyone who can enable Dependabot alerts for a public repository will be able to create custom rules for it. Customers of GitHub Advanced Security can create and manage custom rules across private repositories.

How do I reopen an automatically dismissed alert?

Like any manually dismissed alert, you can reopen an auto-dismissed alert from the alert list view or details page. This specific alert won’t be auto-dismissed again (by any other auto-dismiss rule).

What happens if alert metadata changes or advisory information is withdrawn?

Dependabot recognizes and immediately responds to any changes to metadata which void auto-dismissal logic. For example, if you change the dependency scope and the alert no longer meets the criteria to be auto-dismissed, the alert will automatically reopen.

How do I learn more?

How do I provide feedback?

Let us know what you think by providing feedback — we’re listening!

See more

Private Beta – Expand supported audit log event types with SAML SSO authentication data

In October 2022, we released a private beta adding linked SAML single sign-on (SSO) identities for relevant users to GitHub Enterprise audit log events.

We are expanding the private beta to now include linked identities within git events, making this information available across all relevant events.

Enterprise owners interested in participating in the private beta should reach out to your GitHub account manager or contact our sales team to have this feature enabled for your enterprise. Once enabled, enterprise and organization owners can provide feedback at the logging SAML SSO authentication data for enterprise and org audit log events community discussion page.

See more

GitHub Actions – Updates to GITHUB_REF and github.ref

We have implemented a fix so that GITHUB_REF and the github.ref context value return a fully-formed ref (e.g – refs/heads/main) when a workflow is triggered as a result of a pull request being merged. This change only impacts a small subset of workflows that trigger as a result of a pull request closing after being merged and that make use of GITHUB_REF or github.ref.

Previously, GITHUB_REF and github.ref were incorrectly returning a shortened ref (e.g. – main). These should always return a fully-formed ref regardless of the scenario.

Please visit our documentation for more details about using Actions context and variables.

For questions, visit the GitHub Actions community.

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

See more

Dependency review support for dependency submission results

Dependency review now works with your dependencies from the dependency submission API. Dependency review enforces policies around vulnerabilities and acceptable licenses in the pull request. Previously, dependency review could not be used with another feature of the dependency graph called the dependency submission API. The dependency submission API helps developers get a more accurate set of transitive dependencies, particularly for complex ecosystems like Gradle or Scala which require a build to resolve all transitive dependencies.

To take advantage of this improvement, update to the latest version of the dependency review action, or follow the instructions in our documentation.

For more information, see our documentation about dependency review, the dependency submission API, and some best practices for using dependency review and the dependency submission API together.

See more

[Private Beta] Sign up for full access to the GHEC Enterprise Managed Users SCIM API

Public documentation of the SCIM API for Enterprise Managed Users (EMU) is now available.

Administrators of EMU enterprises can use a token with the admin:enterprise scope to make GET requests from SCIM clients. With this read access, you can directly reconcile GitHub's understanding of SCIM-defined users and groups with your federated identity groups for auditing purposes.

Write requests to these APIs are possible through our published IdP applications, or through a new private beta that offers direct API access.

To get write access to these APIs in beta, register your interest here.

See more

Updated IP ranges for GitHub Enterprise Importer

We're making changes to the IP addresses used by GitHub Enterprise Importer for outbound network connections. These changes will take affect at 00:00 UTC on September 18, 2023.

If you're running migrations with GitHub Enterprise Importer and you have IP allowlisting enabled on your migration source or target, or an Azure Blob Storage or Amazon S3 account which you use for migrations, then you'll need to update your allow list.

For a full list of our IP ranges and more information, see "Configuring IP allow lists for migrations" in the GitHub Docs (https://docs.github.com/en/migrations/using-github-enterprise-importer/preparing-to-migrate-with-github-enterprise-importer/managing-access-for-github-enterprise-importer#configuring-ip-allow-lists-for-migrations).

Owners of organizations affected by this change were already sent an email notification on August 18, 2023, providing 30 days' notice.

See more

New 2FA account recovery options via password reset flow

Users with two-factor authentication enabled can now begin the account recovery process from the password reset flow. Previously, the account password was needed to access 2FA account recovery, but passwords on 2FA-enabled accounts could only be reset with a valid second factor. If you lost your password and all of your second factors, you were locked out because you could not access account recovery. With this change, a user can recover their account as long as they can perform email verification and provide a recovery factor, such as an SSH key, PAT, or previously signed in device.

Once you have performed email verification and provided a recovery factor, your recovery will be manually reviewed by GitHub's support team, who will email you within three business days. If your request is approved, you'll receive a link that lets you disable 2FA on your account. After that, you can reset your password and regain access to your account.

For more information about two-factor authentication, see "About two-factor authentication". For account recovery details, see "Recovering your account if you lose your 2FA credentials".

See more

GitHub Copilot – September 7th Update

In today’s update, we’re showing some love to our Copilot for Business admins with the release of the Copilot settings redesign and audit log integration!

💅🏻 Copilot for Business settings update

We’ve updated the Copilot for Business admin experience to provide an overview of important information and streamline the seat purchasing flow for Copilot. Quickly review the Copilot seats assigned and estimated charges at the top of the page, update your assignment settings without having to remember to hit a Save button, and verify the update to your bill when adding or removing users and teams.

Updated Copilot Overview settings page with seats assigned, estimated bill, and seat assignment

🪵 Review Copilot updates with audit log integration

Tracing updates to settings or seat assignments is key to help admins troubleshoot unexpected behavior within their organizations. Until now, admins had to contact support to help understand changes but as of today, they can now review Copilot events by using the GitHub Audit Log. To ensure administrators can quickly review Copilot updates, we included a new filter titled “Copilot Activity”. Understand settings changes, policy updates, and seat addition/removals right from the Audit Log UI in your organization settings.

Copilot filter selected in the audit log and the log showing Copilot events

Questions, suggestions, or ideas?

Join the conversation in the Copilot community discussion. We’d love to hear from you!

See more

GitHub Issues & Projects – September 7th update

Today’s Changelog brings you updates to project templates and historical charts, sticky group headers, and color improvements!

We’re continuing to make improvements to project templates for organizations (public beta). 👏

You can now view the project template that was used when a project was created. Once a template is used to create a new project, you can find and link back to the template from the project settings page in the “Templates” section. This allows you to reference the history of how a project was created and view any improvements made to the template since then.

templates settings page

You can also now use the CLI to mark a project as a template for members of your organization to use when getting started. The command will look like this:

gh project mark-template 1 --owner That-Lady-Dev

Check out the documentation for more details, and as well as the project CLI documentation to see all the possibilities of interacting with your projects from the terminal.

Be sure to drop a note in the feedback discussion to let us know how we can continue to improve project templates.

📜 Sticky group headers

Group headers are now sticky when scrolling through your project view. For example, if you have swimlanes on your board, scrolling to other columns and items will maintain the group name in view, making it easy for you to keep your place.

🎨 Updated colors for single select fields

The colors for single select fields have been updated, so you’ll now see the same colors within the field picker and on your project views.

single select field colors

➕ Create issues in board repository groups

You can now create issues when grouped by Repository on the board layout. Click Create new issue or start typing the title to get started.

creating issue in repository groups

📊 Updates to historical charts

Historical charts (available for GitHub Team and Enterprise Cloud plans) now show the state changes of your project items over time, allowing you to see how items have been opened and closed over time. This allows you to visualize the progress of your items over time, showing how much work has been completed and how much is left to do.

historical chart

Historical charts no longer support a Group by field.

✨ Bug fixes and improvements

  • Included the Slice by field configuration when you copy a project or use a project template
  • Improved the contrast of the roadmap today marker
  • Fixed the alignment between the filter bar and board columns
  • Fixed a bug where you could not copy a project or use a template if there were invalid disabled workflows
  • Fixed a bug where the view configuration menu alignement shifted when resizing a window
  • Updated the error message when setting a large column limit on board columns

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

Questions or suggestions? Join the conversation in the community discussion.

See more

Organization Archiving general availability

Building on the Public Beta of organization archiving, we're excited to announce that organization archiving is now generally available.

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
  • Email the organization's owners to let them know that the organization has 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"

We'd love to hear your feedback on how it works for you.

See more

Updates to your GitHub Feed

September 12, 2023 update:

When we launched the latest version of your feed on September 6, 2023, we made changes to the underlying technology of the feed in order to improve overall platform performance. As a result, we removed the functionality for “push events for repositories a user is subscribed to”. We don’t take these changes lightly, but as our community continues to grow tremendously, we have to prioritize our availability, user experience and performance. 

Thanks to feedback from the community, we have fixed the following bugs from the initial September 6th release:

  • We were showing releases for organizations that you follow, instead of only showing them for repositories that you watch or star. This is now fixed. 
  • We have also addressed a problem where ‘Followed You’ cards were sometimes appearing out of chronological order.
  • We do not plan to re-include “push events for repositories a user is subscribed to” for the reasons listed above, but we will continue to address feedback as it aligns with our platform goals.

Your homepage feed will now have a singular, consolidated feed that aggregates content from your starred repositories and followed users. As part of this update:

  • The content from the “Following” feed has been combined with the “For you” Feed, so you’ll have one singular location to discover content.
  • For those looking to customize, we’ve enhanced the filtering controls, enabling you to tailor your feed to display only the event types that matter most to you. Including:
    • Announcements (special discussion posts from repositories)
    • Releases (new releases from repositories)
    • Sponsors (relevant projects or people that are being sponsored)
    • Stars (repositories being starred by people)
    • Repositories (repositories that are created or forked by people)
    • Repository activity (issues and pull requests from repositories)
    • Follows (who people are following)
    • Recommendations (repositories and people you may like)
  • We’ve given the entire interface a fresh and visually appealing makeover ✨

image

What this means for you

If you’re an existing “Following” feed user, your feed content should be familiar to what you’ve been seeing on your “Following” tab. And now, with our new filtering control, you can fine-tune your content preferences to further curate your feed.

If you’re an existing “For you” feed user, we’ve also defaulted your filtering to showcase what you currently see on your “For you” tab. The new filtering control allows you to further customize your feed by including or excluding specific content types.

New users, we’ve got you covered with default settings that ensure you’re seeing the most relevant content. Dive in, personalize, and make the feed your own!

See more

Dual Static IP ranges for GitHub-hosted Larger runners

GitHub-hosted larger runners now support dual IP ranges when configured with Static IPs for the GitHub Enterprise Cloud plan.

Static IP enables Enterprise Cloud customers to choose whether a static IP address range will be assigned to their larger runner instances. This provides a fixed IP address range that can be added to your allow list for access to internal systems and can be used in conjunction with GitHub’s IP allow list to enable hosted actions runners and IP allow listing at the same time.

With dual IP ranges, larger runner instances will now receive two IP ranges instead of a single range. This enables runners to scale beyond the previously existing 500 concurrency limit. Additionally, the two IP ranges are created in different geographical locations, providing resiliency against regional outages.

Getting started

For newly created larger runner instances with the Static IP feature, 2 IP ranges will be assigned by default going forward and no additional action is required.

For existing larger runner instances that have Static IP configured:

  • GitHub will assign an additional IP range(s) that admins can view by heading to their existing static IP enabled larger runners.
  • Admins will have 30 days to update their existing firewalls or internal IP allowlists with the new IP ranges before GitHub starts utilizing the new ranges for the runners.
  • Admins will also receive an email guiding them to take the necessary steps for their existing static IP enabled larger runners to continue to function as they switch to the dual IP range functionality.

You can learn more about the Static IP feature by heading over to documentation. If you have any feedback to help improve this experience, be sure to post it on our GitHub Community Discussion.

See more
View more changes