Sitelet https://web.archive.org/web/20220620070825/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

Dependency graph has a REST API for submitting dependencies detected at build time

Dependency graph now supports submissions through the dependency submission API (beta). This enables you to add dependencies, such as those resolved when software is compiled or built, to the dependency graph. Submitted dependencies will appear in a repository's dependency graph and any associated vulnerabilities will trigger Dependabot alerts.

Releasing alongside the dependency submission API are the:

Learn more about the dependency sumbission API.

See more

Secret scanning: Dry runs for custom patterns on edits

GitHub Advanced Security customers can now perform dry runs of their custom patterns when editing a pattern. Dry runs allow admins to understand a pattern's impact across an organization and to hone the pattern before publishing and generating alerts.

Admins can compose a new pattern or edit a published pattern then 'Save and dry run' to retrieve results from their selected repositories. Scan results will appear on screen as they're detected, but admins can leave the page and later come back to their saved pattern's dry run results.

For more information:

See more

The new GitHub Issues – June 16th update

Today’s Changelog brings you tooling to migrate projects from the classic version to beta and accessibility improvements!

🚀 Migrate from Projects (classic) to Projects (beta) (feature preview)

We’ve made it easy for you to migrate your old project (classic) boards to the all new projects (beta) experience! Enable “project migration” in feature preview so that you can try out tables, multiple views, new automation options, and powerful field types with your exisiting projects. For more information, see “Exploring early access releases with feature preview.”

Migration

How it works:

  • We’ll create a copy of your existing project (classic) board in Projects (beta)
  • You’ll be prompted to close your our old project as the newly migrated project and old project will not be kept in sync
  • You can reopen your old project in a pinch if necessary!

💖 Accessibility Improvements

To provide a more accessible experience for all our users, we’ve made numerous fixes across key table and board workflows to better support users leveraging keyboard navigation, screenreaders, or high magnification. Some updates include:

  • Ensuring previously unreachable elements, such as suggestion lists and column headers, are reachable via keyboard navigation and appropriately handled by screenreaders
  • Updating tab behavior in table views to be consistent with common practices for spreadsheet-like tools
  • Improving the Add item workflow by updating the alignment and overflow behavior of the results list to be viewable at high magnifications

We’ve still got work to do but we’re excited to continue making projects better for all our users.

✨ Bug fixes & improvements

Other changes include:

  • Sorting by reactions on the issues index page now includes the number of reactions added
  • Updated naming conventions for assignee in header when grouped in table

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

Prebuilding codespaces is generally available

Today, we’re announcing that the ability to prebuild codespaces is entering general availability. A prebuilt codespace serves as a “ready-to-go” template where your source code, editor extensions, project dependencies, commands, and configurations have already been downloaded, installed, and applied so that new codespaces are available on-demand without any wait period. This helps significantly speed up codespace creations–especially for complex or large codebases.

With general availability, we've introduced a 'prebuild in progress' label in cases where a prebuild template creation is in progress to enable developers stay informed for when a given branch and machine type is ready for a fast codespace creation experience. Administrators now have more control on how often prebuild configurations are updated to manage Actions usage. They can also configure retention settings on prebuild templates to manage underlying storage costs. Additionally, with failure notifications, repository administrators can specify a set of individuals or teams to be informed via email in case a prebuild-associated workflow fails to help with efficient monitoring. Administrators can also temporarily pause a prebuild workflow run while fixing an underlying issue.

With general availability, organizations will be billed for Actions minutes required to run prebuild associated workflows and storage of templates associated with each prebuild configuration for a given repository and region. As an administrator, you can download the usage report for your organization to get a detailed view of prebuild associated Actions and storage costs for your organization-owned repositories.

Prebuilt codespaces are generally available for all GitHub Enterprise Cloud and Team organizations. Repository admins can head over to their repository’s settings page and create prebuild configurations under the Codespaces tab. Once set up, you can take advantage of fast codespace creation by selecting machine types with the ‘prebuild ready’ tag.

Check out the prebuilds documentation to get started!

See more

Advisory Database supports malware advisories

GitHub's Advisory Database now supports listing malware advisories. You can see them by searching "type:malware" on https://github.com/advisories.

If you have enabled Dependabot alerts on your repositories, GitHub will send Dependabot alerts for malware automatically. Note that Dependabot does not send update pull requests for malware as the only resolution is to delete the package and find an alternative.

See more

Block potentially destructive Git pushes

This beta feature allows repository admins to block Git pushes to a repository when they are potentially destructive.

Developers have had branches deleted from their repository when someone pushes changes with Git's --mirror option. The --mirror option is potentially destructive because it makes the remote repository exactly match the local clone. When run by accident, if the remote has more branches or different data than the local clone, many branch deletes and force-pushes can happen at the remote without any warning. This is often embarrassing for the one who pushed and a big challenge to recover from. Here's a real-world example: git push origin –mirror deleted all of my colleagues' branches.

This destructive situation can usually be identified by multiple branch or tag updates being pushed at the same time. The new beta feature being announced here allows admins to block potentially destructive pushes by limiting the number of branches and tags that can be updated by a single push. This can prevent or limit the loss of data.

To use this beta feature, click Settings in a repository that you are an admin of. Next, select General (the default, top-most tab). Then toggle the setting named Limit how many branches and tags can be updated in a single push as shown below. Set the number appropriately for your needs. We recommend the default maximum of 5 branch or tag updates allowed in one push. The minimum value is 2 since two branch updates are required by Git to rename a branch in a single push: delete branch and create branch. Lower numbers are more restrictive of which pushes are allowed, and higher numbers are less restrictive but have more potential for being destructive. As part of this feature's beta, we'd like to learn which number works best for you.

Image showing the setting labeled "Limit how many branches and tags can be updated in a single push."

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

See more

Configure dependency review for vulnerability severity and license type

The Dependency Review GitHub Action, which checks if pull requests introduce a dependency with a known vulnerability, now supports configuration based on vulnerability severity and license type.

The following configuration options are available:

  • fail-on-severity: the action will fail on any pull requests that introduce vulnerabilities of the specified severity level or higher
  • allow-licenses: the action will fail on pull requests that introduce dependencies with licenses that do not match the list
  • deny-licenses: the action will fail on pull requests that introduce dependencies with licenses that match the list

The action is available for all public repositories, as well as private repositories that have Github Advanced Security licensed.

Learn more about dependency review enforcement.
Learn more about configuring the Dependency Review GitHub Action.

See more

Updates to GitHub Feed (Public Beta)

Back in March, we introduced a new "For you" feed in Public Beta, to help you discover interesting projects across GitHub. Today, we are sharing a few updates to this beta.

  • Users can now filter the feed based on content types: for instance, someone might only want to see announcements and releases on their feed, while another person might want to see everything but releases.
    image
  • Similar events are now grouped (rolled up). For instance, if a person is starring multiple repositories, the feed will display a group of "starred" activities.
    image
  • Feed contents are now paginated.
  • Merged Pull Requests in public repositories will now also be displayed on the feed.

For questions or feedback, visit the GitHub Feed feedback.

See more

Translations for Discussions

Translations are now available for discussion comments in Spanish, Portuguese, Korean, and English. If your first preference browser language is different from the language of the discussion comment, you will now see an option to translate the comment's contents.

Discussion comment in Spanish being translated to English and back again

This feature is in beta and we'd love your feedback. Leave us a note here and let us know what you think.

See more

Multiple assignment reuse for GitHub Classroom

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

GitHub Actions: macOS 12 for GitHub-hosted runners is now generally available

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

GitHub Actions: Inputs unified across manual and reusable workflows

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

redirect.pizza is now a GitHub secret scanning partner

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

All historical NVD advisories are now listed on GitHub

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