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

On June 15th, we announced GitHub added malware advisories to the GitHub Advisory Database and will send malware alerts through Dependabot. Since shipping this change, we have received feedback that some organizations have been impacted with Dependabot alerts from these malware advisories that may be false positives.

GitHub has conducted a rapid root cause investigation and found that the majority of those alerts in question were for substitution attacks. During these types of incidents, an attacker would publish a package to the public registry with the same name as a dependency users rely on from a third party or private registry, in the hope a malicious version would be consumed. Dependabot doesn’t look at project configuration to determine if the packages are coming from a private registry, so it has been triggering an alert for packages with the same name from the public npm registry. While this does mean that your package was the target of a substitution attack it does not mean that there is an immediate action to be taken on your part as the malware has already been removed from the npm registry.

While we work to determine how to best notify customers of being the target of a substitution attack, we will be pausing all Dependabot notifications on malware advisories. For non-Enterprise-Server users, Malware advisories will still exist in the Advisory Database and send alerts on npm audit. We are not making any changes to existing alerts on github.com at this time.

For GitHub Enterprise Server users, who were the most impacted, no new advisories will come through GitHub Connect. If you are struggling with too many alerts, please reach out to support and we can share a script for you to run that will delete all malware advisories and alerts.

See more

Previously, when creating an autolink reference for a repository, you could only use a numeric identifier in the <num> parameter. This format didn't support integration with platforms that use alphanumeric identifiers, like the last segment of this Trello card URL: https://trello.com/c/3eZr2Bxw. Now you can create an autolink with an alphanumeric identifier.

Any previously created autolinks will continue to support only numeric identifiers so that they continue working as before. Only newly created autolinks will support alphanumeric identifiers.

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

Changelog_Issues_Jun30_Cover

📊 Expanding access to charts for all plans

We are expanding our Insights capabilities to all plans! Charts help you visualize and track cycle velocity, current work status, and complex visualizations like Cumulative Flow Diagrams.

Starting today, all projects (beta) users can access custom current charts! Head over to the Insights tab for your projects to try it out and don't forget to share feedback!

We're also expanding access to time-based charts to allow organizations to visualize trends over time. Time-based charts are enabled for all Enterprise Cloud organizations and existing Team organizations with at least one project. Team organizations that have not used projects (beta) will be onboarded over the next couple of weeks.

Thank you for all of your feedback during the alpha and we hope you'll continue to share your thoughts with us on Discussions.

✨ Bug fixes & improvements

Other changes include:

  • File uploads now support both .webm and .tgz file types.
  • Unsaved view changes are persisted across page refreshes.

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

When using the GraphQL API, you can now filter Dependabot alerts by the scope of the dependency affected. The possible scopes are DEVELOPMENT or RUNTIME.

Dependency scope information is available for alerts opened on or after June 23, 2022, and can also be viewed in the Dependabot alerts UI as of last week.

For more information, see Dependabot alerts in the GraphQL API reference or learn more about Dependabot alerts in our documentation.

See more

A dropdown has been added to the Fork button to help you quickly find your forks of a repository. This includes forks in your personal account and in organizations that you're a member of.

Example of the "your existing forks" dropdown

This feature was inspired by Refined GitHub – an impressive open source project maintained by @fregante. The feature was requested of GitHub through the GitHub Stars program.

Read more about forking a repository in the GitHub documentation.

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

See more

GitHub is transitioning map rendering services from MapBox to Azure Maps in our Free, Pro, and Team plans. This includes maps embedded in the site file viewer, embedded maps, and maps rendered in markdown. As part of the transition, custom icons and formatting of features in geojson and topojson files will no longer be supported. This change will not impact our Enterprise Cloud instances which will continue to use MapBox for map rendering. Documentation can be found here: https://docs.github.com/en/repositories/working-with-files/using-files/working-with-non-code-files#geometry-types

See more

GitHub Enterprise Cloud customers can elect to participate in a private beta to configure audit log streaming to AWS S3 with OpenID Connect (OIDC). Audit log streaming configured with OIDC eliminates storage of long-lived cloud secrets on GitHub by using short-lived tokens exchanged via REST/JSON message flows for authentication.

If interested in participating in the private beta, please reach out to your GitHub account manager or contact our sales team to make the feature available for your enterprise. For additional information on configuring OIDC, read about setting up audit log streaming to AWS S3 with OpenID Connect.

See more

Previously, three aspects of repository forks caused friction to innersource collaboration and administration:

  1. Repositories could not be forked within a single organization.
  2. Repositories with internal visibility could not be forked to an organization.
  3. Enterprise owners lacked control over where repositories could be forked.

These obstacles have been addressed with the following new features. We’re always looking for new ways to improve repository collaboration and we welcome your ideas.

Fork a repository to the same organization as its parent

Previously, a repository could be forked only to a different organization or user account.

Now, a repository can be forked to the same organization as its parent repository, addressing situations where people are working in one organization and don’t want to fork a repository to a different organization or user account.

Fork internal repositories to enterprise organizations

Previously, when a repository with internal visibility was forked, the fork was automatically created in the person’s personal account space and its visibility was changed to private.

Now, people can fork an internal repository to an organization in the same enterprise, and the fork will retain its internal visibility. When forking an internal repository, you can choose which of the enterprise’s organizations should receive the fork – similar to forking a public repository, except that:

  1. The destination organizations will be limited to those within the enterprise of the parent repository.
  2. You will not be permitted to change the internal visibility of the fork while forking it.

Enterprise owners can limit where forks can be created

Previously, enterprise owners couldn’t restrict where repositories in the enterprise could be forked. This was important for them to keep confidential repositories from accidentally being forked to an exposed location.

Now, enterprise owners can control where enterprise members can fork repositories. Forking can be limited to preset combinations of enterprise organizations, the same organization as the parent repository, user accounts, and everywhere.

Image of enterprise settings for controlling where repositories can be forked

More information

Learn more about working with forks, or enforcing a policy for forking repositories, in the GitHub documentation.

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

See more

The GitHub Advisory Database now includes curated security advisories on Erlang [Hex], Elixir, and more. This brings the Advisory Database to nine supported ecosystems, including: Composer, Go, Maven, npm, NuGet, pip, RubyGems and Rust.

Support for this ecosystem in the dependency graph and Dependabot alerts will be available in the future.

See more

You can now get more transparency and control over dependency caching in your actions workflows.

Actions users who use actions/cache to make jobs faster on GitHub Actions can now use our cache list and delete APIs to:

  • list all the Actions caches within a repository and sort by specific metadata like cache size, creation time or last accessed time.
  • delete a corrupt or a stale cache entry by providing the cache key or ID.

Learn more about Managing caching dependencies to speed up workflows.

See more

Today, we’re releasing capabilities that will enable developers and organizations to efficiently manage and confidently scale with Codespaces.

Retention setting for all individuals

To enable auto-cleanup of unused codespaces, inactive codespaces will now be automatically deleted if they have been unused after a period of 30 days. The retention period applies to all individual users on GitHub.com that are using Codespaces and can be adjusted to a maximum value of 30 days. With that, developers no longer need to remember to manually clean up old instances of dev environments that may be unintentionally generating additional costs. The retention counter for inactive codespaces can be reset by connecting to the instance. Additionally, developers will be notified via email and in-product messaging to help them stay informed about the auto-deletion.

Retention policy for organization administrators

Organization admins will also be able to set an organization-level retention constraint for their organization’s codespaces. The organization retention policy will override the individual default retention setting for organization-owned codespaces. With this, admins no longer need to remind individual teams to clean up stale codespaces thus minimizing wasteful resources and saving money for their organization.

We are also introducing support for organization level APIs and CLI commands in public beta so that admins can programmatically manage their organization-owned codespaces at scale. With this beta, organization admins can use the following REST API and CLI commands:

API

  • List all codespaces within your organization.
  • Get information on a specific codespace within your organization.
  • Stop, or delete codespaces within your organization.

CLI

  • List all codespaces within your organization.
  • Stop codespaces within your organization.
  • Delete codespaces within your organization.

Additionally, developers can also manage their own codespaces via APIs listed in our documentation that are generally available. With these APIs, you can perform CRUD (Create, Read, Update, and Delete) operations, view available machine types, and manage user-level and repository-level secrets for your codespaces seamlessly.

Get Started

The default 30 day retention setting will be applied to all new codespaces going forward across GitHub Free, Team and Enterprise Cloud plans. The max retention policy constraint is generally available and organization APIs are in beta for GitHub Team and Enterprise Cloud plans.
Here are links to our documentation to get started:

If you have any feedback to help improve this experience, be sure to post it on our discussions forum.

See more

The GitHub Sponsors Explore page, which lists your sponsorable dependencies, has been updated with improved functionality. See how many of your or your organization's dependencies come from a single maintainer, how close the maintainers are to their funding goals, group by multiple ecosystems, find maintainers who accept one-time payments and more.

See more

Pull Requests will now load more quickly thanks to deferred syntax highlighting.

When you first land on a Pull Request’s Conversation or Files tab we will show plain text diffs, and then swap in the syntax highlighted versions as soon as they are ready.

See more

This marks 1️⃣ year since our initial private beta announcement! 🎉

Today's Changelog brings you the ability to bulk add items to projects and GraphQL API improvements!

🪷 Bulk add items

To make it even easier to add your issues and pull requests to a project, we have now added a new way to bulk add issues to your projects.

  • Hit the + button by the omnibar.
  • Select Add item from repository.
  • Pick your repository and get adding.

2022-06-22 19-30-46 2022-06-22 20_02_27

🤖 GraphQL API improvements

The projects GraphQL API is now generally available 🎉. With this update, we are announcing:

1) The introduction of new ProjectV2 object and mutations.
2) The deprecation of ProjectNext object and mutations, scheduled for 1st October 2022.

What are the new changes?

We have added a new ProjectV2 object to our GraphQL API to programmatically access a project.

The fields of the project are now available as:

The items of the project are represented by the ProjectV2Item object. It contains a field type to identify the item type – Issue, Pull Request, Draft Issue or Redacted. The values of the item are available under the fieldValues field.

We are also adding the following mutations for updating a project:

Based on feedback that more granular scopes would be useful, we have introduced new OAuth scopes specifically for this update:

  • The read:project scope provides query access to ProjectV2 objects.
  • The project scope provides query access to ProjectV2 objects and access to mutations.

✨ Bug fixes & improvements

Other changes include:

  • Bug fix where @mentions didn't include all users when editing a comment.
  • Ability to open the issues side-panel using the spacebar.
  • Long project titles no longer truncate when there is room to display the full title.
  • Bug fix to resolve a flash that occurs when creating or editing a project view title.

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

Today, we're shipping a new filter for the Dependabot alerts list view. In the alerts list view, you can now filter for scope:development or scope:runtime. Alerts for development dependencies also feature a label in the UI.

Dependency scope information will be available for alerts opened on or after June 23, 2022.

Which ecosystems are supported?

The following ecosystems are supported as of June 23, 2022:

Language Ecosystem Dependency Scope
Ruby RubyGems
JavaScript npm
JavaScript Yarn No, defaults to runtime
PHP Composer
Go Go modules No, defaults to runtime
Java Maven test maps to development, all else default to runtime
Python Poetry
Python pip ✅ for pipfile, for requirements.txt scope is development if the filename contains “test” or “dev”, else it is runtime
.NET NuGet ✅ only for .nuspec when tag != runtime; for all other cases defaults to runtime
Rust Cargo

For more information, learn more about Dependabot alerts in our documentation.

See more

GitHub Advanced Security customers can now use cursors to paginate over alert results they retrieve via the repository and organization level REST APIs.

Paginating with cursors, using the new before and after query parameters, can help assure data consistency and improve response times. To receive an initial cursor on your first request, include an empty "before" or "after" query string in your API call.

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

See more

GitHub Advanced Security customers can now see an overview of code scanning alerts at the enterprise level. This page provides a repo-centric view of application security risks, as well as an alert-centric view of all secret scanning, Dependabot and now code scanning alerts. This view is beta and will be followed in the coming weeks with an enterprise level REST API to retrieve code scanning alerts.

Code scanning alerts at the enterprise level

Learn more about security overview
Learn more about GitHub Advanced Security

See more

Today, we’re officially releasing GitHub Copilot, an AI pair programmer that suggests code in your editor, to all developers for $10 USD/month or $100 USD/year.

To show our appreciation to the Open Source and Learning communities, it will also be free to use for verified students and maintainers for popular open source project on GitHub.

Also thanks to users who are already in the technical preview program. You can continue enjoy free access until August 22nd.

Learn more in the GitHub CEO’s blog

See more