upvote
Please, read between the lines. Github actions has been a mess since 2019 at least. None of the instability is new, before this unprecedented growth (for a service that's supposed to scale horizontally) the excuse du jour was the azure migration, before that it was the high rate of shipping post acquisition.

Core parts of the product, like navigating to individual files in a code review, are broken

reply
> Core parts of the product, like navigating to individual files in a code review, are broken

I think this is a good argument to underline "It's not _just_ the scale". Adding to this, the Github Code Review experience is kind-of broken, the way comments/threads are stacked in the PR overview has not improved, pagination isn't really a thing, and these issues are age old. Hopefully, one day, Github will mature.

reply
The phrasing could have been better, but we've talked as a team about cancelling a $100k/yr contract nearly half a dozen times the last year, and the only thing keeping us from doing so is various "compliance" issues, and to a lesser degree the friction from physically moving. That's a tenuous moat, and if I were a GH PM I'd probably want to know that the current instability is somewhere near critical mass.
reply
For CI there are a number of drop-in commercially-available options. You can make it a staged migration, first trivially migrating the build runners, followed by the more complicated integration test and deployment runners. The CI harness itself can follow, and finally moving to a code hosting and visualization service is last.

The final step is challenging; likely the most difficult part is changing all the code references and imports. Shadowing changes would be straightforward. Training your likely 25-50 engineers to use the new code review UX would likely not take that long.

Considering the wasted engineering velocity during Github outages, it's worthwhile to do even a partial migration. Github's action runners have in my experience, been the most fragile part of the platform. Given the ease of moving build and merge queue runners to alternates, it's a no-brainer.

reply
not constructive, but also not personal. rude but based on observed facts.
reply
How low would uptime have to get before you'd consider holding the engineers personally responsible for it?
reply
Why are we holding the engineers accountable and not the CEO? The company isn’t one department. Responsibility should bubble up to the top.
reply
They dont have a CEO ever since their last CEO said that human programming "wasn't going anywhere".
reply
Agreed. At some point to have to stop hugging your ops team and start firing them.
reply
No, you hire more of them, you give them what they need to do their jobs, and you actually listen to their recommendations. It's not even complicated. It just takes time and money, neither of which companies want to spend on reliability until their customers scream very loud en masse.
reply
Agreed. In fact, keep firing ops until someone gets it done. There's no way your company will build a reputation for not supporting their teams.
reply