Azure DevOps is nearly identical, but with slightly different zoo of issues that are less well documented in public sources.
It also has the problem of not having a local dev runner for actions. The "inner loop" is atrociously slow and involves spamming your colleagues with "build failed" about a thousand times, whether you like it or not.
IMHO, a future DevOps runner system must be an open-source, local-first. Anything else is madness.
Right now we're in the "mainframe era" of DevOps, where we edit text files in baroque formats with virtually no tooling assistance, "submit" that to a proprietary batch system on a remote server that puts it into a queue... then come back after our coffee to read through the log printout.
I should buy a dot matrix printer to really immerse myself into the paradigm.
They are so identical, there's code in the GitHub runner to search and replace "Azure DevOps" with "GitHub Actions" in log output on the fly.
The entire code is a wonderful mess. We found that when we early-adopted ephemeral runners, that the control flow is full of races and the status code you get at the end is indicative of exactly nothing. So even if the backend is just having a hickup picking up a job with an obscure Azure error code, you better just throw that entire VM away, because you can't know if that runner will ever recover or has already done things to break the next run.
The current version of GHA is "Azure DevOps v3".
IIRC, it came after Microsoft purchased GitHub and I think it was part of a plan to discontinue/kill Azure DevOps altogether in favor of GitHub. I don't think they have feature parity yet, specially on the issues and permissioning parts.
Although, I never saw a public announcement of this discontinuation, ADO is kind of abandoned AFAICT and even their landing page hints to use GitHub Enterprise instead [1].
It also has the problem of not having a local dev runner for actions. The "inner loop" is atrociously slow and involves spamming your colleagues with "build failed" about a thousand times, whether you like it or not.
IMHO, a future DevOps runner system must be an open-source, local-first. Anything else is madness.
Right now we're in the "mainframe era" of DevOps, where we edit text files in baroque formats with virtually no tooling assistance, "submit" that to a proprietary batch system on a remote server that puts it into a queue... then come back after our coffee to read through the log printout.
I should buy a dot matrix printer to really immerse myself into the paradigm.