The GPG key used to verify GitHub CLI Debian and RedHat packages expired on Friday, September 6. If you have installed gh via our official package repositories, we ask that you update your keyring to the new key to continue verifying GitHub CLI releases.
Please refer to this documentation for instructions on how to do so with your respective package manager.
For reference, a note on this was also included in the CLI v2.56.0 release notes, published earlier this week.
We’re excited to announce that GitHub is partnering with ORCID. You can now authenticate your ORCID account with your GitHub account, and display your ORCID iD on your public GitHub profile. ORCID provides a persistent unique digital identifier (an ORCID iD) that researchers own and control, and that distinguishes them from every other researcher.
Go to https://github.com/settings/profile to authenticate your ORCID iD.
On December 14, 2023, GitHub Actions released v4 of the actions to upload and download artifacts. This version improves upload/download speeds by up to 98%, addresses long-standing customer feedback requests, and represents the future of artifacts in GitHub Actions.
With the introduction of v4, we will be deprecating v1 and v2 of actions/upload-artifact, actions/download-artifact, and related npm packages on June 30, 2024. We strongly encourage customers to update their workflows to begin using v4 of the artifact actions.
In order to prevent issues for customers using GitHub Connect, the tags for v1 through v2 will not be removed from the actions/upload-artifact and actions/download-artifact project repositories. However, attempting to use a version of the actions after the announced deprecation date will result in a workflow failure. This deprecation will not impact any existing versions of GitHub Enterprise Server being used by customers.
This announcement will also be added to actions/upload-artifact and actions/download-artifact. Please visit the documentation to learn more about storing workflow data as artifacts in Actions.
We listened to your feedback and released new versions (v4) of actions/upload-artifact and actions/download-artifact. While this version of the artifact actions includes up to 10x performance improvements and several new features, there are also key differences from previous versions that may require updates to your workflows.
v4 is not cross-compatible with previous versions. For example, an artifact uploaded using v3 cannot be used with actions/download-artifact@v4.upload-artifact@v4 ensures artifacts are immutable, improving performance and protecting objects from corruption, which would often happen with concurrent uploads. Artifacts should be uploaded separately and then downloaded into a single directory using the two new inputs, pattern and merge-multiple, available in download-artifact@v4. These objects can then be re-uploaded as a single artifact.Customers will still be able to use v1 – v3 of the artifact actions. If you wish to upgrade your workflow to use v4, please carefully consider the impact the aforementioned major version changes will have on your project and any downstream dependencies.
Artifacts v4 is only available to GitHub.com customers today but we will be extending support to GitHub Enterprise Server (GHES) customers in the future.
To learn more about what is included in v4, visit the actions/upload-artifact and actions/download-artifact repositories.
We’ve released the following improvements to your homepage feed.
2. You will now see cards for when someone has forked one of your repositories. 
We’ve added a new category to the GitHub Docs, “Contributing to GitHub Docs”, filled with resources used by the GitHub Docs team, the rest of the company, and the open source community to create documentation. The articles in this category explain the processes behind producing documentation, how GitHub approaches docs, and how to write docs according to GitHub’s style and content guidelines. If you’ve ever wanted to know the processes behind producing documentation or you’re about to begin documenting your own project and want to base your processes on our approach, you can now find that information in GitHub Docs.
GitHub Docs is an open source project that everyone is welcome to contribute to. To contribute, head to our github/docs repository and browse the open issues with the “help wanted” label.
September 12, 2023 update:
When we launched the latest version of your feed on September 6, 2023, we made changes to the underlying technology of the feed in order to improve overall platform performance. As a result, we removed the functionality for “push events for repositories a user is subscribed to”. We don’t take these changes lightly, but as our community continues to grow tremendously, we have to prioritize our availability, user experience and performance.
Thanks to feedback from the community, we have fixed the following bugs from the initial September 6th release:
Your homepage feed will now have a singular, consolidated feed that aggregates content from your starred repositories and followed users. As part of this update:
If you’re an existing “Following” feed user, your feed content should be familiar to what you’ve been seeing on your “Following” tab. And now, with our new filtering control, you can fine-tune your content preferences to further curate your feed.
If you’re an existing “For you” feed user, we’ve also defaulted your filtering to showcase what you currently see on your “For you” tab. The new filtering control allows you to further customize your feed by including or excluding specific content types.
New users, we’ve got you covered with default settings that ensure you’re seeing the most relevant content. Dive in, personalize, and make the feed your own!
Repository rules allow you to easily add scalable protections for branches and tags on your repositories. This feature was recently made generally available, and GitHub Desktop 3.3 now adds support for repository rules in the form of preemptive warnings and errors if your work fails a rule configured by an administrator of your repository. These rules can fail when commits are pushed to GitHub, which may not be ideal if you queue up multiple commits before pushing. Advanced warning allows you to make changes before committing, saving you time and frustration.
Administrators can configure many different repository rules that apply to branches or tags. If a commit fails any of them, you won’t be able to push it to GitHub. This can be frustrating if you have multiple commits queued up, because the whole push will fail and you may have to perform a rebase to fix the failed commits. GitHub Desktop will now preemptively warn you if a commit you’re working on will fail a rule when you eventually try to push it. These warnings happen in several ways.
Specific branch names may be disallowed. You’ll now see an error if you try to create a branch that isn’t allowed.
GitHub Enterprise Cloud customers can utilize metadata rules that require certain fields to conform to specific values. One example being commit messages, which can be required to match a specific string or a regex pattern. These metadata rules are fully supported in GitHub Desktop 3.3.
Certain rules have remediations that aren’t supported by GitHub Desktop, such as requiring status checks to pass. These rules are bundled into a catch-all error message above the commit button.
Administrators can allow certain apps, roles, or teams to bypass rulesets. If you can bypass rules, the guidance shown is in the form of warnings instead errors, to let you know to be extra careful.
GitHub Desktop is proud to be an open source project and represents both GitHub and the open source community. Thanks to @le0pard for creating the RE2JS library being used for repository rules regex matching.
Automatic updates will roll out progressively, or you can download the latest GitHub Desktop here.
In 3.2.8, GitHub Desktop is shipping two great community contributions of highly requested features — “Check Out a Commit” and “Double Click to Open in Your External Editor”.
Alongside that, we have a nice addition to the clone dialog where you can quickly see if a repository has been archived, as well as many accessibility enhancements.
A big thanks to @kitswas for his work in adding the ability to check out a commit from the history tab, a much asked for feature.
We would also like to give a shout out to @digitalmaster with another highly requested feature add of being able to double click on a file to open it in your external editor, whether that is in the history or changes view.
Another great add with this release is being able to tell at a glance which repositories in your cloning dialog are archived and likely not suitable for cloning.
GitHub Desktop is actively working to improve accessibility in support of GitHub’s mission to be a home for all developers.
In so, we have the:
– addition of aria-label and aria-expanded attributes to the diff options button – #17062
– number of pull requests found after refreshing the list screen reader announced – #17031
– ability to open the context menu for the History view items via keyboard shortcuts – #17035
– ability to navigate the “Clone a Repository” dialog list by keyboard – #16977
– checkboxes in dialogs receiving initial keyboard focus in order not to skip content – #17014
– progress state of the pull, push, fetch button announced by screen readers – #16985
– inline errors being consistently announced by screen readers – #16850
– group title and position correctly announced by screen readers in repository and branch lists – #16968
– addition of an aria-label attribute to the “pull, push, fetch” dropdown button for screen reader users – #16839
– aria role of alert applied to dialog error banners so they are announced by screen readers – #16809
– file statuses in the history view improved to be keyboard and screen reader accessible – #17192
– ability to open the file list context menu via the keyboard – #17143
– announcing of dialog titles and descriptions on macOS Ventura – #17148
– announcing of the “Overwrite Stash”, “Discard Stash”, “Delete Tag”, and “Delete Branch” confirmation dialogs as alert dialogs – #17197, #17166, #17210
– improvements of contrast in text to links – #17092
– tab panels in the branch dropdown announced by screen readers – #17172
– stash restore button description associated to the button via an aria-describedby – #17204
– warnings in the rename branch dialog placed before the input for better discoverability – #17164
– errors and warnings in the “Create a New Repository” dialog are screen reader announced – #16993
Automatic updates will roll out progressively, or you can download the latest GitHub Desktop here.
We've shipped a small fix to improve security around creation of pull requests in public repos.
Prior to this fix and under very specific conditions, a user could create a pull request in a public repo even though they did not have push access to either the base or head branch and were not a member of the repo's organization. Often these pull requests were created by mistake and quickly closed, but could still trigger unexpected GitHub Actions or other CI jobs.
This fix has no impact on the common open source workflow where a user forks a public repo, makes a change in their fork, and then proposes their change using a pull request. This fix also has no impact on pull requests already created.
We want to hear from you! Let us know if you have questions or feedback.
If you manage your node.js dependencies with the pnpm package manager, you can now use Dependabot to keep those dependencies updated with automatic pull requests. You can easily configure this feature by adding or updating your dependabot.yml file in your repository. At this time, Dependabot will not open security alerts against pnpm dependencies.
Secret scanning's push protection feature is now generally available for all free public repositories on GitHub.com.
You can enable push protection for any public repository on GitHub.com from your repository's "Code security and analysis" settings in the UI or REST API. If you're an organization or enterprise owner, you can also also bulk-enable secret scanning.
For your repositories that are not a part of an organization, you can bulk-enable secret scanning and push protection in your personal "Code security and analysis" settings.
GitHub Desktop 3.2.3 makes force pushing and fetching through the newly added fetch/pull dropdown menu items as well as adding pull request comment notifications. Since 3.2.1, GitHub Desktop has also released more than 30 accessibility improvements.
In GitHub Desktop 3.1.5, we added the ability to force-push and fetch to the Repository menu item when applicable. Now, when those menu items would be available, the pull/push/fetch button becomes a dropdown so users can easily force push or fetch.
If you have been enjoying our Pull Request notifications on your repositories, you will be happy to hear we have expanded those notifications to include when someone has commented on your pull request as well so that you can keep up to date on the latest conversations happening on your pull request.
GitHub Desktop is actively working to improve accessibility in support of GitHub's mission to be a home for all developers.
Automatic updates will roll out progressively, or you can download the latest GitHub Desktop here.
We announced two weeks ago that we are changing how you receive notifications for secret scanning alerts. From today, those changes are in effect.
As long as you are not ignoring the repository in your watch settings, commit authors always receive notifications for new secrets that are leaked. This means you receive a notification for any secret committed after an initial historical scan has run on the repository.
We are changing how you receive notifications of secret scanning alerts. Previously, to receive secret scanning alert notifications, you had to watch a repository with "All activity" or "Security alerts" and enable Dependabot email alerts to receive notifications.
Beginning March 16, here are the steps you need to take to continue to receive notifications from secret scanning:
