Skip to content

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

Today's update brings the ability to set an allowlist for languages within the IntelliJ extension, quickly switch to an annual GitHub Copilot for Individuals plan, and the private preview of code referencing.

Select languages setting within IntelliJ

The previous disabledLanguages configuration is replaced with a new, more flexible languageAllowList configuration. This change allows enabling or disabling all languages at once using the * wildcard.

github-copilot.xml location

The github-copilot.xml file is located at

~/Library/Application Support/JetBrains/<IDE+VERSION>/options/github-copilot.xml

For example the path to github-copilot.xml for IntelliJ version 2022.3 is

~/Library/Application Support/JetBrains/IntelliJIdea2022.3/options/github-copilot.xml

github-copilot.xml for enabling all languages (default behavior)

<application>
  <component name="github-copilot">
    <languageAllowList>
      <map>
        <entry key="*" value="true" />
      </map>
    </languageAllowList>
  </component>
</application>

You can now specify an individual language override if your configuration also includes a wildcard.

github-copilot.xml for disabling all languages except for Kotlin and Java

<application>
  <component name="github-copilot">
    <languageAllowList>
      <map>
        <entry key="*" value="false" />
        <entry key="kotlin" value="true" />
        <entry key="java" value="true" />
      </map>
    </languageAllowList>
  </component>
</application>

A new hidden languageAllowListReadOnly configuration property has been added that makes languageAllowList readonly in the UI.

github-copilot.xml for making the UI setting readonly and enabling all languages

<application>
  <component name="github-copilot">
    <option name="languageAllowListReadOnly" value="true" />
    <languageAllowList>
      <map>
        <entry key="*" value="true" />
      </map>
    </languageAllowList>
  </component>
</application>

An easier way manage your Copilot for Individuals trial and plan

We've heard confusion from users on how to switch between monthly and annual billing. We want you to feel fully in control of your GitHub Copilot plan so we've updated the Plans and Usage page to make it easier to swap between your plan options. Just head down to the Copilot plan section and hit the Manage subscription button to see your options.

We've also added the option to activate your Copilot trial directly from this page and while we'd hate to see you go, if you find that Copilot isn't for you during your trial, you can quickly cancel it before it converts into a paid plan.

DURING TRIAL

Try out code referencing [Private Beta]!

Last week, we announced our private beta for code referencing in Copilot. Learn more by heading to our blog post or join the waitlist today!

Questions, suggestions, or ideas?

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

See more

GitHub Advanced Security customers can now perform on-demand validity checks for supported partner patterns, and the alert index view now shows if a secret is active. This builds on our release of enabling automatic validation checks for supported partner patterns back in April.

When the “Automatically verify if a secret is valid” setting is enabled on a repository, users will see a “Verify secret” button on the alert page. This sends the secret to our relevant partner provider to see if the secret is active and updates the status on the alert and index pages.

screenshot of an adafruit io key alert with a verify secret button

As we work with our partners to add support for more secrets, we'll update the "Validity check" column in the documented supported secrets list.

See more

If you are using the Dependabot grouped version updates feature (currently in public beta), you can now tell Dependabot to ignore updates in the group (similar to how you can do it for Dependabot's individual updates). While closing a grouped pull request will still not create ignore conditions, you can use Dependabot comment commands to tell Dependabot to ignore certain updates in the group – either a specific minor update, a specific major update, or all updates for one dependency.

On a grouped pull request, you can now also tell Dependabot to stop ignoring certain updates that you have already ignored. By commenting @dependabot unignore, you can specify either to stop ignoring a specific range of updates, all updates for a specific dependency, or all updates for every dependency in the group. Dependabot will now also list in the pull request body all the ignore conditions it used to build the pull request. Alternatively, you can comment @dependabot show <dependency-name> ignore conditions and Dependabot will list the ignore conditions for that dependency.

For more information on Dependabot ignore conditions and chat commands, please see the documentation.

See more

If you are using the Dependabot grouped version updates feature (currently in public beta), you can now group your pull requests by dependency type in ecosystems that support this. Instead of listing all the dependencies by name or pattern for your groups, you can now also use the dependency-type key (set to either "production" or "development") to create groups based on dependency type. Then, on your version updates schedule, Dependabot will try to open one pull request to update all available dependencies of that type.

For more information on how to use this feature, check out our documentation on configuring groups for Dependabot pull requests.

See more

Today’s Changelog brings you the brand new slice by, updates to issue forms, and a group menu across layouts!

🍕 Slice by

You can now slice by field values in your project views! Configuring a Slice by field allows you to quickly toggle through and review your project items broken down by a field, saving you additional filters and views to quickly understand the state and details of your project. While you can slice by your issue and project fields to customize your view, some helpful slice by views include:
– Single select fields to view items broken up by status, priority, or team
Labels to group items by repository labels
Assignees to see who is working on what

slice_by

Select a Slice by field from the view configuration menu. This will pull the field values into the panel on the left, allowing you to click through the values in the list to adjust the items shown in the view.

See it in action on the GitHub public roadmap, and check out the documentation for more details.

📋 Updates to issue forms

You can now configure custom issue forms to automatically add an issue to a project as well as set defaults for drop downs by adding a YAML form definition file to the /.github/ISSUE_TEMPLATE folder in your repository.

issue form yaml syntax

For more comprehensive instructions on syntax for issue forms, check out the documentation.

We’re looking to improve the experience around issue forms and templates. If you have any feedback 👉 drop a comment in our community discussion!

Group menu for item and group actions

We’ve added a group menu to quickly take action on items in a group or on the group itself. Click ... from the group header on your tables, boards, or roadmaps to archive or delete all items in a group, edit the group details directly, hide the group from the view, or delete it from your project.

group menu

Bug fixes and improvements

  • Fixed keyboard navigation and focus when navigating to Make a copy from the project ... menu
  • Fixed group header spacing on the roadmap layout
  • Fixed a bug where using the @next filter qualifier for iteration fields was referencing the incorrect iteration
  • Fixed a bug with the numerical Field sum decimal precision

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

A new header will be sent back to API callers that use the fine-grained permission model (GitHub Apps and fine-grained PATs) to help developers discover which permissions are needed to call an API route. This new header, x-accepted-github-permissions, contains the list of permissions required to access the endpoint.

In the fine-grained permission model more than one permission may be needed to access an endpoint. Multiple sets of permissions may also be valid, since there are multiple ways to access data within GitHub. All valid sets are included in the header, each set separated by a semicolon (;).

For example, when calling "List project collaborators", you'll recieve the header x-accepted-github-permissions: repository_projects=write; organization_projects=admin. This indicates that to get the list of collaborators on a project, you need either the repository_projects Write permission or the organization_projects Admin permission.

This header is used in the same way as the x-accepted-oauth-scopes header for coarse-grained scope actors (OAuth apps and PATs (Classic)).

To learn more about troubleshooting permissions issues with GitHub Apps and fine-grained PATs and to get more information about this header, see "Insufficient permission errors". To see the permissions needed for each endpoint, see "Permissions required for GitHub Apps" and "Permissions required for fine-grained PATs".

See more

GitHub environments can be configured with deployment branch policies to allow-list the branches that can deploy to them.

We are now security hardening these branch policies further by blocking runs triggered from forks with branches that match the protected branch name. We are also preventing tags with the same name as a protected branch from deploying to the environments with branch policies around protected branches.

Learn more about configuring environments with deployment protection rules to set up rigorous and streamlined guardrails for your deployments.

For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

See more

Secret scanning's push protection feature prevents supported secrets from being pushed into repositories, and has to date been enabled at the repository, organization, or enterprise level.

Now, everyone across GitHub can enable push protection for themselves within your individual settings. This ensures your pushes are protected whenever you push to a public repository on GitHub, without relying on that repository to have push protection enabled.

To opt in, go to the "Code security and analysis" section of your personal settings. Next to "Push protection for yourself", click Enable.

GitHub will enable push protection for all GitHub Free individuals by default in January, 2024.

See more

The administrator account (ending in _admin) of Enterprise Managed User enterprises is now required to enter sudo mode before taking sensitive actions. As with standard user accounts, the administrator must provide their password or a second factor credential to enter sudo mode.

Sudo mode is a GitHub security feature that validates the user's session before they perform a sensitive action, like creating a personal access token, deleting an organization, or updating their credentials.

Until now this mode was disabled for all Enterprise Managed Users (EMUs), as they had no credentials on GitHub.com and therefore could not provide one for the sudo mode prompt. As a result, EMU accounts are able to take sensitive actions without being asked for a credential. However, the admin for the EMU enterprise does have credentials on GitHub.com and will now be asked for them before taking sensitive actions.

For more information about sudo mode, see "Sudo mode". To learn more about Enterprise Managed Users, see "About Enterprise Managed Users".

See more

The GitHub Enterprise Server 3.10 release candidate is here

GitHub Enterprise Server 3.10 gives customers more control over how their instance is used and run. Here are a few highlights:

  • Code Scanning configuration can be customized per repository, allowing repository owners to decide which languages to analyze by default.
  • Fine-grained personal access tokens (PATs) are now available as a public beta on Enterprise Server, giving developers and administrators granular control over the permissions and repository access granted to a PAT.
  • Assess security risk and coverage data across all organizations in an enterprise via the Code Security tab.
  • Define who can merge pull requests, and how they are merged, to make it easier for you to meet your compliance and security goals.
  • Reduce data transfer required to backup your Enterprise Server by utilizing incremental backups of MySQL data in backup-utils v3.10.0.
  • GitHub Projects is now generally available in Enterprise Server.

If you are upgrading from Enterprise Server 3.8 then this release also includes an upgrade from MySQL 5.7 to 8, which will increase I/O utilization. Please read this page for more details on this increase and how to mitigate it if you see an unacceptable degradation of performance on your instance.

Release Candidates are a way for you to try the latest features at the earliest time, and they help us gather feedback early to ensure the release works in your environment. They should be tested on non-production environments. Here are some highlights for this release. Read more about the release candidate process.

Read more about GitHub Enterprise Server 3.10 in the release notes, or download the release candidate now. If you have any feedback or questions, please contact our Support team.

See more

For security reasons, source IP addresses have been removed from error messages that are returned from the GitHub API when callers try to access protected resources from non-permitted IP addresses.

To learn more about IP allow lists, visit Restricting network traffic to your enterprise with an IP allow list in the GitHub documentation.

If you'd like to learn more about your source IP addresses, please contact GitHub Support.

See more

The code scanning REST API updated_at field has been improved to help you review your most recently changed alerts.

The updated_at timestamp now returns the alert's most recent state change on the branch that you requested. We consider a state change to be a significant event, including an alert being introduced, fixed, dismissed, reopened or reintroduced. This is implemented in both the repo API and org API so it can be used consistently at scale.

Previously, the updated_at timestamp changed whenever an alert was found in an analysis or the alert state changed, and so was updated very regularly. This improvement lets you efficiently use updated_at to sort and focus on your most recently changed alerts.

The code scanning REST API list alerts endpoints code-scanning/alerts returns the value for the default branch, unless another branch is specificed. The alert endpoint code-scanning/alerts/{alert_number} reports at the alert level, so will return the maximum value for the alert across all branches.

This is now live on GitHub.com for the repository level API. This will be live for the organization level API over the next few days because it requires data reindexing. This will ship to GitHub Enterprise Server version 3.11. For more information, see the code scanning REST API documentation.

See more

When you migrate to GitHub.com with GitHub Enterprise Importer, user activity (e.g. issues, pull requests, comments) is linked to placeholder identities called "mannequins".

After you've finished migrating, you can "reclaim" those mannequins, linking the migrated activity to users' GitHub.com accounts. As part of this process, users receive invitations, asking them to accept the mannequin attribution.

Now, organizations using Enterprise Managed Users (EMU) can reclaim mannequins immediately, skipping the invitation process. This can be done one-by-one, or in bulk using a CSV.

To use this new feature, you'll need to update to the new v1.0.0 version of the GitHub Enterprise Importer CLI, released today.

For more details, see "Reclaiming mannequins for GitHub Enterprise Importer" in the GitHub Docs.

See more

We are excited to announce the alpha release of Copilot in GitHub Support, a faster way to find answers to your GitHub related questions! Copilot in GitHub Support is an AI-powered assistant that answers questions based on our official GitHub Enterprise Cloud documentation.

Initially, we’re offering the Copilot experience to a limited number of randomly selected GitHub Enterprise Cloud customers. We hope to continue rolling out the experience to a wider audience over the coming months.

If your ticket is selected, you’ll be provided with an option to opt-in while creating your support ticket. During the alpha, GitHub will be reviewing answers provided and collecting feedback from participating customers to improve the accuracy.

Copilot in GitHub Support is part of our ongoing effort to make GitHub the best place for all developers to collaborate, innovate, and ship great software. We believe that Copilot in GitHub Support will enhance your experience and productivity.

We look forward to hearing from you and learning from your feedback.

See more

Support for migrating Jenkins Scripted Pipelines to GitHub Actions is now available as a private beta! If you use Scripted Pipelines in your Jenkins instances, you can now automate the migration of your pipelines to GitHub Actions using GitHub Actions Importer.

To get started, please reach out to your GitHub account manager or contact our sales team! For questions and feedback about the private beta, please visit the GitHub Actions Importer community.

See more

What would you do with twice the memory on your computer? How about 30% better CPU performance?

We’ve leveled you up!

Over the past six weeks we’ve upgraded underlying infrastructure for Codespaces, migrating from Intel to AMD based CPUs, which boast improved specs.

As of today, 4-core and higher Codespaces now include twice the RAM, and 30% better CPU performance, at no additional cost to you. You now get snappier performance and more room for your processes to stretch out without having to lift a finger. We’ll be rolling out the same upgrade for the 2-core Codespaces in a matter of days.

Save money

If you’re using an 8-core machine because you need the RAM, now you can save cost by backing that down to a 4-core machine so you get twice the bang for the buck. Same goes for scaling down from 4 to 2 cores, and so on. Because free usage of GitHub Codespaces is calculated by cores per hour, using a smaller machine will also give you more free coding hours.

Now your GitHub Codespaces cloud dev environment builds, tests, and shares your running application faster than ever, at the same price.

Note: this release does not affect the machines used in the generation of Codespaces prebuilds.

Give ‘em a spin! https://github.com/codespaces

See more

We will be moving the private beta of required workflows on GitHub Actions to Repository Rules to give organization administrators a powerful way to protect their repositories with added feature benefits including unified configuration, dry running workflow rules, branch targeting, and a consistent UI experience.

Starting September 20th, 2023, users can configure their workflows using rulesets in order to run and pass in selected repositories before merging their code. On October 18th, users will no longer be able to access Actions Required Workflows and must use rulesets in its place.

How does this impact beta users of Actions Required Workflows?

Existing Actions Required Workflows private beta users will continue to have access until October 18th, 2023, allowing them time to adapt to the forthcoming changes. During this transitional period, users will maintain their existing workflows without disruption. This ensures that organizations can smoothly navigate the migration process, avoiding any abrupt disruptions to their current code merging practices. Here’s a quick overview of the events leading up to the move.

For GHEC customers

Leading up to October 18th:

  • GitHub will attempt to automatically migrate any existing Required Workflows to Rulesets for customers.
  • Any workflow files that did not successfully migrate will need to be manually migrated by code owners.

After October 18th:

  • The ability to require a workflow to pass before merging code will only be available on GitHub Enterprise plans via Repository Rules
  • Organization Rulesets will enable administrators to define, configure, and manage all workflows required to pass before merging code in repositories.
  • The feature formally known as Actions Required Workflows will no longer be accessible and users will be directed to Rulesets.

For GHES customers by version

  • GHES 3.8 and 3.9 will not be impacted until their next upgrade
  • GHES 3.10 and 3.11 will not be impacted if Actions Required Workflows are already in use
  • GHES 3.12 Requiring a workflow to run and pass before merging will be only be available vis Repository Rulesets

To learn more about how Repository Rules can help control how people can interact with branches, visit our documentation.

See more

As of August 17, 2023, Dependabot will no longer support Python 3.6 or 3.7, which have reached their end-of-life. If your code uses these versions, Dependabot will no longer be able to open pull requests in your repository and will log errors. Update to at least Python 3.8 to ensure your code is secure and Dependabot can still run.

View the official release cycle for Python for more information on supported versions.

See more