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

Organization owners can now grant a user or team access to all of the repositories in their org with a single click. Five new pre-defined roles have been added to the organization settings, under Organization Roles > Role Management, where all organization owners can view and assign them.

Pre-defined roles ship natively with GitHub. We will add more pre-defined roles over time that support common personas like “CI/CD Admin” or “Security Manager”.

A screenshot showing the five new roles in the organization settings

Introducing pre-defined roles and organization-wide repository permissioning

These five new roles showcase an expansion of organization roles – the ability to also include repository-level base roles (like read) and permissions (like close issue). When granted, the recipient has those privileges on all of the repositories in the organization, current and future. While organization owners cannot yet create organization roles that include repository permissions, that will be supported in the coming months.

A screenshot of the Triage role expanded to show the repository permissions included in the role

This new functionality of organization roles helps organizations replace automation that watches for new repository creation and adds the right users or team to every repository.

UI updates to show role assignments

When users and teams are assigned access across all repositories, this is called out in the team and repository view rather than list all of the accesses.

A screenshot showing that this team has access to all of the repositories in the organization. Below it is a listing of the repositories that the team has been given specific access to.

In addition, the Roles Management view in the organization settings has been updated to show indirect assignments – these are roles that a user or team recieves due to a team that they are a member of. This provides a full accounting of all organization roles that a user or team has within the organization.

A screenshot showing a user that has been granted two roles. One is directly assigned, and has a remove button on the right hand side of the row. The other is indirectly assigned via a team named org-member-parent-team, and does not have a remove option.

The APIs for organization role management have been updated to support these pre-defined roles. You’ll find a base_role field in the description of the organization role, which is the repository role (like read) that is included in the organization role.

You can learn more about organization roles at “Using organization roles“.

See more

Over the next few weeks, jobs generating Dependabot pull requests will start running as GitHub Actions workflows on Github.com accounts with GitHub Actions enabled. This migration will include faster Dependabot runs, increased troubleshooting visibility, self-hosted runner support, and other performance and feature benefits. No additional steps are required, and you should not experience service disruptions during the migration. By the beginning of September, repositories with GitHub Actions enabled should expect to see the jobs that generate Dependabot pull requests run as GitHub Actions workflows.

Running Dependabot does not count towards GitHub Actions minutes – meaning that using Dependabot continues to be free for everyone.

Are you so excited for the Dependabot performance benefits that you want to get started today? You can optionally enroll your repositories and/or organizations before the migration begins! Get started by opting in to run Dependabot PR jobs as GitHub Actions workflows here.

If your organization has disabled GitHub Actions by policy, Dependabot will continue to run on the legacy compute provider. If you want to use Dependabot on GitHub Actions, an organization administrator must update your configuration before opting in to run Dependabot on GitHub Actions.

Check out our docs to learn more about Dependabot on GitHub Actions. For additional information, check out our blog post or previous changelog.

See more

Code security configurations are now generally available (GA)!

Code security configurations simplify the rollout of GitHub security products at scale. They help you define collections of security settings and apply them across groups of repositories.

Since the beta release on April 2, 2024, we’ve launched several improvements, including configuration enforcement and an API.

We have sunset the old organization-level code security settings UI experience along with the API parameters that complemented it.

All new changes to security settings must happen through the new code security configurations expereince. Organizations that were previously opted out of the experience have been opted back in. All default settings for new repositories have been migrated to a configuration called “Legacy” and automatically applied to new repos.

Learn more about code security configurations, the configurations REST API, or send us your feedback.

See more

When rolling out code scanning default setup at scale (e.g., via code security configurations), GitHub checks if an advanced CodeQL setup already exists for each repository. If an advanced setup exists, GitHub retains it and does not enable the default setup.

Starting today, it will be easier to understand if a repository will be converted during an at scale rollout.

Previously, GitHub would consider a repository to be using an advanced setup if the repository had ever had a CodeQL analysis. After this change, a repository is now considered as using an advanced CodeQL setup only if:

  • In the last 90 days, there has been a CodeQL analysis for the default branch, and
  • the workflow file associated with the latest CodeQL analysis in the default branch has not been deleted or disabled.

How does this affect me?

The improvements to the detection of existing CodeQL setups impacts you only if you are doing a rollout of code scanning at scale using (e.g.,) code security configurations and had previously used CodeQL via an advanced setup on some of your repositories.

If you are doing a rollout at scale, and want a repository to be considered for conversion to default setup, you can now delete or disable the associated yml file or you can delete the associated configurations for API-based advanced setups.

These changes will simplify enabling default setup at scale by increasing the number of repositories that are converted from advanced to default setup during an at scale rollout.

How do I convert my repo from advanced setup to default setup?

You can always enable default setup at the repository level. If there is a yml workflow file in the repository, GitHub will disable it for you. If you are doing API uploads, however, you need to adjust your CI/CD systems to stop submitting analyses. Note that while default setup is enabled, all CodeQL uploads via the API will be rejected.

How do I convert my repos from advanced setup to default setup at scale?

To convert multiple repos you have two options.
1. Use the default setup repository-level API, or
2. Use organization-level code security configurations to configure all the GHAS products in one go.

Note that repositories will be converted from default to advance only if they meet any of following criteria:

  • The latest CodeQL analysis on the default branch is older than 90 days old.
  • All CodeQL configurations have been deleted.
  • (Exclusively for yml-based advanced setups) The workflow file has been deleted or disabled.

Can I use an API to bulk disable advanced setups that use yml workflow files?

Yes. You can directly disable the associated workflow file by calling the Actions endpoint via the REST API. To do so, you will need to know the name of the workflow file. The name of the workflow file can be found in the code scanning /analyses endpoint.

See more

Code security configurations will be made generally available (GA) on July 10th, 2024. At that point, we will sunset the old organization-level code security settings UI experience along with the API parameters that complemented it.

If you are currently using the ‘Update an organization’ REST API endpoint to set default security settings for new repositories, or the ‘Get an Organization’ REST API endpoint to retrieve current defaults for security settings on new repositories, those parameters will now be ignored. However, previous default settings have been saved to a code security configuration called “Legacy” in your organization, and will continue to apply.

The parameters will be removed entirely in the next version of the REST API.

To change the default security settings for new repositories, you can use the code security configurations UI, the configurations API, or the unaffected enterprise-level security settings.

Learn more about code security configurations, the configurations REST API, or send us your feedback.

See more

GitHub Copilot Enterprise subscribers in Visual Studio can now use Copilot Chat to get answers enriched with context from Copilot knowledge bases. To try out this functionality, you’ll need to be running Visual Studio 17.11 Preview 3 or later.

You can access a knowledge base from any Copilot Chat conversation by typing @github, pressing the # key, selecting a knowledge base from the autocomplete, and then entering your question. Copilot will respond, using the Markdown documentation in your knowledge base as context for its answer.

For more details, check out the docs for Copilot Chat in Visual Studio.

See more

Starting today, the npm registry will begin removing README content from package version metadata to reduce the size of package packuments, and improve the performance of the registry and package managers, including the npm cli.

A packument is the top-level package document that lists the set of manifests for available versions for a package. Users can observe the packuments using tools such as pacote.

See more

The various improvements, features, and fixes shipped in June for iOS and Android.

In June, we released a number of improvements to the GitHub Mobile apps, mostly focusing on accessibility and enhancing existing features.

iOS

We now allow users to navigate to GitHub URLs by pasting them into the search bar on the Home tab. This makes it easier to quickly access repositories, issues, and pull requests from the app.

 

We’ve added the ability to hide disruptive comments within GitHub Discussions, and have added syntax highlighting for Haskell code snippets.

  • Addressed memory leaks when viewing changed pull request files and pinned repositories on user profiles.
  • Enabled opening draft releases without a tag directly within the app.
  • Displayed line counts next to long file names in pull request files changes navigation.
  • Aligned placeholders in comment views to the inputted text.
  • Improved keyboard navigation in the Explore feed to open selected repositories within the app instead of a web browser.
  • Aligned the account selection chevron next to the username in the Profile for accounts without a display name.
  • Scaled the current account login and display name with Dynamic Type on iPad.
  • Enhanced usability by opening the context menu on the first tap of the context button on comments.
  • Resolved issues causing crashes when viewing GIFs within repository source code.
  • Wrapped long URLs in repository profiles onto multiple lines for better readability.
  • Improved VoiceOver functionality by announcing no search results when searching for favorite repositories.
  • Made project single-select field pickers appear as buttons for assistive technologies.
  • Scaled usernames and repository names within headers in profile views with Dynamic Type.
  • Dismissed review events display the review author’s name in the timeline.
  • Enabled expanding or collapsing security vulnerability reference details using VoiceOver within Copilot Chat code blocks.
  • Implemented an error message display when Copilot chat fails to generate a message.
  • Improved accessibility by announcing the role of reason selectors when sending feedback about a Copilot response.
  • Implemented a flash scroll bar indicator for Copilot suggested messages at large font sizes.

Android

  • The name input dialog in the new file creation flow now alerts users when attempting to use unsupported recursive paths.
  • Resolved issue where in-app language preferences were not applied to all sections in the issue or pull request screens.
  • Fixed commit id mismatch after updating a branch in pull request screen.
  • Fixed the accessibility role for comment author badges.
  • Improved color contrast and TalkBack in Home and Repository screens.
  • Improved keyboard shortcuts in Projects and Repository screens.
  • Improved keyboard navigation in the Profile screen.
See more

GitHub Pages’ legacy pagesworker architecture has been shut down on June 30th, 2024.

In August 2022, GitHub Actions became the default method to build and deploy Pages sites. Starting today, the fallback pagesworker architecture is no longer available.

To build a Pages site from a branch with Jekyll, you must enable GitHub Actions in the repository settings. Alternatively, if GitHub Actions is unavailable or disabled, adding a .nojekyll file to the root of your source branch will bypass the Jekyll build process and deploy the content directly. In this case, you would need to build the site yourself and push the static assets to your source branch.

Branch deployment remains available but now requires GitHub Actions unless a .nojekyll file is used.

Learn more about GitHub Pages

See more

Delegated bypass for push protection has expanded support to cover pushes from the web file editor. When your organization or repository configures a delegated bypass list for push protection, any commits from the file editor that include secrets will be blocked, and the committer will need to submit a bypass request for review.

See more

GitHub Actions GPU hosted runners are now generally available for Windows and Linux, providing T4 GPU access to Actions customers. These GPU hosted runners empower developers working on machine learning, game development, or with GPU-accelerated code to complete all their CI building and testing on GitHub-hosted runners.

The GPU hosted runners are fully managed by GitHub, with images managed by trusted partners on the Azure marketplace. They are also compatible with GitHub Hosted runners’ static IPs and private networking capabilities.

Get Started

Customers can begin using GPU hosted runners in their organization or enterprise by:
1. Setting up new larger runner GPUs through their runner groups
2. Updating the ‘runs-on’ syntax in their Actions workflow file to call that runner name

More information about setting up, using, and pricing for GPU runners can be found in our documentation on hosted runners.

We’re eager to hear your feedback on these runners, share your thoughts in our community discussions using this template.

See more

GitHub Enterprise administrators now have a better user experience on the Enterprise Licensing page `https://www.github.com/enterprises//enterprise_licensing`. We have revamped the Enterprise Cloud content to make the data more intuitive and straightforward, saving you time when managing your licenses.
ghe-subscription-example

  • Enhanced Usability: The Enterprise Cloud card has been updated to be more intuitive and user-friendly. Further, we’ve simplified how license usage is presented for enterprises using the Visual Studio Subscription with GitHub Enterprise license bundle, making it clearer and easier to understand your usage metrics.
  • Optimized CSV Download Experience: The Licensing page’s CSV download feature has been improved to provide better feedback on the report’s status. For reports that have a large volume of data, we will now email the CSV report to you once it’s ready to avoid confusion and unnecessary waiting.

Join the discussion within GitHub Community.

See more

Secret scanning validity checks are now generally available.

Starting today, validity checks will be included in the ‘GitHub recommended’ setup through code security configurations and will be enabled for any newly attached repositories.

Please note that on July 24, validity checks will also be enabled retroactively for any repositories that had attached the GitHub recommended configuration before July 2, 2024. If you wish to directly manage feature enablement moving forward, we recommend unattaching the recommended configuration and attaching your own custom configuration to those repositories.

Learn more about secret scanning and validity checks

GitHub secret scanning lets you know if your secret is active or inactive with partner validity checks. These checks are run on an ongoing basis for supported providers for any repositories that have enabled the validity check feature; you can also perform on demand validity checks from the alert details page.

Learn how to secure your repositories with secret scanning, participate in the community discussion with feedback, or sign up for a 60 minute feedback session on secret scanning and be compensated for your time.

See more

Starting today, you can enable validity checks for your GitHub organization through security configurations.

You can also more easily enable or disable validity checks at the enterprise level with the ability to enable or disable for all enterprise repos.

If your organization had previously enabled validity checks through the ‘Global Settings’ page, the feature will be migrated to your existing configurations and enabled on repositories they are attached to with no additional effort on your part.

Please note that GitHub is also adding validity checks to the ‘GitHub recommended’ code security configuration. Any organization which has enabled the recommended configuration before today will have validity checks automatically enabled on July 24, 2024. If you wish to directly manage feature enablement, we recommend unattaching the recommended configuration and attaching your own custom configuration to those repositories.

Learn more about secret scanning and validity checks

GitHub secret scanning lets you know if your secret is active or inactive with partner validity checks. These checks are run on an ongoing basis for supported providers for any repositories that have enabled the validity check feature; you can also perform on demand validity checks from the alert details page.

Learn how to secure your repositories with secret scanning or sign up for a 60 minute feedback session on secret scanning and be compensated for your time.

See more

GitHub users can create software bill of material (SBOM) files for their repositories to help them understand its dependencies. SBOMs are a machine-readable inventory of a project’s dependencies and associated information. With this release, we have added copyright attribution data for dependencies in the SBOM.

Learn more about SBOM files and how GitHub helps you secure your software supply chain.

See more

Today’s changelog brings you GraphQL and webhook support for project status updates and project custom field changes directly in the webhook event!

Using GraphQL and webooks with project status updates

Following our release earlier this year for project status updates, you can now interact with project status updates using GraphQL and webhooks. This unlocks new ways to automate how you provide and gather project status update information.

GraphQL

There is a new ProjectV2StatusUpdate GraphQL object to interact with project status updates, so you can view, create, update, and delete status updates.

Below is an example query to create a new project status update.

mutation {
  createProjectV2StatusUpdate(
    input: {projectId: "0123456", body: "We wrapped up our bug bash following the beta rollout. We're back on track for our GA date in August! 🚀", startDate: "2024-06-03", targetDate: "2024-08-09", status: ON_TRACK}
  ) {
    statusUpdate {
      id
      startDate
      targetDate
      body
      bodyHTML
      status
    }
  }
}

Webhooks

Project status updates are included in the new projects_v2_status_update webhook event, so you can understand and be notified when a new project status update is provided.

You must be subscribed to this event from the organization settings page to receive this information.
organization settings for webhook event

Below is an example of a webhook event.

{
    "action": "edited",
    "projects_v2_status_update": {
        "id": 32633,
        "node_id": "PVTSU_lADOBH2n9s4Ajp6VzX95",
        "project_node_id": "PVT_kwDOBH2n9s4Ajp6V",
        "creator": {
          ...
        },
        "body": "We've kicked off this project and are feeling confident in our rollout plan. More updates and demos to come next week!",
        "start_date": "2024-06-24",
        "target_date": "2024-08-16",
        "status": "ON_TRACK",
        "created_at": "2024-06-24T20:27:48Z",
        "updated_at": "2024-06-24T20:30:47Z"
    },
    "changes": {
        "body": {
            "from": "We're still planning this out and are kicking off soon.",
            "to": "We've kicked off this project and are feeling confident in our rollout plan. More updates and demos to come next week!"
        },
        "status": {
            "from": "INACTIVE",
            "to": "ON_TRACK"
        },
        "start_date": {
            "from": null,
            "to": "2024-06-24"
        },
        "target_date": {
            "from": null,
            "to": "2024-08-16"
        }
    },
    "organization": {
        ...
    },
    "sender": {
        ...
    }
}

Using webhooks for project custom field changes

Project custom field changes are now included directly in the project_v2_item webhook event when a project item’s fields are edited, removing the need to send an additional GraphQL query. This gives you the previous and current field values to understand how project fields change over time and how long they have a particular value, allowing you to understand how long an item was In progress before moving to Done status.

Below is an example of the webhook which includes the previous and current value for single select, text, number, iteration, and date project custom fields using the changes parameter.

"changes": {
    "field_value": {
        "field_node_id": "PVTSSF_lADOBH2n9s4Aje1Izgb1kEs",
        "field_type": "single_select",
        "field_name": "Status",
        "project_number": 18,
        "from": {
            "id": "f75ad846",
            "name": "Todo",
            "color": "GREEN",
            "description": "This item hasn't been started"
        },
        "to": {
            "id": "47fc9ee4",
            "name": "In Progress",
            "color": "YELLOW",
            "description": "This is actively being worked on"
        }
    }
},

Bug fixes and improvements

  • Added the convertProjectV2DraftIssueItemToIssue GraphQL mutation to convert drafts to issues
  • Fixed an error message when resizing columns in the table layout
  • Fixed errors when migrating a classic project to the new Projects experience
  • Fixed a bug where updating an issue in the project side panel didn’t reflect in the project view
  • Fixed the rendering of special characters in a single-select field description from the table layout cell dropdown
  • Fixed a bug where a space could not be added in project chart titles

✍️ Tell us what you think!

Join the conversation in the community discussion to share your feedback.

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

See more

June CE Changelog

Another month, and another exciting set of updates for Copilot Enterprise. Let’s dig in:

Copilot Chat in GitHub.com can now answer questions about your pull requests, discussions, and files.

Catch up on Pull Requests: Copilot can answer questions about a Pull Request and give you an overview of the changes the Pull Request introduces. To learn more, see “Asking questions about a specific pull request” in the GitHub docs.
Try it yourself: Navigate to a Pull Request on GitHub.com, and ask Copilot to Tell me about this Pull Request

Get more out of Discussions Copilot can help you get up to speed quickly by summarizing discussions and discussion comments. In addition, Copilot can identify themes in the discussion and commentary made by different participants aiding you in catching up on context seamlessly. To learn more, see “Asking a question about a specific issue or discussion” in the GitHub docs.
Try it yourself: Navigate to a discussion on GitHub.com, and ask Copilot to Summarize this discussion

Ask about Files and learn about recent changes: Copilot can now tell you about a file or retrieve the most recent changes in the file on any branch. Ask Copilot to tell you what has changed in a file to gain a deeper understanding into your codebase and what’s changing in it. To learn more, see “File details skill” in the GitHub docs.
Try it yourself: Navigate to a file on GitHub.com, and ask Copilot to What's changed in this file recently?

Copilot Enterprise features are now available in Visual Studio Code and Visual Studio

As announced earlier this month, Copilot Enterprise features are now available in Visual Studio Code and in Visual Studio for the first time. (For Visual Studio, you’ll need to be running Visual Studio 17.11 Preview 2 or later.)

Chat with the context of the web in Visual Studio Code and Visual Studio: GitHub Copilot can now search Bing to find information outside of its general knowledge or your codebase. Just mention @GitHub, and Copilot will intelligently decide when to use Bing. Bing search is only available if enabled by an administrator – for more details, see “Enabling GitHub Copilot Enterprise features”.

Get answers from across your entire codebase in Visual Studio: Copilot Chat can now answer questions with understanding of your full repository, not just the tabs you have open. Index your repository on GitHub.com, and then ask a question mentioning @GitHub. You can ask questions like @GitHub Where is device detection implemented?.

Access your Copilot knowledge bases in Visual Studio Code: You can now access your knowledge bases from any Copilot Chat conversation by typing @GitHub #kb, selecting a knowledge base from the list, and then entering your question. Copilot will respond, using the Markdown documentation in your knowledge base as context for its answer.

As always, we welcome any feedback on Copilot Enterprise in the discussion within GitHub Community.

See more

Starting today, you can now perform on demand validity checks for NuGet API keys and supported Azure connection strings. These checks will also continue to run on an ongoing basis.

GitHub secret scanning lets you know if your secret is active or inactive with partner validity checks. These checks are run on an ongoing basis for supported providers for any repositories that have enabled the validity check feature; you can also perform on demand validity checks from the alert details page.

Learn how to secure your repositories with secret scanning or sign up for a 60 minute feedback session on secret scanning and be compensated for your time.

See more

Auto-triage rules help you reduce alert and pull request fatigue, while better managing your alerts at scale.

With Dependabot auto-triage rules, you can create your own custom rules to control how Dependabot ignores alerts with auto-dismissal, snoozes and reopens alerts, and generates pull requests to fix alerts – so you can focus on the alerts that matter, without worrying about the alerts that don’t.

Rules can be created with the following alert attributes:
– CVE ID
– CWE
– Dependency scope (devDependency or runtime)
– Ecosystem
– GHSA ID
– Manifest path (for repository-level rules only)
– Package name
– Patch availability
– Severity

For more information and how to use this feature, please refer to our documentation.

See more