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

Teachers we have heard your feedback! The GitHub Classroom team is excited to announce that now in addition to reusing a single assignment you can reuse multiple assignments across Classrooms and/or from semester-to-semester. You no longer have to manually and repeatedly create new assignments using the same template repo.

Using 'Reuse assignment' on the Classroom level you can copy single / multiple assignments and associated template repo across Classrooms and organizations. The copied assignment will include the Assignment details such as name, source repository, autograding and preferred editor.

AssignmentReuse

AssignmentReuse_modal

These changes will be gradually rolling out over the next week. For more information on how to use this new experience, check out our documentation. Your feedback is welcome at our Education Community Forum.

See more

The macOS 12 Actions runner image is now generally available. Start using GitHub Actions to build and publish apps for the Apple ecosystem with the latest version of Xcode by updating your jobs to include runs-on: macos-12

jobs:
  build:
    runs-on: macos-12
     steps:
      - uses: actions/checkout@v2
      - name: Build
        run: swift build
      - name: Run tests
        run: swift test

The macOS 12 Actions runner image has different tools and tool versions than macOS 11. See the full list of changed software.

If you spot any issues with your workflows when using the image, please let us know by creating an issue in the virtual-environments repository.

See more

Workflows triggered by workflow_dispatch and workflow_call can now access their inputs using the inputs context.

Previously workflow_dispatch inputs were in the event payload. This made it difficult for workflow authors who wanted to have one workflow that was both reusable and manually triggered. Now a workflow author can write a single workflow triggered by workflow_dispatch and workflow_call and use the inputs context to access the input values.

For workflows triggered by workflow_dispatch inputs are still available in the github.event.inputs context to maintain compatibility.

Using the inputs context in GitHub Actions

For questions, visit the GitHub Actions community

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

See more

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, we help protect users from data leaks and fraud associated with exposed data.

We have partnered with redirect.pizza, a domain redirection service, to scan for their API tokens and help secure our mutual users. Their API keys allow users to create, update, and delete redirects. We'll forward API tokens found in public repositories to redirect.pizza, who will notify the user by email and automatically revoke the token. More information about redirect.pizza’s API tokens can be found here.

GitHub Advanced Security customers can also scan for redirect.pizza API keys and block them from entering their private and public repositories via secret scanning’s push protection feature.

See more

When you visit the GitHub Advisory Database, you can now search for any historical advisory recognized by the National Vulnerability Database.

Previously, we only displayed advisories from our supported ecosystems. We then expanded to have an Unreviewed category for advisories that do not belong to those ecosystems, and we've been auto-publishing new advisories to this category since.

We've now backfilled our database to include all historical advisories from prior years, so you can find any advsiory you may be searching for regardless of publication date. This brings us to over 160 thousand advisories, and counting! You can browse them by clicking the "All unreviewed" button or by searching "type:unreviewed" in the search bar.
Unreviewed advisories backfilled

See more

GitHub Education now provides a safe place for students to take the first step in their open source journey with the launch of Community Exchange on GitHub Global Campus. Community Exchange offers students the ability to connect with peers to learn valuable skills to contribute to open source.

cx_screenshot

With Community Exchange, users can discover student created repositories and even submit a repository of their own. By submitting a repository a student can:

  • Get exposure for their repository by the nearly two million students on Global Campus
  • Build their portfolio by maintaining or contributing to repositories
  • Help other students learn
  • Grow their network

Community Exchange is available to all Global Campus students on their Global Campus dashboard. Students who haven't joined Global Campus can apply for GitHub Global Campus benefits.

To learn more about Community Exchange, check out our blog post.

See more

GitHub Advanced Security customers can now use sort and direction parameters in the GitHub REST API when retrieving secret scanning alerts. API users can sort based on the alert’s created or updated fields. The new parameters are available at the enterprise, organization, and repository level API endpoints.

Learn more about the secret scanning REST API
Learn more about private repository scanning with Advanced Security

See more

Organization owners and repository admins can now require developers to sign off on commits made through GitHub's web interface. Also, it is now easier for developers to complete a signoff in the web interface.

Note: Signing off on a commit is different than signing a commit, such as with a GPG key.

Background

The Git command line interface has a --signoff option that developers can use to sign off on their commits. Many open-source organizations require developers to sign off on their changes to affirm compliance with repository rules and licensing. Git's --signoff option appends a specially formatted line to the commit message, as shown here:

Signed-off-by: Mona Lisa <mona@github.com>

This text is what constitutes a signoff. It is often called a “DCO signoff” because the most common signoff agreement is the Developer Certificate of Origin (DCO) from the Linux Foundation.

Challenges

Open-source projects often use pull request checks to block commits from being merged unless they're signed off. Here’s an example of a commit being blocked in the open-source Gradle Profiler repository, which uses the Probot GitHub App to check whether all of a pull request's commits are signed off:

A pull request check that failed because a commit was not signed off

This problem is more likely when committing from GitHub's web interface where Git’s --signoff option isn't available. To sign off there, developers must manually add the Signed-off-by: text to their commit message. That's easy to overlook or misformat, resulting in the commit being blocked from merging. Resolving this situation can be complicated and slow developers down, as shown in these instructions to fix one commit:

Instructions for amending a commit that is not signed off

In the words of one open-source contributor:

🤦 As a pull request reviewer, this is my biggest pain point. If someone forgets to manually sign off on a commit in the web UI, the pull request check fails and the only resolution is to rebase or squash and force push to fix the commit message. Either way, the review history becomes unclear. This is high friction for new and infrequent contributors and people forget.

New signoff capabilities

Organization owners and repository admins can now require developers to sign off on commits made through GitHub's web interface, such as when editing a file or merging a pull request.

Also, it is now easier for developers to complete a signoff in the web interface, resulting in fewer commits being blocked from merging and less time spent resolving blocked commits.

How to enable required signoffs for an organization

Organization owners can configure an organization-level setting to require sign off on commits made through the web interface. To do so, click Settings in an organization that you are an owner of. Next, in the navigation under Code, planning, and automation, select Repository and then Repository defaults. Finally, under Commit signoff choose All repositories to require sign off on web-based commits in all repositories in the organization, as shown below. Alternatively, select No policy to disable the setting so that sign off will not be required unless enabled at the repository level.

GitHub's organization-level setting for requiring sign off on commits made in the web interface

How to enable required signoffs for a repository

Repository admins can toggle a similar repository-level setting. To do so, click Settings in a repository that you are an admin of. Next, select General (the default, top-most tab). Then toggle the setting named Require contributors to sign off on web-based commits as shown below. This setting will be overridden by the organization-level setting unless the organization has No policy selected.

GitHub's repository-level setting for requiring sign off on commits made in the web interface

When the setting is enabled, the web interface will inform developers that their action of committing will also constitute signing off, as shown below. Like using Git's --signoff option on the command line, signing off in the web interface will automatically append the Signed-off-by: text to the commit message.

GitHub's web interface for committing will inform developers that they are also signing off when they commit

Other information

Related to this feature, GitHub is planning a Git push policy setting that blocks commits from even entering a repository if they are not signed off. This will apply to commits made in GitHub's web interface or pushed from the Git command line or another Git client.

We appreciate feedback on this and other topics in GitHub's public feedback discussions.

See more

Custom repository roles are now GA for GitHub.com and Enterprise Server 3.5.

Organization admins can create custom repository roles available to all repositories in their organization. Roles can be configured from a set of 35 fine grained permissions covering discussions, issues, pull requests, repos, and security alerts. Once a role is created, repository admins can assign a custom role to any individual or team in their repository.

Custom repository roles can be managed in the Repository roles tab of your Organization settings:

image

Custom repository roles are also supported in the GitHub REST APIs. The Custom Roles API can be used to list all custom repository roles in an organization, and the existing APIs for granting repository access to individuals and teams support custom repository roles.

To get started with custom repository roles, read the docs.

See more

In February 2022, we launched a new feature called community contributions to security advisories.

We have made a handful of changes to the UX based on your feedback:

  • Fixed the breadcrumb on unreviewed advisories to more clearly display they are unreviewed.
  • Hid the link to submit a community contribution when it is not possible due to OSV constraints.
  • Added an information icon clarifying that not all ecosystems are supported.
  • Updated the auto-generated PR title to the format "[GHSA-####-####-####] Advisory Name" to be clearer on which advisory its for.
  • Fixed a bug that was adding unnecessary noise to the PR diff.
  • Added function to auto-post an affirming comment when a contribution is accepted.
  • Learn more about the GitHub Advisory Database
  • Learn more about GitHub community contributions
See more

The dependency graph now supports detecting Rust (Cargo.{toml,lock}) files. These will be displayed within the dependency graph section in the Insights tab. Users will receive Dependabot alerts and updates for vulnerabilities associated with their Rust dependencies. Package metadata, including mapping packages to repositories, will be added at a later date.

Learn more about the dependency graph.

See more

GitHub Enterprise Cloud owners now have the ability to opt-in to display enterprise members’ IP addresses for all
events involving enterprise-owned private repositories and enterprise-owned assets, such as issues and projects, in your
audit log.
This additional information can be used to improve threat analyses and
further secure your software.
Note, IP addresses will continue to not be displayed for activity related to public repositories.

For additional information, read about displaying IP addresses in the audit log for your enterprise.

See more

Dependabot version updates help you keep your dependencies up-to-date by opening pull requests automatically when new versions are available.

With this release, you can now more easily enable and configure Dependabot version updates from your repository’s settings page. Within the "Dependabot" section of the "Code security and analysis" tab, you can choose to enable Dependabot version updates, which will prompt you to create a dependabot.yml config file. If a dependabot.yml file exists, you can access that from the repository settings page.

Note: you still need to configure Dependabot version updates with a dependabot.yml file to enable it.

For more information, learn more about Dependabot version updates and how to configure a dependabot.yml file.

See more

Today's Changelog brings you the release of project webhooks, a first exploration into templates and a host of improvements to GitHub Issues.

☁️🪝 Automate more with project webhooks

The first release of webhooks for projects (beta) is now available for Organizations and GitHub Apps. 🤩

Once configured and enabled, webhooks will transmit events for any action taken on project items within your organization. This includes changes made (via projects) to status, assignee, labels, and even draft issue titles and descriptions!

You can find webhooks for projects (beta) in the "Webhooks" section of your organization settings page under the title Projects v2 Items. For more information, including technical specifications, check out the docs.

🦻 We're still developing webhooks, and we'd love to hear your feedback; drop us a line in our Feedback Discussion.

🎨 Get started with templates

When you create a new project, you now have the option of multiple templates to choose from. Start with either the default table or board, or explore one we've created for you with our team backlog or feature templates.

Stay tuned for more with templates in the future. 💖

Select a starting template

🧭 Improved navigation via project header

Quickly understand which organization or user a project belongs to and easily navigate via the breadcrumbs in the project header. We've got more to do here, so please let us know what you think.
Projects Compact Header

✨ Bug fixes & improvements

Other changes include:

  • Bug fix so projects (beta) insights retain URL parameters when switching to custom date ranges.
  • REST API, GraphQL API and webhook support for closed issue reasons.
  • The emoji menu on milestone creation now loads in the correct place.
  • Users trying to upload large files now receive the correct 'file too large' error, not a 'file type not supported' error.
  • Bug fix when converting a task list item to an issue, the ` character is now correctly formatted.
  • When transferring an issue between repositories, if no search results are found there is new UI to help you understand why some repositories are excluded.
  • Using the assignee filter menu on the issues index page, you now have the option to filter by the current user instantly, without having to wait for all possible assignees to load.

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

Code scanning flags up potential security vulnerabilities in pull requests — well before code is merged and deployed. Starting today, such alerts will be more visible: they will appear as a review on the pull request Conversation tab. As with any review, developers can then have a conversation about specific areas of the code that was changed.

And of course, from the code review by the GitHub code scanning bot, you can dive deeper into the alert: view the details, check the data flow paths, and dismiss an alert.

Code scanning alert

Code scanning and branch protection rules

Users were already able to configure code scanning as a required check in the branch protection settings in a repository.

With the new code scanning functionality, developers can start a conversation about code scanning alerts. Branch protection rules that require all conversations to be resolved before a PR can be merged apply equally to conversations about code scanning alerts: as soon as a code reviewer comments on a code scanning alert, the PR can not be merged until the conversation is marked as resolved. This helps ensure comments made on alerts are addressed prior to merging.

As you'd expect, when an alert is fixed, the conversation around the alert gets resolved and the PR can be merged.

PR merge blocked because of unresolved conversation

Learn more about GitHub Advanced Security and code scanning.

See more