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

GitHub Actions: Use the GITHUB_TOKEN with workflow_dispatch and repository_dispatch

Customers will now be able to use the GITHUB_TOKEN with workflow_dispatch and repository_dispatch events to trigger workflows. Prior to this change, events triggered by GITHUB_TOKEN would not create a new workflow run. This was done to prevent the accidental trigger of endless workflows. This update makes an exception for workflow_dispatch and repository_dispatch events since they are explicit calls made by the customer and not likely to end up in a loop.

name: Create Workflow Dispatch

on:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Workflow
        uses: actions/github-script@v6
        with:
          script: |
            github.rest.actions.createWorkflowDispatch({
              owner: context.repo.owner,
              repo: context.repo.repo,
              workflow_id: 'test.yml',
              ref: 'main',
            })

For more details see
Triggering a workflow from a workflow.

For questions, visit the GitHub Actions community.

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

See more

Dependabot unlocks transitive dependencies for npm projects

Your GitHub repositories with Dependabot alerts enabled and Dependabot security updates enabled will automatically generate Dependabot pull requests for vulnerable npm transitive dependencies.

Previously, Dependabot couldn't generate a security update for a transitive dependency when its parent dependency required incompatible specific version range. In this locked state, developers had to manually upgrade the parent and transitive dependencies.

Now, Dependabot will be able to create pull requests for npm projects that upgrade both the parent and child dependencies together.

For example, if a vulnerability for the transitive dependency node-forge triggers a Dependabot alert and allows a PR to be created:

2 generated security update white bg

Prior to this change Dependabot would fail to create a Dependabot security update for transitive dependencies :confused:. But not anymore! 😀 Now, Dependabot will unlock the node-forge security update by bumping the parent webpack-dev-server version in addition to patching the `node-forge dependency within the same Pull Request!

3 update PR white bg

This change will apply to pull requests generated by Dependabot that update vulnerable npm packages.

See more

Custom repository role creation APIs are now available in public beta

Custom repository roles enable Enterprise organization administrators to define and assign least-privilege roles for their repositories, beyond the standard Read, Triage, Write, Maintain, and Admin roles.

Now, REST API endpoints to create and update custom repository roles are available in a public beta for GitHub Enterprise Cloud customers. These new endpoints build on the existing custom repository role APIs that allow assignment of those roles to a team or user. The endpoints accept PATs from organization admins, as well as calls from properly authorized OAuth and GitHub apps.

These REST APIs will be supported in GitHub Enterprise Server 3.8, after they reach general availability in GitHub Enterprise Cloud.

Find out more about programmatically creating custom repository roles.

We'd love to get your feedback through your account team, or in our community Discussions board topic.

See more

Better suggested pull request description from commit message

When opening a pull request from a comparison that only includes one commit, GitHub defaults the title and description to the subject line and body of that commit's message. Authors who write detailed git commit messages that adhere to the widely accepted convention of wrapping at 72 characters per line may have noticed that this can result in strange formatting because of how GitHub Flavored Markdown treats newlines.

We now take and automatically reformat the commit message when suggesting the pull request description, making it look just as good as the commit message it came from when viewed on github.com, GitHub Mobile, and other tools.

An image of a PR being opened before and after this change

Learn more about Creating Pull Requests

See more

The new GitHub Issues – September 2nd update

Today’s Changelog brings auto-hiding columns based on board filters, item numbers in table layout, updated enterprise project visibility settings, and issue transfer updates!

🙈 Auto-hide columns with board filters

You ask, we deliver! With today’s release, project boards will automatically hide columns depending on the filters you’ve applied. Customize your boards with the exact set of columns you need – no more empty columns here!

board columns

#️⃣ Item number displayed in table layout

Addressing a popular customer request, issue and pull request numbers are now displayed alongside the title in the table layout. Quickly identify item numbers without having to open the issue to PR or search to find your specific items. 🔢

image

⚙️ Enterprise visibility settings for GHEC

Enterprises on GHEC now have the ability to set the policy for who is able to change the visibility of projects within its organizations.

Enterprise admins can change the visibility setting in the Enterprise Projects Policies page. 👀

image

📝 Issue transfer updates

Based on your feedback, we have updated issue transfers to avoid label duplication. 🚫 🏷️ 🏷️

When transferring an issue between repositories:

  • Labels will now only be transferred if they already exist in the target repository.
  • Milestones will now be transferred if they exist, with matching names and due dates, in the target repository.

Our GraphQL API has been updated to include a flag for anyone looking for the old behavior. If you would like to transfer an issue and create new labels at the same time, you can use the ‘createLabelsIfMissing‘ flag.

✨ Bug fixes & improvements

Other changes include:

  • Fixed a bug in the filter bar so that Reviewers:@me works as expected.
  • Updated the Date selection component to be consistent across browsers and project pages.
  • Quickly add a PR from a repo that has Issues disabled by pasting its link into the project. We’ll render it correctly now!

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

GitHub Actions Larger runners – Are now in public beta

Today, we are announcing the public beta of larger GitHub hosted runners for GitHub Actions for Team and Enterprise plans 🎉 🎉

The new larger runners provide new capabilities for Team and Enterprise GitHub Action users:

  • Linux and Windows machines up to 64 cores
  • Fixed IP ranges to provide access to runners via allow list services
  • Admin control over access to larger runners and concurrency

Larger machine sizes

Developers will be able to make use of machine sizes up to 64 cores on demand to run their workflows, billed by the job minute.

image

Fixed IP ranges

Setup a fixed IP range for your machines by simply ticking a check box, this provides an IP range that can be allow listed in internal systems and in GitHub’s allow list to keep using Actions while making your GitHub environment more secure.

image

Admin control

Admin’s can choose who can have access to larger machine sizes and at what concurrency, providing guard rails on spending
image

Larger machine pricing

Larger runners are charged for in both private and public repos and do not consume included minutes.
To learn more about the larger runner per job minute pricing, check out the updated pricing docs

To learn more about using the new larger runners, check out our docs

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

See more

Update and configure code security enablement settings via the organization REST API

At the organization level, you can now view (GET) and update (PATCH) enablement status as well as configure the setting to automatically enable new repositories for the following GitHub security products:

  • Dependency graph
  • Dependabot alerts
  • Dependabot security updates

If you are a GitHub Advanced Security customer, you can also view and update the same settings for:

  • Secret scanning
  • Push protection

In addition, GitHub Advanced Security customers can view and update the enablement status for GitHub Advanced Security at the organization level.

Learn more about the organization REST API and send us your feedback

Learn more about GitHub Advanced Security

See more

Autolinks with alphanumeric or numeric IDs

Previously, we announced a change to how <num> parameters work for autolink references, switching from numeric to alphanumeric IDs. We heard from a number of customers who still need numeric identifiers. Now when creating an autolink reference, you can use an alphanumeric or numeric identifier.

Screenshot of Autolink references

Autolinks are available in repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub's products.

Learn more about autolinks at Configure autolinks in the GitHub documentation. We appreciate feedback on this and other topics in GitHub's public feedback discussions.

See more

Packages: Fine-grained permissions and organization-level publishing are now available for the GitHub Packages npm registry

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

Publishing packages at organization level with GitHub Packages

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

Learn more about connecting a repository to a package.

Fine grained permissions for npm packages published to GitHub Packages

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

Learn more about configuring a package’s access control.

Internal visibility

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

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

Read more about working with the GitHub npm registry

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

See more

Audit Log Streaming to Datadog available as Public Beta

GitHub Enterprise Cloud (GHEC) customers can now participate in a public beta enabling audit log streaming to a Datadog endpoint. Joining this beta allows enterprises to continue to satisfy long-term data retention goals and also analyze GitHub audit log data using the tools offered by Datadog.

GHEC administrators interested in participating in the public beta can enable audit log streaming by following the instructions for setting up streaming to Datadog. Customers can provide feedback on their experience at the audit log streaming to Datadog community discussion.

See more

Code scanning: customize your CodeQL analysis using query filters

The default code scanning query suites include checks for the most important security vulnerabilities for each supported language, so that any potential problems can be surfaced to developers before they are committed to their repository. However, in some situations a particular check is not relevant for a codebase and you might prefer to not run that CodeQL query. You can now easily exclude queries using code scanning query filters.

Query filters use the same syntax as CodeQL query suites and you can filter on any CodeQL query metadata property. Query filters must be specified in a custom code scanning configuration file, which you refer to from your code scanning analysis workflow file.

In your code scanning workflow file, use the config-file parameter of the init action to specify the path to the configuration file you want to use:

- uses: github/codeql-action/init@v2
  with:
    config-file: path/to/config/file.yml

In your configuration file, specify the query filters you want to use. For example, to exclude the Unsafe HTML constructed from library input query from the default code scanning query suite for JavaScript you can specify its id in an exclude block:

name: "My code scanning CodeQL config"

query-filters:
- exclude:
     id: js/html-constructed-from-input

For more information about how to use query filters, see Configuring code scanning in the code scanning documentation.

See more

Updated design for Notification Settings

We've updated the notifications settings page to be more vibrant and easier to understand what changes you're making. Here are some of the updates:

  • Confirmation of which email you'd like to receive notifications at
  • Grouping of your subscriptions and where you receive notifications
  • Grouping of system-related notifications

Learn more here.
An image showing the before and after of notification settings changes. Top of the UI features the ability to choose the default notifications email, with ability to automatically watch repositories and teams just below. From there, a developer can manage their subscriptions for repositories as well as system-related notifications.

See more

GitHub Desktop 3.0.6 Community Contributions

GitHub Desktop 3.0.6 brings a slew of community contributions! As an open source project, we are always so grateful to our contributors who make Desktop better for themselves and others. Additionally, we’ve improved the recognition of default branch changes.

Adds:

  • Add Warp terminal integration for macOS. Thanks @lhvy!
  • Add PyCharm Community Edition support on macOS. Thanks @tsvetilian-ty!
  • Add context menu to the current branch and current repository toolbar. Thanks @uttiya10!

Fixes:

  • Older versions of Sublime Text and SlickEdit are also recognized as external editors. Thanks @vbwx!
  • Fix commit shortcut (Ctrl/Cmd + Enter). Thanks @tsvetilian-ty!
  • Show 'Email' label on the preferences form when user is not signed in. Thanks @andymckay!
  • Fix invalid URL state while the "Clone Repository" modal is open. Thanks @tsvetilian-ty!
  • Fix commit description with three lines overflowing when it shouldn't. Thanks @HeCorr!
  • 'Update from default branch` menu item allows quick merge of upstream. Thanks @uttiya10!
  • Unified diff line gutter context menu items for discard changes no longer enabled when whitespace is hidden.
  • 'Show Whitespace Changes' popover appears as expected on unified diff.
  • On pull or fetch, make sure the default branch is updated to match the repository settings.
  • Fix notifications on Windows 10 builds prior to the Creators Update.

Improvements:

  • Add ability to skip staggered release to ensure the latest version is downloaded.

Learn more about GitHub Desktop

See more

Secret scanning: Admins can now provide a link to display when a push is blocked

GitHub Advanced Security customers using secret scanning can now specify a custom link that will show in the error message when push protection detects and blocks a potential secret. Admins can use the custom link to provide their developers with a point of reference on best practices with secrets.

Learn more about protecting pushes with secret scanning.

Custom link displayed in a push protection error message

See more

Improved UI for syncing a fork

We updated the web UI to make keeping forks in sync with their upstream repositories more intuitive. "Fetch upstream" has been renamed to "Sync fork," which better describes the button's behavior. If the sync causes a conflict, the web UI prompts users to contribute their changes to the upstream, discard their changes, or resolve the conflict.

Image of sync fork button

Read more about branches.

Read more about working with forks.

See more

GitHub Actions: Enhancements to OpenID Connect support to enable secure cloud deployments at scale

OpenID Connect (OIDC) support in GitHub Actions is now enhanced to support secure cloud deployments at scale.

Org & repo admins can use the new OIDC API support to:

  • enable a standard OIDC configuration across their cloud deployment workflows by customizing the subject claim format.
  • ensure additional compliance & security for their OIDC based deployments by appending the issuer url with their enterprise slug
  • configure advanced OIDC policies by using the additional OIDC token claims like repository_id and repo_visibility.

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

See more

New options for controlling the default commit message when merging a pull request

In May we shipped a setting for including the pull request title in the default commit message presented to users when squash merging a pull request. We just shipped more options for customizing the default commit message, including using the pull request's description! You can also now customize the default commit messages for merge commit merges. The goal is more predictable, consistent, and useful commit messages for your pull requests, which translate to a more useful Git commit history.

How it works

From repository settings, a maintainer or admin can choose the default format for commit messages produced when merging pull requests:
image

This selection is used to form a default commit message that gets presented to users on the pull request page when merging a pull request. For example, assume Default to pull request title and description is selected and a user clicks to merge a pull request with this description:
image

The default commit message will include the pull request's title and description:
image

The user can then accept this commit message or make changes before merging.

Options

For merge commit merging:

  • Default message: pull request number and head branch on the first line; pull request title on the third line
  • Pull request title: pull request title and number on the first line
  • Pull request title and description: pull request title and number on the first line; pull request description starting on the third line

For squash merging:

  • Default message: commit title and commit message (if the pull request contains a single commit), or the pull request title and number and list of commits (if the pull request contains multiple commits)
  • Pull request title: pull request title and number on the first line
  • Pull request title and commit details: pull request title and number on the first line; commit message (if a single commit) or list of commits (if multiple commits)
  • Pull request title and description: pull request title and number on the first line; pull request description starting on the third line

Additional details

If no message is provided when merging a pull request using the REST API or GraphQL mutation, a default commit message will be formed based on the selected message format and merge method.

The default message format can be managed using the Create a repository or Update a repository REST APIs. See the merge_commit_title, merge_commit_message, and squash_merge_commit_title, squash_merge_commit_message parameters.

Feedback

We want to hear from you! Tell us what you think and how we can make it better: https://github.com/orgs/community/discussions/30439

Learn more

Learn more about configuring merge commit merging and configuring squash merging.

See more
View more changes