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.
GitHub Desktop now allows you to open your repositories with any editor or shell, even if it’s not on the list of supported integrations. Supercharge your integrations with advanced configurations including specifying command line arguments.
Today, we’re releasing a beta version of an open source GitHub App that manages private mirrors of public upstream repositories. The Private Mirrors App (PMA) enables organizations with regulatory or policy code review requirements to conduct their reviews in private, before contributing changes upstream. The app manages the lifecycle and synchronization of these private mirrors and automatically configures rulesets to manage PRs made to the mirrors.
The main benefits of working on private mirrors through PMA are:
If this is interesting to you, check out the Private Mirrors App repo. If you’ve got questions or feedback, feel free to file an issue in the repostitory or join the conversation in the GitHub Community Discussions.
GitHub Desktop 3.4 lets you reset back to a specific commit quickly with “Reset to Commit” and improves discoverability of key application controls.
With Reset to Commit, it takes one click to set your local history back to your latest pushed commit, with all of the reverted changes landing back into your changes list. While similar to using the undo function, Reset to Commit allows for resetting more than one commit at a time. By adding a new way to modify your history, Reset to Commit fits right along side undoing, reverting, amending, squashing, reordering, and cherry-picking features.
GitHub and the Desktop team are committed to making GitHub Desktop a tool for all developers. With GitHub Desktop 3.4, links are underlined by default and checkmarks are used in the diff to indicate whether a line is selected to be committed. These changes are aimed to enhance discoverability, be keyboard-accessible, and be semantically marked up to enable interaction with assistive technologies.
For users who want to opt out of these changes, check out the new Accessibility settings pane to customize your experience.
Automatic updates will roll out progressively, or you can download the latest GitHub Desktop here.
We’re excited to announce that the dependabot-core project is being relicensed under the MIT License, making it easier for the community to contribute to Dependabot.
Keeping dependencies updated is a crucial part of securing your software supply chain, and Dependabot has been helping GitHub users do this since 2019. It’s used by millions of developers each month to keep their dependencies up-to-date and free of known security vulnerabilities. We don’t charge anyone to use Dependabot, because we think everyone should be able to use open source without fear of vulnerabilities.
dependabot-core is the component of Dependabot that defines the logic to create pull requests for dependency updates across the 20+ languages and package managers it supports today. The update logic in dependabot-core is tightly integrated with the rest of GitHub’s Dependabot features, such as grouped updates and auto-triage rules, and contributions from collaborators have helped with its support of Swift and improvements to NuGet. By adopting the MIT license, we will simplify the process for members of the community to contribute to Dependabot and innovate together.
Dependabot-core was previously available under the Prosperity Public License 2.0, and has received contributions from more than 300 developers over the past few years. Now, the MIT license will make it easier than ever for members of the community to join our cause to improve the security of all the world’s software. If you’d like to learn more about contributing to dependabot-core, please check out the repository, and drop us an issue or pull request!
Starting November 30, 2024, GitHub Actions customers will no longer be able to use v3 of actions/upload-artifact or actions/download-artifact. Customers should update workflows to begin using v4 of the artifact actions as soon as possible. While v4 of the artifact actions improves upload and download speeds by up to 98% and includes several new features, there are key differences from previous versions that may require updates to your workflows. Please see the documentation in the project repositories for guidance on how to migrate your workflows.
The deprecation of v3 will be similar to the previously announced v1 and v2 deprecation plans, which is scheduled to take place on June 30, 2024. Version tags will not be removed from the project repositories, however, attempting to use a version of the actions after the deprecation date will result in a workflow failure. Artifacts within their retention period will remain accessible from the UI or REST API regardless of the version used to upload. 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.
Docker Compose v1 has been deprecated as of July 2023. All customers utilizing Compose v1 on GitHub-hosted runners are encouraged to migrate to Compose v2. Per GitHub’s support policy we will remove this tool from our GitHub managed runner images effective July 9, 2024.
To avoid breaking changes, customers will need to update their Actions workflow files from using docker-compose to docker compose. After July 9, workflows will begin to fail that are using the previous syntax. Customers are advised to review the migration instructions to ensure they are making all the changes required.
For more information on GitHub managed images, see the runner-images repository.
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.