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 is the engine that powers GitHub code scanning, used by more than 100,000 repositories to catch security vulnerabilities before they cause issues in deployments.

CodeQL is fully integrated into the Pull Request workflow, so it has to be as fast as possible to keep developers unblocked.

We're constantly working on performance improvements, from incremental optimizations to fundamental research, all with the goal of speeding up the nearly 150,000 checks we run every single day, without compromising our best-in-class precision and low false-positive rate.

With the recent release of CodeQL version 2.12, we looked back at the performance gains compared to version 2.11 (September 2022) to see how far we've come. We compared the analysis time for the same 55,000 repositories on GitHub.com and found an average improvement of 15.7% across all supported languages:

codeql performance 2 11 2 12 improvement

Users on GitHub.com automatically run the latest CodeQL version. Customers on GitHub Enterprise Server can update by following the sync processes explained here.

See more

The GitHub Enterprise Server 3.8 release candidate is here

GitHub Enterprise Server 3.8 brings new capabilities to help companies build and deliver secure software, more quickly. With over 100 new features, here are a few highlights:

  • Projects, the adaptable and flexible tool for planning and tracking work on GitHub, is now available on Enterprise Server as a public beta. A project is an adaptable spreadsheet that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively. You can create and customize multiple views by filtering, sorting, grouping your issues and pull requests, and adding custom fields to track metadata specific to your team. Rather than enforcing a specific methodology, a project provides flexible features you can customize to your team’s needs and processes.
  • GitHub Actions support organization-wide required workflows. You can define mandated workflows to run during the lifecycle of a repository’s pipeline. Individual development teams at the repository level will be able to see what required workflows have been applied to their repository, what actions that workflow performs, and whom to contact if they have questions.
  • Code scanning now supports Kotlin. We are launching a public beta for support of Kotlin. In this public beta Kotlin support will be enabled by default for all new code scanning users, and existing users that have already configured a Java analysis.
  • The Management Console now supports multiple users. Authentication in the management console is currently based on a single admin password. In version 3.8 we are introducing a multi-user concept with a user management interface to the Management Console which will allow admins to invite new users with different types of roles.

Release Candidates are a way for you to try the latest features at the earliest time, and they help us gather feedback early to ensure the release works in your environment. They should be tested on non-production environments. Here are some highlights for this release. Read more about the release candidate process.

Read more about GitHub Enterprise Server 3.8 in the release notes, or download the release candidate now. If you have any feedback or questions, please contact our Support team.

See more

Following feedback from code scanning users, we've moved documentation about the CodeQL CLI from codeql.github.com to docs.github.com, the main GitHub Docs site.

You can now find the articles under the “Using the CodeQL CLI” and “CodeQL CLI reference” categories, which correspond to the categories on the original site. We’ve updated each of the original articles on codeql.github.com with links to the new location of the article and to each subsection, so that if you go to the old location you can easily find the information you need.

The source files now exist in Markdown format in the public, open-source docs repository. If you would like to contribute, you can consult and follow the steps listed in the GitHub Docs contributing guide.

See more

What's new?

Starting today, anyone with repository write or maintain roles will be able to view and act on Dependabot alerts by default. Previously, only repository admins could view and act on Dependabot alerts. This change will help ensure that alerts are visible to the same developers responsible for fixing them.

How do I opt in?

No action needed–this change will be applied to all existing and new repositories starting today.

What's not changing?

This doesn’t affect custom roles, the Security Manager role, or organization permissions for Dependabot alerts. Only repository admins can enable or disable Dependabot alerts.

What about alert notifications?

This change also will not affect your alert notification or repository watching settings. So, if you aren’t opted in to Dependabot alert notifications based on your user settings, you won’t receive any.

If you are currently receiving notifications on alerts, any new repositories will be included with existing Dependabot alerts notifications.

Learn more about this change here.

See more

Code scanning can now be set up to never cause a pull request check failure.

By default, any code scanning alerts with a security-severity of critical or high will cause a pull request check failure.
You can specify which security-severity level for code scanning results should cause the code scanning check to fail, including None, by going to the Code security and Analysis tab in the repository settings.

Screenshot code-scanning-settings

This has shipped to GitHub.com and will be available in GitHub Enterprise Server 3.9. Learn more about severity levels for security alerts and Code scanning results check failures on pull requests.

See more

Maintainers of GitHub repositories can now use Category Forms to create templates for their Discussions, which means that users can start new discussions with all the necessary information already included. We hope this leads to less repetitive back and forth conversation with maintainers, as users are more likely to capture all relevant details in their first Discussion post.

Similar to Issue Forms, maintainers can create a discussion template, which will live in .github/DISCUSSION_TEMPLATE/. Each template will map 1:1 with the available Discussion Categories slugs. For example, the template for the “Announcements” category will be .github/DISCUSSION_TEMPLATE/announcements.yml. Once created, Category Forms in Discussions will be familiar to users who have seen them in issues:

Learn more about Category Forms
For questions or feedback, please visit our community.

See more

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Persona to scan for their API keys and help secure our mutual users on all public repositories and private repositories with GitHub Advanced Security. Persona API keys allow users to create, update, and interact with their identity-related data. GitHub will forward API keys found in public repositories to Persona, who will notify affected customers and work with them to rotate their API keys. You can read more information about Persona API keys here.

GitHub Advanced Security customers can also scan for Persona API keys and block them from entering their private and public repositories with push protection.

Learn more about secret scanning
Partner with GitHub on secret scanning

See more

Previously, GitHub Actions gets a GITHUB_TOKEN with both read/write permissions by default whenever Actions is enabled on a repository.
As a default, this is too permissive, so to improve security we would like to change the default going forward to a read-only token. You can still flip it to read/write if needed.

This change will not impact any existing enterprises, organizations or repositories. Here is how the defaults are set going forward.

  1. Enterprises: New enterprises will have read-only token.
  2. Organizations owned by Enterprise: New organizations will inherit the permissions from parent enterprise.
  3. Organizations not owned by Enterprise: New organizations will have read-only token.
  4. Repositories owned by organization: New repositories will inherit permissions from parent organization.
  5. Repositories owned by personal account: New repositories will have read-only token.
See more

GitHub Enterprise Cloud customers can now join a private beta which allows API request events to be streamed as part of their enterprise audit log.

In this private beta, REST API calls against enterprise private repositories can be streamed to one of GitHub's supported streaming endpoints. Further iterations on this feature are planned to expand the API events captured and make this data available via the audit log API.

Many GitHub users leverage GitHub's APIs to extend and customize their GitHub experience. However, use of APIs can create unique security and operational challenges for Enterprises.

With the introduction of targeted audit log streaming API requests, Enterprise owners are now able to:

  • Better understand and analyze API usage targeting their private repositories;
  • Identify and diagnose potentially misconfigured applications or integrations;
  • Troubleshoot API activity targeting private repositories that may be contributing to API rate limiting; and
  • Develop API specific anomaly detection algorithms to identify potentially malicious activity.

Enterprise owners interested in participating in the private beta should reach out to your GitHub account manager or contact our sales team to have this feature enabled for your enterprise. Once enabled, you should begin seeing API request events in your audit log stream. Feedback can be provided at our beta feedback community discussion post.

See more

We are making changes to job summaries and logs in GitHub Actions that will impact customers using self-hosted runners. Over the next six months, customers using self-hosted runners will need to ensure machines have appropriate network access to communicate with the GitHub hosts below so that job summaries and logs emitted from Actions workflows can work as expected.

  • actions-results-receiver-production.githubapp.com
  • productionresultssa*.blob.core.windows.net

After July 31, 2023, if you are using self-hosted runners and have not updated your network access settings to allow the aforementioned hosts, your job summaries and logs may not display correctly.

For more details see
Communication between self-hosted runners and GitHub.

For questions, visit the GitHub Actions community.

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

See more

In January 2022, GitHub announced audit log streaming to AWS is generally available. By streaming the audit log for your enterprise, enterprises benefit from:

  • Data exploration: Examine streamed events using your preferred tool for querying large quantities of data. The stream contains both audit and Git events across the entire enterprise account.
  • Data continuity: Pause the stream for up to seven days without losing any audit data.
  • Data retention: Keep your exported audit logs and Git events data as long as you need to.

To expand on this offering, enterprises streaming their audit log to AWS S3 now have the ability to use AWS CloudTrail Lake integration to automatically consolidate and ingest GitHub audit logs into AWS Cloud Trail Lake. AWS CloudTrail Lake is a managed security and audit data lake that allows organizations to aggregate, immutably store, and query events. By deploying this integration in your own AWS account, AWS CloudTrail Lake will capture and provide tools to analyze GitHub audit log events using SQL-based queries.

To learn more, read our documentation on integrating with AWS CloudTrail Lake.

See more

Today we are announcing the public beta of roadmaps in GitHub Projects! 🎉

Last November at GitHub Universe, we announced the private beta for roadmap. With your help and feedback over the last three months, we have shipped many exciting updates making it easier for you to visualize and plan your work over time, understand what is in progress or coming up next, and keep your team and stakeholders up to date.

image

🗺 Creating a roadmap

You can quickly build a roadmap alongside the same table and board views you already know and love.

When creating a roadmap, use existing date or iteration fields in your project to populate your items on the roadmap or create a new field from the Date fields menu. Set the zoom level to Month, Quarter, or Year depending on how granular you need your roadmap to be.

➕ Adding items and dates

Adding roadmap items works just like adding project items in any other view. Use the + Add item to search for or create a new issue, or type to create a draft placeholder. Once you’ve added the item, assign it to a specific date or within an iteration with a single click.

If plans change (which they often do!), you can adjust and move an item directly on the roadmap to reflect the new plan.

🎨 Customizing the view

Customizing your roadmap helps you create a tailored view for you and your teams. Select a group by field to segment and bucket your items by a custom field, such as status or team. This allows you to visually separate your items to understand both how they line up with each other and how long they all are expected to take.

Select a sort by field to further organize your roadmap, and specify a filter so that you only include relevant project items.

Tell us what you think!

We’ve got more improvements planned but we want to hear from you! Be sure to drop a note in the discussion and let us know how we can improve! Check out the documentation for more details.

If you would like to request access for the tasklists private beta to visualize the hierarchy of your items on the roadmap, sign up on the waitlist.

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

We are reverting this change for now. More details to follow.

The default compression for Git archives has recently changed. As result, archives downloaded from GitHub may have different checksums even though the contents are completely unchanged.&lt

GitHub doesn’t guarantee the stability of checksums for automatically generated archives. These are marked with the words “Source code (zip)” and “Source code (tar.gz)” on the Releases tab. If you need to rely on a consistent checksum, you may upload archives directly to GitHub Releases.
These are guaranteed not to change.

See more

GitHub Desktop 3.1.5 improves support for force pushing and fetching through the newly added Repository menu items as well as supporting pull request notifications on forks. This release also comes with many great contributions (12 changelog entries! ) from our open source contributors.

Force-pushing and Fetching

Previously, a user could only force push after an action such as rebasing. Now, when users find their branch in any diverged state, they can opt to use the force push Repository menu item. For example, a user can force push when commits exist on the remote that they are sure they want to overwrite.

ALT GitHub Desktop repository in a diverged state with Repository menu open showing force push menu item

Similarly, a user may find themselves in a new local branch they are not ready to publish, yet they want to fetch to see if there are any new changes on their main branch they would want to merge in. Instead of having to switch branches, they can use the Repository menu item to fetch those changes.

Notifications for Forks

If you have been enjoying our Pull Request notifications on your repositories, you will be happy to hear that with 3.1.5 those same notifications are supported on forks.

Open Source Contributions

We love the help we get from the open source community, providing many fixes and improvements for everyone to enjoy.

Thank you @angusdev for contributing all these fixes:

  • Hide window instead of hiding the app on macOS
  • The repository change indicator is visible if repository list item is selected and in focus
  • Tooltips are positioned properly if mouse is not moved
  • Tooltips of long commit author emails wrap to multiple lines
  • Clone repository progress bar no longer hidden by repository list
  • Close repository list after creating or adding repositories

Thank you @tsvetilian-ty for adding support for JetBrains Toolbox and JetBrains Fleet editor for Windows.

Thank you @zipperer for adding support for emacs editor.

Thank you @patinthehat for adding support for JetBrains PhpStorm and WebStorm editors

Thank you @daniel-ciaglia for adding support for VSCodium as an external editor.

Thank you @Shivareddy-Aluri for adding the ability to copy tag names from the commit list.

Thank you @j-f1 for improving the the diff view by adding highlighting to Arduino's .ino files as C++ source.

Learn more about GitHub Desktop here.

See more

This week, we’ve shipped a new experience for creating issues directly from Projects, improved sorting by custom fields across all layouts, and fixed a few bugs.

📝 Create issues in a snap with the new issue creation dialog

Create new issues quickly and easily by clicking the + icon on the omnibar and selecting Create new issue. Add labels, select a milestone, and assign to a teammate without ever leaving your project.

🗂 Sorting by field values on the board layout

Sort by field values on the board layout to easily organize your work items within your board columns. Select a sorting field from the view configuration menu to reorder items within each column, and move your items freely between columns while still maintaining the sorted order.

✅ Tasklists (Private Beta) improvements & bug fixes

Tasklists is currently in Private Beta but we’re letting folks in as fast as we can, join the waitlist!

We’ve recently shipped a major refactor to tasklists, so bear with us and help us by reporting problems you run into!

🐛Tasklists bug fixes

  • Fixed a bug where transferring Issues broke tasklists
  • Stopped inserting superfluous newlines around tasklists
  • Stopped showing duplicate labels on tasklists

✨ Tasklists enhancements

  • Edit history now reflects the changes made to the tasklists in Markdown
  • Tasklists preserve inserted Markdown instead of callously disposing of all “non-tasks”
  • Support for bold, italicize, strike text out, link and code formatting
  • Ability to @ mention people in tasks
See more

Organization admins and security managers can now enable private vulnerability reporting for all public repositories within an organization at once.

With this enhancement, you no longer have to enable the feature for each repository individually.

Find this option under your organization's "Settings" tab under "Code security and analysis".

Private vulnerability reporting

See more