Category: Last Week in GitHub

Last week was GitHub Galaxy, where GitHub showed off many of its innovations and how its platform can help enterprise and “mid-market” customers. I’ll do a separate write-up on what I got from those presentations.

Let’s look at what got released last week.

On the quality of life side, GitHub improved the contrast in their default light and dark themes. I haven’t taken them for a spin because I have been using one of their themes targeting color-blind folks because it has better contrast. I wish their announcement did more to show the side-by-side comparisons of what changed. Still, I’m delighted they continue to make efforts to improve their accessibility.

The feature that I’ve been anticipating the most is the addition of a VS Code extension for GitHub Actions. You can get the extension here. I’ve been using it since it came out, and it has already saved me a couple of times. Previously, I depended on actionlint for early feedback on my workflows, but this new extension does an even better job. The most significant difference I’ve seen is it does a decent job of detecting what variables are in scope. It still needs improvement, but that is typical with a beta product. While I haven’t used it yet, you can also check the status of workflows associated with the repo you are in from VS Code. This feature might be a massive win for devs who aren’t creating workflows but using them.

Putting on my security and compliance hat, GitHub made a ton of improvements that I can’t wait to use.

Looking at the dependency graph, we can now export an SBOM or Software Bill of Materials. GitHub has been making many improvements to the dependency graph and allowing us to add things not found during the build. This built-in way to generate an SBOM will be a huge help for anyone who needs to worry about Executive Order 14028. They’ve also made a bunch of improvements to the UI for the dependency graph.

Another fascinating compliance change lets us see when an admin bypassed a branch protection rule to push a commit. While this is only a minor tweak to the existing functionality it helps shine a light on areas where something exceptional happened.

GitHub released even more features than this, but these are the ones that caught my eye.

This article will be my last This Week in GitHub. I’ve learned a lot by looking at their releases every week, but it’s time for me to move on to some new projects.

Usually, this is a space where I write about the features that GitHub released last week. I am still amazed at how much stuff their engineering teams release in a given week, but that is not what I’ll write about now.

GitHub announced 13 changes last week, most around their Advanced Security offering, and the rest didn’t immediately catch my eye. The possible exception is that GitHub fixed a bug where the title of private issues and PRs could be visible in their new search feature](https://github.blog/changelog/2023-03-23-fixed-bug-that-allowed-private-issues-and-pull-request-titles-to-be-shown-in-search-results/). Overall, I’m not too worried about this particular issue. There are nuances around getting a specific item to appear in the search. Realistically, there isn’t a lot of proprietary information to glean from the title of a PR or Issue. All that said, I’m hoping that in the next Availability Report, GitHub will go into more detail about how they will prevent similar issues from happening in the future.

A potentially more impactful change happened last week when GitHub changed its RSA SSH Host Key. This happened because they accidentally published the private key, and out of an abundance of caution, GitHub changed their host key. So this is not a sign that GitHub had a data breach.

If you use an RSA SSH key, you will see a message like this when you try executing git commands against GitHub.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s. Please contact your system administrator. Add correct host key in ~/.ssh/known_hosts to get rid of this message. Host key for github.com has changed and you have requested strict checking. Host key verification failed.

GitHub provided instructions in the announcement for updating your ~/.ssh/known_hosts if you want to continue using the same SSH key. Alternatively, you could create a new SSK key using ECDSA or Ed25519 or get fancy and use a Yubikey.

Sticking with the overall theme of security, GitHub has also created a Secure Code Game. This game specifically targets C and Python, but many of the ideas will carry over to whatever language you work in. It follows my favorite style of coding challenge, where there is some existing code and some tests for you to make them pass. It’s been a while since I’ve written any Python, but I’m excited to give this a go.

And finally, GitHub has announced some cool stuff it’s doing with AI and even opened up a few waitlists. While it’s a little ridiculous, I love the idea of having Copilot write a summary describing the PR I’m looking at. I want to see how all this was made because I’d bet the difference between adding a summary and making a poem was so minimal it just got thrown in.

Have you started using AI in your daily work? I’d love to hear about how you are using it.

Last week GitHub released a feature that had a coworker whooping with joy. But we’ll get to that in a moment.

First, there is a more significant thing I want to look at. GitHub is working with EU policymakers on the Cyber Resilience Act. While I’m based out of the US and work at a US-based company, I still have unpleasant memories from the year before GDPR went into effect as we scrambled to comply with some legislation we didn’t understand. I’m very excited to hear that GitHub is working on this, and I hope the policymakers listen.

I’m slowly reading through the proposals for the Cyber Resilience Act or CRA, but it is slow going. It will be worth keeping an eye on this proposal.

Also, GitHub is officially starting its rollout process to move everyone to 2FA.

Now for the releases that GitHub made last week.

GitHub announced a fix to a bug where users retained access to an org after being removed. I couldn’t find any previous mention of this bug, but apparently, they have had a manual fix since Oct. 20, 2022. My guess is GitHub has a policy of waiting for the automated fix to be in place before discussing issues. I wish I had heard about this issue in October and suddenly got an update rather than finding everything out later.

Moving to happier news, I was surprised to see how excited some coworkers were about this change. You can now comment on an entire file in PRs. This is a public beta, and they are looking for feedback, so try it out.

There is also a new beta for slash commands in discussions, issues, PRs, and projects. I’m curious to see how much this becomes a part of my workflow. Adding code blocks doesn’t knock my socks off, but easy access to saved replies and creating markdown tables has my attention.

Enterprise customers can join a public beta to display members’ IP addresses in the audit logs.

Moving from public to private betas, GitHub is looking for folks to test a tool for migrating repos from BitBucket Server to GitHub.

Moving over to Generally Available features, we have a lot more.

Projects are now on GitHub Mobile. On the one hand, using a ticketing system from my phone sounds like hell; on the other, I recognize that I’ve done that with Jira.

Discussions can now be closed as either Resolved, Outdated, or Duplicate.

Creating and managing GitHub Action Runner Groups comes to the team plan. This functionality was already available to enterprises.

In the land of GitHub Advanced Security, code scanning now only shows alerts based on the files changed in a PR. Also, the change to notifications for secret scanning has gone into effect.

We saw runner groups get moved into the team plan, and I also hope we eventually see something like this for GitHub Advanced security.

Sticking with changes to the enterprise tier, apps can now call GitHub APIs using a user-to-server token. I haven’t used this functionality, but it apparently creates parity with OAuth apps.

Finally, we get to Dependabot, who also got some love this week. Dependabot now keeps Gradle version catalogs up-to-date. And, for anyone using versioned Reusable Workflows, Dependabot can now keep those up to date too.

Well, that about wraps it up. What new features stood out to you?

I’ve talked about it a lot, but it’s here. GitHub is starting to roll out the 2FA requirements for everyone starting March 13th, the day this is published. GitHub will begin with small groups at first but progressively scale the size of those groups up over the year.

They will email folks 45 days before they will require it for an account, and if you do not set up 2FA in that time, you will get the opportunity to snooze, turning it on for up to one week the first time you log in after those 45 days are up.

This article mentions the numerous improvements they have made to 2FA this year. I have no doubt that we will see more as they learn through this rollout process.

That’s not the only big news from this week. GitHub also announced the Octernship, open to students in India, Singapore, Indonesia, Malaysia, Vietnam, Philippines, Thailand, Mexico, Nigeria, and Colombia. This is an excellent program to expand the opportunities in tech beyond the US. It is also fantastic that GitHub allows other companies to partner with them and work with students. If you’re interested in being a partner for this program, you can apply here.

None of what I’ve mentioned so far is about features that GitHub released last week, and they certainly released a lot, so let’s get into those.

The dependency graph will no longer ingest go.sum files in Go projects. This will apparently reduce the number of false positives for Depenedabot alerts. Also, go.mod files are still supported.

Sticking with the dependency-related topics dependency graph and Dependabot now support npm v9.

Security advisories now have multiple types of credits. These credits are:

• finder
• reporter
• analyst
• coordinator
• remediation developer
• remediation reviewer
• remediation verifier
• tool
• sponsor
• other

GitHub Enterprise Server 3.8 is now generally available. While I understand the need for self-hosted GitHub instances, I still find it amusing that some folks want to self-host GitHub. You can run both the self-hosted and cloud-based versions if you have GitHub Enterprise.

The GitHub Slack integration now supports filters on Discussion categories. I can imagine this being a great improvement for anyone subscribing to Discussion via the Slack integration. I hope we see more filters like this added to that integration in the future.

GitHub Enterprises can now run more concurrent 2-core Windows and Linux jobs. Previously, you could only run 180 jobs concurrently as a GitHub Enterprise on 2-core Windows and Linux runners. Now you can run up to 500; if that still isn’t enough, you can reach out to GitHub support to get even more.

Custom repository roles API is now generally available. There was also a breaking change that came with this. The endpoint is moving from /orgs/{org}/custom_roles to /orgs/{org}/custom-repository-roles. The now deprecated beta API will be removed on September 7th, 2023.

There will also be changes to the code search API starting April 10th. The most significant change is rate limiting, which will be set to 10 requests a minute.

Sticking with searching through code over in Advanced Security land, you can now run CodeQL queries across multiple repos at the same time. GitHub is mainly targeting this at security researchers, allowing them to look at a bunch of open-source repositories simultaneously. Hopefully, this will help make the theory that there are more eyes on open-source software true.

Also, you can now delete stale code-scanning configurations. I’ve not used this feature, so I’m not entirely sure what this is solving, but my guess is fewer false positives to look through in security scans which is always a win.

In GitHub Actions land, we see some improvements to required actions. The biggest improvement is that any branch with a required workflow automatically requires a PR.

Finally, we have GitHub Issues & Projects with a whole bunch of improvements, but I’m waiting for the Task List improvements they’ve made to come to PRs.

What new feature are you most excited about?

This is the year that GitHub will require anyone who contributes code to enable 2FA, and we continue to see them improve how we use 2FA this week. As I previously mentioned, the changes we see out of GitHub this year will be an excellent opportunity for us to learn how to do 2FA better.

You can now disassociate your email address from your locked GitHub account. As GitHub mentions when enabling 2FA, if you lose access to your second factor and recovery codes, there is no way to regain access to your account. With this latest enhancement, if you find yourself in that situation, you can disconnect your email from that account to create a new account.

While creating a new account would change the read-only email account that GitHub generates for you, if you use your actual email address, all your commits would transfer over to that new account.

GitHub also made it easier to set your preferred 2FA method. This will hopefully make it easier for you should you need to log in from another device or use sudo mode. I didn’t see the point of this change at first. Then I remembered a brief time when GitHub decided I should always use the mobile app to verify myself even though I had my security key already connected to my computer.

Moving away from 2FA, if you use JetBrains Gateway and are a .NET developer, you’ll be excited to hear that CodeSpaces now has a beta for Rider. I would love to hear how this goes for anyone using it.

Also, code search and code view are now in a public beta. I had some initial issues with code search, but over the past few weeks, I’ve not run into any, so hopefully, they have gotten all the kinks worked out as they enter into the public beta.

Were there any GitHub announcements I missed that caught your eye?

Most weeks, I find a few things that GitHub releases that catch my eye. Unfortunately, last week was not one of those weeks. In fact, what caught my eye this week was a project getting canceled.
The book Accelerate popularized the four key metrics of DevOps or the DORA metrics. These metrics offer a great deal of insight and can help guide teams to find out how they can improve.
GitHub had a feature on the roadmap to show Deployment Frequency and Lead Time. These are the two metrics that GitHub is ideally situated to provide, but there are a lot of challenges in collecting these metrics.
While this was not assigned to anything other than future development, I was very excited about this feature, and I am sad to see that it will not be worked on. That said, I understand the challenges of trying to collect this data.
How can you tell from your repository that code was released? Does merging to your main branch represent releasing? What about creating a tag? If you use GitHub Actions for your deployment pipeline, this is much easier since it is the mechanism that releases your code.
Unfortunately, we are left with many other tough questions, like how do you calculate the lead time for an individual item? Is this something that can only be calculated if you use GitHub issues? What if you use conventional commits or provide a changelog?
I’ve also found that each repo, let alone each team has a different release process. Creating a truly generic solution to these various problems would be very challenging.
So, while I am sad that GitHub will not build in a feature, I understand why they won’t.
Do you track any of the DORA metrics? Have you automated their collection?

Last week was a solid week for GitHub releases. While only one stands out to me as super helpful, there was still a substantial showing of new features released and other subtler changes made to ease our lives.

Last week’s big news is that merge queues are now in a public beta. Have you ever been about to merge a PR only for someone to beat you to it, and now you need to update your PR, rerun CI, and get a new approval? Merge queues will help and handle most of the tedious work for you.

Merge queues will not inherently solve the problem of merge conflicts. However, they will make it easier to work in smaller chunks, which is the best strategy for avoiding merge conflicts.

This is not a feature that every repo or team will need, but for those who do, I think this will be a massive quality-of-life improvement.

Also worth noting is that enabling merge queues will require updates to your pipelines so that checks run at the right time.

on:
  pull_request:
  merge_group:

There were a couple of significant improvements to permissions. Dependabot alerts are now visible to anyone with write or maintain roles on a repo. Also, we can now create custom roles to manage branch protection rules. Previously, those things were limited to repo admins, leading to devs with more permission than they should have or no access to the tools they need.

GitHub also tweaked the Dependency graph for some JVM projects to show how you can get more info from your build into the graph. This is something that JavaScript projects already get out of the box, but it’s great that GitHub is making it easier for other languages to get these features.

Will merge queues make your team’s workflow better?

I’ve been watching the releases on GitHub closely for a bit, and this week did not see a lot of new releases, but there was certainly something interesting.

GitHub usually is good about giving us advanced notice before changes come out. How they rolled out Ubuntu 22.04 was a great example of this. There are also other things like Copilot, where there was an extended beta period before it became a product.

This week was a bit different. GitHub is updating the default GITHUB_TOKEN permissions to read-only in GitHub Actions. Before you get too worried, this is designed only to impact new repos, org, and enterprises. Existing repos, orgs, and enterprises will not have any changes, and new ones can enable the write permissions if they want.

Switching the default for the tokens to read-only is good, but it would be messy if they did not grandfather in existing repos. That said, if you work on one of those grandfathered repos, it’s still worthwhile to move to read-only tokens by default.

GitHub also released another change that impacted existing projects, and I suspect it caught many people by surprise. The January availability report briefly mentions it, but we’ll have to wait till next month’s report to get all the details.

On Tuesday, January 30th, GitHub released a change that could change the checksums for some git archives. They eventually reverted this change, and the availability report identified this as a 7-hour outage.

Looking at the timing of that notice going up, I doubt they realized this would happen. Their first reaction was to mention in the changelog that they do not guarantee the stability of checksums in autogenerated archives. If you are looking for a guarantee, the archives you upload are guaranteed to have identical checksums.

After quickly scanning the documentation for Releases, I did not find mention of the caveat around checksums and autogenerated artifacts, but I easily could have missed it. 

There is a lot to learn from this. GitHub had an unexpected change made while updating a dependency. Their first reaction was to announce the difference and tell us they didn’t guarantee the functionality. Eventually, they rolled that change back, presumably because of complaints. Next month they will tell us more about what happened in their availability report.

I can’t say that I liked the initial announcement of the change, but GitHub has continued to address the issue with transparency, which I appreciate.

Would your team handle a similar situation as well?

Last week GitHub announced that 100 million developers are using GitHub. This is, of course, a tremendous milestone for them. What I found most interesting from that article was GitHubNext. This is the research arm of GitHub and where CoPilot came from. There are a lot of exciting projects they are working on there, but that is a topic for another time.

They didn’t let hitting the 100 million developer mark slow them down. There were still other things announced and released last week. One of the announcements I’d love more context on is that PayPal will no longer be supported to sponsor projects starting February 23rd. Credit and debit cards will still be supported if you want to sponsor projects. Removing a payment method from the outside makes it look like GitHub is making it harder for projects to get sponsors. The article also didn’t say much about why this change was happening, which leaves me thinking there was some dispute with PayPal.

Looking at new functionality though GitHub desktop received some love and has some improvements around force pushing. There were also some community contributions to the project, which is fantastic. It makes me so glad to see other projects with thriving communities. I was working with a closed-source tool last week and was constantly frustrated that I couldn’t just see the code to understand what was happening.

While GitHub Desktop gained the ability to force push whenever the web portal got an interesting new feature, there is now an API for reverting a PR. This is awesome as it is one less time that we need to use a force push. Hopefully, people will utilize this functionality because sometimes reverting is much faster than trying to patch.

Which of these are you most excited to try out?

Last week there was an announcement of false alerts flagged in security logs, a prolonged outage, sunset announcements, and a few other updates that mainly impact folks using GitHub Issues, using Advanced Security, or managing enterprise organizations.

Along with all that, Git released 2.39.1 to address a couple of CVEs. The best thing to do is update your version of Git, but if you can’t, GitHub offers some remediation steps until you can upgrade.

GitHub also announced that some audit logs for branch protection rules were flagged as false alerts. The window for false alerts was between January 6th and 11th, and the logs were for protected_branch.policy_override and protected_branch.rejected_ref_update entries. Flagging the logs is an elegant solution to a problem around audit logs. GitHub never deletes audit logs but sometimes writes incorrect logs. 

There was also a widespread outage on Thursday, January 19th, that lasted about 5 hours. I felt the impact of that outage as it impacted general Git operations and Actions. What frustrated me about this outage was less the breadth of the outage or the length of it, but rather GitHub posting the same status three times. I have a lot of empathy for the folks who worked this incident, and I know how much this is Monday morning quarterbacking, but seriously change up the status update.

I look forward to reading about this incident next month when GitHub releases its availability report.

Did you know that GitHub supported SVN endpoints? I did not, but don’t start using them now since GitHub will remove SVN support on January 8th, 2024. Feature debt is real, and I am always excited to hear about companies that decide to sunset a product, except Google. I’m still bitter about Google Reader. GitHub says that less than 0.02% of requests to their Git backend came through the SVN endpoints. I don’t know how much effort went into maintaining SVN support but take note of this approach. GitHub used data to determine how much a feature was being used and reached out to those who used it to find out what they needed to switch. Removing SVN support was a far longer road than we can see from the outside, but it resulted in new features to help those last few folks migrate all the way to git.

GitHub also deprecated CodeQL Action v1. They aren’t deleting the action, but I suspect if there is any security vulnerability found for that version, they will. One of the coolest parts of this announcement was that Depenabot could upgrade the workflows to v2 for you. If you haven’t checked out using Dependabot to update your dependencies on a schedule, it’s worth checking out.

Which announcement from GitHub caught your eye this week?