open-source

Subscribe to all “open-source” 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

GitHub Skyline CLI extension now available

Bring your GitHub contributions to life with the new GitHub Skyline CLI extension – visualize, customize, and 3D print your journey in open source, all from the command line!

GitHub CLI Skyline extension in action showing a user's contributions in glorious ASCII art.

Go
@chrisreddington
@martinwoodward
@leereilly
@jasonlong

🛠️ Features

  • Binary STL generation: Turn your contribution data into 3D-printed works of art.
  • Customizable year selection: Show off a single year or flex with multi-year masterpieces.
  • Automatic authentication: Uses your GitHub credentials or specify another user.
  • ASCII art previews: See your contribution skyline before it’s immortalized IRL.

💻 Quick Start

If you already have GitHub CLI installed, installation is as easy as:

gh extension install github/gh-skyline

Generate a skyline:

gh skyline --year 2024

Generate a skyline for a specific user and year range:

gh skyline –-user chrisreddington --year 2014-2024

Start printing your GitHub journey in 3D glory. Your desk, your shelf, and your ego will thank you 😎

 

An example of a 3D Printed GitHub Skyline

 

🌟 Did you know: If you don’t have a 3D printer, you can upload STL files to GitHub and see them rendered directly in your browser:

Share your virtual | IRL skylines with #GitHubSkyline on social or in the community discussion – we can’t wait to see your creations!

See more

GitHub CLI renews GPG signing key for Linux packages

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.

See more

GitHub Desktop 3.4.4 – Introducing Custom Editor and Shell Integration

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.

Demonstrating adding a custom editor via the new integrations setting

Accessibility Improvements

  • Fixed: The “Open a Pull Request” and “About” dialog’s headings are announced via NVDA – #19107
  • Fixed: The branch selection popover in the “Open a Pull Request” dialog does not close on filter clearing – #19106
  • Fixed: The contrast ratio of icon in the diff file warnings is at least 3:1 – #19097
  • Fixed: The “Push Local Changes” confirmation dialog uses “alertdialog” role such that screen readers announce entire dialog contents – #19098
  • Fixed: Emoji’s provide descriptions for screen readers – #19101
  • Fixed: Stop improper announcement of \”dialog\” role on the autocompletion suggestions popover – #19114
  • Improved: Screen readers announces when users expand context in a diff – #19128
  • Improved: The squash dialog provides visual input labels – #19100
  • Improved: The search inputs across the app provide visual labeling in the form of a search icon – #19103

Community Contributions

  • Added: The external editor Cursor is supported on macOS – #17462. Thanks @bjorntechCarl!
  • Added: The external editor JetBrains RustRover is supported – #18802. Thanks @Radd-Sma!

Download GitHub Desktop

See more

GitHub Private Mirrors App – Public Beta

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:

  • Branch protection rules can enforce PR reviews by people on particular teams to ensure proper signoffs
  • If commits include code/keys/docs that should not be made public, there’s the opportunity to remove them and squash merge without leaking history
  • Initial development can happen inside an Enterprise Managed Users (EMU) organization, whose users ordinarily can’t interact with public GitHub repos. Once the app syncs a change, the public fork and upstream PR use normal github.com identities.

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.

See more

GitHub Desktop 3.4 – Reset to Commit and Accessibility Settings

GitHub Desktop 3.4 lets you reset back to a specific commit quickly with “Reset to Commit” and improves discoverability of key application controls.

Resetting to Commit

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.

See more

dependabot-core is now open source with an MIT license

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!

See more

Deprecation notice: v3 of the artifact actions

Starting January 30th, 2025, 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.

See more

GitHub-hosted runner images deprecation notice: Docker Compose v1

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.

See more

Authenticate ORCID iD

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.

See more

Deprecation notice: v1 and v2 of the artifact actions

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.

See more

GitHub Actions – Artifacts v4 is now Generally Available

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.

  • Artifacts will be scoped to a job rather than a workflow. This allows the artifact to become immediately available to download from the API after being uploaded, which was not possible before.
  • Artifacts v4 is not cross-compatible with previous versions. For example, an artifact uploaded using v3 cannot be used with actions/download-artifact@v4.
  • Using 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.
  • A single job can upload a maximum of 500 artifacts.

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.

See more

Improvements to the homepage feed

 

We’ve released the following improvements to your homepage feed.

  1. You now have the option to include or exclude events from starred repositories, in addition to the default events from repositories you sponsor or watch.

       2. You will now see cards for when someone has forked one of your repositories.

See more

Contributing to GitHub Docs

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.

See more

Updates to your GitHub Feed

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:

  • We were showing releases for organizations that you follow, instead of only showing them for repositories that you watch or star. This is now fixed. 
  • We have also addressed a problem where ‘Followed You’ cards were sometimes appearing out of chronological order.
  • We do not plan to re-include “push events for repositories a user is subscribed to” for the reasons listed above, but we will continue to address feedback as it aligns with our platform goals.

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:

  • The content from the “Following” feed has been combined with the “For you” Feed, so you’ll have one singular location to discover content.
  • For those looking to customize, we’ve enhanced the filtering controls, enabling you to tailor your feed to display only the event types that matter most to you. Including:
    • Announcements (special discussion posts from repositories)
    • Releases (new releases from repositories)
    • Sponsors (relevant projects or people that are being sponsored)
    • Stars (repositories being starred by people)
    • Repositories (repositories that are created or forked by people)
    • Repository activity (issues and pull requests from repositories)
    • Follows (who people are following)
    • Recommendations (repositories and people you may like)
  • We’ve given the entire interface a fresh and visually appealing makeover ✨

image

What this means for you

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!

See more

GitHub Desktop 3.3 – Repository rules

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.

Repository rules

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.

Branch creation

Specific branch names may be disallowed. You’ll now see an error if you try to create a branch that isn’t allowed.

GitHub Desktop’s “Create a branch” dialog showing a disallowed branch name error

Metadata rules

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.

GitHub Desktop’s commit message area, showing an error for a commit message rule failure

Additional rules

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.

GitHub Desktop’s commit message area, showing a generic error for a failed repository rule

Bypassing

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’s commit message area, showing bypass warnings for a commit message rule and another rule

Shout out to our open source contributors

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.

See more
View more changes