You can now use the REST API to open a private vulnerability report on open-source repositories that have this feature enabled.
Learn more about the repository security advisories REST API
You can now use the REST API to open a private vulnerability report on open-source repositories that have this feature enabled.
Learn more about the repository security advisories REST API
On March 30, 2023, we fixed a bug that allowed a dependency graph hovercard URL to be used to retrieve the name, description, and star count of any repository on GitHub.com. The bug was introduced on March 28, 2023 and our investigation has found no evidence of exploitation. To exploit the bug, a specific header needed to be set when making a request to the URL and the numeric ID of a repository provided. The URL would then return the HTML content designed to be used for a hovercard UI element with the repository name, description, and star count in the response.
This bug was reported to GitHub via the GitHub Bug Bounty program.
Since the introduction of Category Sections to organize content in our own community, users have asked for similar features to organize their own Discussions. Today, we're introducing the ability for all maintainers to group their Discussion categories into sections. We think this will help users better organize content, and also find new content more easily.
The UI for this feature looks similar to the one in our own community, but users will now see a new UI when they edit a category. Users can not only create a new Category, but they can also create a new section from the "Manage Discussion Categories" page.
Editing a single category now also gives the user the option of adding it to an existing section.
For questions or feedback, please visit our community.
Available in public beta today, the security coverage page now includes multi-repository enablement, which lets you enable or disable security features across several repositories at once. This feature improves upon the "enable all" feature that only allows you to enable one security feature at a time for all repositories within the organization.
Multi-repository enablement also allows you to filter repositories based on attributes such as team or repository topic, and to enable or disable security features for only those repositories in just a few clicks.
The following security features can be enabled/disabled using multi-repository enablement:
These improvements have shipped as a public beta to GitHub.com and will be available in GitHub Enterprise Server 3.10.
Learn more about multi-repository enablement and send us your feedback
Learn more about GitHub Advanced Security
Today we are announcing the public beta of repository rules! 🎉
Repository rules are GitHub's next evolution of branch protections to help make your repositories more secure and compliant at scale.
Rules allow you to easily define protections for branches and tags in your repositories and, if you are a GitHub Enterprise Cloud customer, to enforce them across your organization. It is also easier for everyone collaborating on your repositories to know what rules are in place.
At the core of rules is the ability to define rulesets. A ruleset is a collection of rules that are enforced together. For example, you could require that all commits to a branch are signed and that those commits have two reviewers. Rulesets can also be applied to tags, allowing you to enforce rules on releases.
The ruleset page is the central place to view and manage all the rules for a repository. It shows the rules that are currently in place and allows you to add new rulesets or edit existing ones.
When creating a ruleset, you define its enforcement status as active or disabled. Active rulesets must pass for a commit to be merged, while disabled rulesets are not enforced; they will not prevent merges but allow admins to craft rules before enforcing them.Enterprise Cloud customers can also evaluate rulesets: a "dry run" mode for understanding the impact of new rules before they are active and enforced.
It's also easier to target branches and tags in rulesets, with options to select the default branch, all branches, and branches or tags that match an fnmatch pattern. You can add multiple patterns to a ruleset to apply it to different branch and tag naming styles.
You can always know what rules are in place for a repository.
Anyone with read access to a repository can view its rules and what they mean. The rulesets overview is linked from the branches page by clicking the shield icon, and from a pull request, and from the output of the Git CLI when rules block a push.
From here, you can filter rules by branches or tags to understand how a rule might be enforced on your next push.
Repository rules are now available to all GitHub cloud customers. To get started, visit the documentation to learn how to enable and use rules. For Enterprise Cloud customers, visit the documentation to learn about organization rulesets and more.
We want to hear from you on how we can improve repository rules! Join the conversation in the repository rules public beta discussion.
When we introduced GitHub Discussions in 2020, we allowed users to mark an answer to a question in the "Q&A" Discussions category. As the feature began getting more usage, we noticed that often, the real answer to a question may live in a reply to an answer. Today, we are introducing the ability for users to mark a threaded reply as the answer to a question.
All replies will now have a button to allow the questioner to mark them as the answer.
Marking the reply as the answer highlights it and makes it clear to the reader where the real answer to the original question lives.
This feature improves the accuracy of marked answers, while also reducing the burden on users to duplicate their text to get their answer marked as correct.
For questions or feedback, please visit our community.
GitHub Importer allows you to import repositories from other code hosting platforms to GitHub.com using a UI or REST API.
Today, GitHub Importer supports Git, Mercurial, Subversion and Team Foundation Version Control (TFVC) repositories.
From October 17, 2023, we will no longer support importing Mercurial, Subversion and Team Foundation Version Control (TFVC) repositories. We're ending support for this functionality due to extremely low levels of usage.
Even without GitHub Importer, moving from these alternative version control systems to Git is simple thanks to fantastic open source tools – for more details, read our Docs article, "Using the command line to import source code".
When changes in a repository make a Dependabot pull request out-of-date, Dependabot will automatically rebase it so that it is able to be merged without your manual effort. With this release, if a PR has not been merged for 30 days, Dependabot will stop rebasing it and will include a note about this in the PR body. You will still be able to manually rebase and merge the pull request. We've heard your feedback about Dependabot noisiness and are making Dependabot quieter and more focused on repositories you care about. For enterprise customers, this improvement has the added benefit of enhanced efficiency with your self-hosted GitHub Actions runners. For Enterprise Server customers, this update will be available to you in GHES 3.10.
You can now filter by repository topic or team on the enterprise-level Dependabot, code scanning, and secret scanning pages in security overview.
These improvements have shipped to GitHub.com and will be available in GitHub Enterprise Server 3.9.
Learn more security overview and send us your feedback
Learn more about GitHub Advanced Security
You can now fetch release notes, changelogs and commit history for Docker update pull requests with Dependabot. This will allow you to quickly evaluate the stability risk of the dependency upgrade. To enable support, add the org.opencontainers.image.source label to the Dockerfile with the URL of the source repository. Additionally, the repository should be tagged with the same tags as the published Docker images. This allows Dependabot to understand which repo and commit is associated each version/tag of a Docker image. Here's an example repository demonstrating this setup.
Did you know? Dependabot's internal library for identifying dependency updates is open source. If you notice a Dependabot pull request is missing metadata, you can leverage the transparency of open source to debug the root cause – for example, if the package maintainer needs to fix their metadata annotation.
GitHub Advanced Security customers using secret scanning can now view any secrets exposed historically in an issue's title, description, or comments within the UI or the REST API. This expanded coverage will also detect and surface secrets matching any custom pattern defined at the repository, organization, or enterprise levels.
Following our recent release of generating a software bill of materials from the repository's dependency graph, you can now generate an SBOM for a repository using a new REST API for SBOMs. The resulting JSON will represent the head of the repository's main branch.
Following a successful beta with lots of great customer feedback, webhook forwarding in the GitHub CLI is now available to everyone.
Webhook forwarding makes it easy to test your webhooks integration in your local environment without having to worry about port forwarding.
All it takes to start receiving webhooks locally is one simple command:
gh webhook forward --repo monalisa/hello-world --events issues,pull_request --url http://localhost:4000/webhooksTo learn more, head over to "Receiving webhooks with the GitHub CLI" in the docs.
Code scanning default setup is now available for Go!
Default setup automatically finds and sets up the best CodeQL configuration for your repository. It detects the languages in the repository and enables CodeQL analysis for every pull request and every push to the default branch and any protected branches. A repository is eligible for default setup if it uses GitHub Actions and contains JavaScript/TypeScript, Python, Ruby or Go.
You can use default setup on your repository's "Settings" tab under "Code security and analysis".
This new feature is available on GitHub.com today, and will also ship with GHES 3.10. More language support will be provided soon, and all other CodeQL-supported languages continue to work using a GitHub Actions workflow file. The options to set up code scanning using API uploads or third party analysis tools remain supported and are unchanged.
For more information on code scanning default setup, see Configuring code scanning automatically.
Users with access to secret scanning alerts can now view metadata for any active GitHub token leaked in their repositories. Metadata includes details like the token's owner, expiration date, and access permissions. With this information, security teams can assess a leak's potential impact and prioritize remedial action accordingly.
This feature builds on our previous release in January, which introduced validity checks for leaked GitHub tokens.
After recently adding the archive date of repositories to the GitHub UI, the timestamp is now also available in GraphQL API responses.
Users can now query the archivedAt timestamp of when a repository was archived using the GitHub GraphQL API.
Commenting on files (including deleted, binary, and renamed files) in a pull request is now generally available on the web and GitHub Mobile! A special thank you to everyone that provided feedback during the public beta.
API support is also now available. See create a review comment (REST API) or addPullRequestReviewThread (GraphQL mutation) for more details on commenting on files. A new "subject type" field is also now returned by other APIs indicating whether a comment is on a line or file.
Learn more about commenting on a pull request.
Caching dependencies and other commonly reused files enables developers to speed up their GitHub Actions workflows and make them more efficient.
We have now enabled Cache Management from the web interface to enable developers to get more transparency and control over their cache usage within their GitHub repositories.
Actions users who use actions/cache can now:
In addition to the Cache Management UX that we have now enabled, you could also use our Cache APIs or install the GitHub CLI extension for Actions cache to manage your caches from your terminal.
Learn more about dependency caching to speed up your Actions workflows.
For questions or to share your feedback, visit the GitHub Actions community.
Team Maintainers may now disable notifications resulting from a team @mention in GitHub issue and pull request comments through an optional configuration in the team settings page. Notifications resulting from PR review requests are unaffected by this setting. Existing issue and PR subscriptions are also unaffected. This team setting will also be exposed via API.
For more information, see the teams documentation.
Today's Changelog brings you bulk editing in the table layout and improvements to tasklists!
You can now update multiple cells in a column at once!
Update a range of cells in any column by dragging the small blue rectangle in the bottom right of any cell up or down. You can also use keyboard commands to paste values into multiple cells at the same time.
Command+C (Mac) or Ctrl+C (Windows) Shift and clicking a different cell in the column or select non-neighboring cells by clicking a cell and selecting multiple cells while holding down Command (Mac) or Ctrl (Windows) Command+V (Mac) or Ctrl+V (Windows) The hierarchy team has been hard at work improving tasklist performance on issues and in the Projects sidepanel speeding up editing and control of tasks by 2x! We call this class of improvements "lockless editing" and we're working on baking this approach into all tasklist operations in the future.
We've also improved the speed of tasklists updates reflecting in your projects. Changes to the Tracked by and Tracks columns, which could previously take minutes are now reflected in real-time. 🎉
Tracked byTracked by issue is closed as not plannedTracked by filter suggestion so users can now read the entire issue title without truncation Tracked By in your project, items added will now show up in the last tasklist of the issue you are filtering byTracked by search menu in the project filter Tracked byTracks column was stuck in a loading stateTracked by pill in the project item side-panelRepository field pill to board items when toggling it from the Fields menuSee how to use GitHub for project planning with GitHub Issues, check out what's on the roadmap, and learn more in the docs.