The Wayback Machine - https://web.archive.org/web/20220921232539/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

CodeQL for VS Code: download CodeQL databases from GitHub.com

We have started creating and storing CodeQL databases for the most popular open-source projects on GitHub.com. If you use CodeQL for security research, you can now obtain these databases easily and directly through the CodeQL extension for Visual Studio Code, which makes it much easier to write and run your own custom CodeQL queries.

Using CodeQL for security research

The CodeQL engine powers GitHub code scanning: it analyses source code and flags up potential security problems (for example, in pull requests). By default, code scanning runs a large set of open source queries that are able to identify the most important and common security problems.

CodeQL is also a powerful tool for variant analysis and other types of security research. CodeQL treats source code as data, and anyone can write custom CodeQL queries to explore a codebase and identify vulnerabilities. Like code search on steroids!

The first step of any CodeQL analysis is extracting the source code into a CodeQL database. This database contains a relational representation of the source code — including elements like the abstract syntax tree, the data flow graph, and the control flow graph. You can create CodeQL databases yourself using the CodeQL CLI, but with the feature we shipped today, it's much quicker to get started: you can download a ready-built CodeQL database from GitHub.com.

Downloading CodeQL databases from GitHub.com in VS Code

To download a CodeQL database for use in the CodeQL extension in VS Code:

  1. Make sure you have set up the CodeQL extension for VS Code. For more information, see Setting up CodeQL in Visual Studio Code.
  2. Open the CodeQL databases view in the extension.
  3. Hover over the sidebar, click the GitHub icon, and specify the owner/repo identifier of the public repository you'd like to analyze.

    image

Once you've downloaded a CodeQL database, you're ready to start your research. Find more information in the CodeQL documentation.

FAQs

How many CodeQL databases are available?

We currently store databases for over 200,000 repositories on GitHub.com. That list is constantly growing and evolving to make sure that it includes the most interesting codebases for security research.

What languages are can you download CodeQL databases for?

We create and store databases for all of the languages that we support in CodeQL code scanning. For more information, see About code scanning with CodeQL.

Can I download CodeQL databases outside VS Code?

Yes, you can also download CodeQL databases using the GitHub REST API. For more information, see Downloading databases from GitHub.com in the CodeQL CLI documentation.

Why is there no CodeQL codebase available for my favourite open source repository?

If there is a repository that you'd like to analyze, but a CodeQL database is not available yet, then you can trigger the creation (and storing) of a database by enabling GitHub code scanning with the CodeQL engine. Alternatively, you could fork the repository and enable code scanning on the fork. For more information, see the code scanning documentation.

See more

GitHub Sponsors: Fiscal host support for user accounts

Today, we're adding support for users to create a GitHub Sponsors profile and choose to receive sponsorship payouts via a fiscal host. This will give maintainers more flexibility and choice in how they receive funding. This has already been possible for organizations creating a GitHub Sponsors profile, and that remains unchanged. Users and organizations can still choose to use a Stripe Connect account instead of a fiscal host if they prefer. Learn more about signing up for a GitHub Sponsors profile using a fiscal host.

See more

Removing support for connecting to GitHub Enterprise Server 3.1 from GitHub Mobile

GitHub Mobile can no longer connect to GitHub Enterprise Server 3.1. To enable connections from GitHub Mobile to GitHub Enterprise Server, a site administrator must upgrade to GitHub Enterprise Server 3.2 or later. Newer versions of GitHub Enterprise Server improve performance, enhance security, and provide new features. For more information, see "GitHub Enterprise Server releases" and "Upgrading GitHub Enterprise Server."

Read more about GitHub Mobile and send us your feedback to help us improve.

See more

help.github.com will now take you to GitHub Support

A month ago we shared an update about the help.github.com URL. Starting today help.github.com will start redirecting to GitHub's Support Portal at support.github.com
Users should continue to use docs.github.com to reach GitHub Docs.

Any links starting with 'help.github.com/' will continue to work as expected.

See more

Automatic Single Sign On for Enterprise Managed Users – Public Beta

Enterprise administrators can now choose to redirect signed-out Enterprise Managed Users to their company's single sign-on (SSO) page. This feature is available as a public beta.
By default, enterprises with Managed Users enabled are hidden, showing a 404 error page any time an enterprise resource is visited by a user that isn't already signed in to the enterprise.
If you enable this feature for your enterprise, visitors to resources in your enterprise, org, or user namespaces will immediately be presented with an SSO redirect if not already signed in to your enterprise.
This redirect helps users sign in to the correct account, rather than giving them the impression that the link they were given no longer works.

You can find this setting in the Authentication security section of your Enterprise Settings, below the single sign-on configuration sections.
image

Read more about this settings at "Automatic redirection for Enterprise Managed Users".

See more

Git commit author shown when squash merging a pull request

The author of the Git commit created when squash merging a pull request is now shown before merging. Previously, the commit author was only shown when merging with a merge commit.

image

Also, if the user merging the pull request also opened it and has multiple email addresses configured, a drop-down now lets them choose a different email address to use for the commit's author.

image

These improvements are designed to ensure Git commits created by squash merging are associated with the correct email address.

Learn more about merging a pull request.

See more

GitHub Sponsors: change notice for the ‘custom amount’ setting

In order to streamline sponsoring maintainers, we're changing the custom amount settings for GitHub Sponsors. Starting October 3rd, 2022, all Sponsors profiles will have custom amounts enabled by default.

  • On that date, if you haven't enabled custom amounts previously, we will set your minimum custom amount to either your lowest published monthly tier or your lowest published one-time tier, whichever is higher. If you wish to change the minimum, you can enable custom amounts on your Sponsors dashboard (if not already enabled), and then set it to your preferred minimum.
  • If you set a minimum custom amount before October 3, 2022, it will remain unchanged.

Custom sponsorship amount settings on the GitHub Sponsors dashboard for maintainers

See more

GitHub for iOS: Edit files in pull requests

Banner announcing edit files in pull requests feature for GitHub for iOS

Introducing “Edit File” within pull requests on GitHub for iOS! Make quick updates to existing pull requests to fix those pesky typos or add that missing method before merging.

File editing for pull requests within GitHub for Android is coming later this year.

See more

Merge commits now created using the merge-ort strategy

When GitHub creates merge commits, like to test whether a pull request can be merged cleanly or to actually merge a pull request, it now uses the merge-ort strategy. merge-ort is a relatively new Git merge strategy that is significantly faster (for example, complex merge commits that previously took 5 or more seconds to create are now created in less than 200 milliseconds) and addresses subtle correctness issues found in the merge-recursive strategy. And because merge-ort is the default merge strategy in the latest releases of Git, merge results are now more predictable and consistent between your local machine and GitHub.

Learn more about the Git merge-ort strategy and merge methods for pull requests.

See more

New Audit Log events and event context

GitHub's audit log allows admins to quickly review the actions performed by members of their Enterprise. It includes details such as who performed the action, what the action was, and when it was performed. To ensure the audit log can be used as an effective security and compliance tool, GitHub is constantly evaluating new audit log events and ensuring those events have the necessary fields to provide meaningful context. GitHub has made the following enhancements to the Enterprise audit logs:

  • business.sso_response and org.sso_response events will be displayed in the REST API and audit log streaming payloads for GitHub Enterprise Cloud (GHEC) and GitHub Enterprise Server (GHES) version 3.8 or later.
  • repo.rename, project.rename, and protected_branch.update_name events will now include the old_name field make clear the current and past name of renamed repos, projects, and protected branches.
See more

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
View more changes