I attempted to read that code in order to glean information about how it communicates back to GitHub about progress etc. The goal was to make a new runner. I ran for the hills, fast.

Sounds like most Microsoft projects to be honest. Not a lot of them can be highlighted as the pinnacle of software engineering, including their GitHub Actions implementation.

No kidding. I have been in the bowels of EF at work, and it has led me to (likely not independently) coin "encapsulation infatuation". Bloody hell, what a beautifully decoupled mess. The only way to make sense of a single thing is to step through/into each line of code.

It’s easy to look at the endgame. Just look at the hurdles https://github.com/nektos/act has to work with

Sadly that's an emulator of the entire stack, I wanted to do the runner part only (the goal being to end up with a sane self-hosted runner replacement).

I’m not sure if it’s open source but the actions-runner-controller project maintains a slimmed down version of the runner image that might be worth looking at

I searched for "github actions random exit codes" and didn't find anything.

Cool story. He was speaking about the source code and literally provided a link to the issue in question

I think he means his link, searching the text doesn't show "exit code," though maybe it is worded differently.

she did not, the exit code story is a different thing, though one I told on HN before. basically i spent half a year or so with writing infra and autoscaling for action runners on GCP, and there's absolutely nothing there i'm proud of. the pieces just didn't fit together. and weirdly enough, the majority of the blame isn't even with GCP and their broken image snappotting, slow provisioning times and asinine API design.

The linked issue is not about random exit codes though? And also doesn't really seem to support his assertion that the maintainers don't know how it works, but I'll admit I'm not very familiar with GitHub Actions.

Personal experience building infrastructure and an autoscaler for these things (which performed horribly due to API lag) while having weekly meetings with our GitHub rep to get the --ephemeral flag in (took about a year longer than promised). Sometimes the exit code would be 0 when using `--once`, and sometimes it would not be. Sometimes it'd also be 0 if the token somehow didn't work and the worker couldn't even register no matter how often you restarted it (of course with a cryptic Azure IAM error code). Either way, we eventually just decided that throwing away the machine if the runner exists for any reason was safest.

Looks like GHA was announced[1] around the same time as the acquisition by MS. The first commit in that repo is a year later when they opensourced it, so we can't see how it evolved before then.

For anyone who was at Github at the time, was it always written in C# or rewritten/replaced after acquisition? If "GitHub Actions is based on Visual Studio Team Foundation Server's CI" is the case, then it sounds like the latter.

[1]: https://github.blog/2018-10-16-future-of-software/

I don't recall the exact context anymore but during the Microsoft Build this year it was said by an employee at Github that the service came with the acquisition which is the reason it was and stays C#.

You can also find many leftovers with the "VSS" acronym, like https://github.com/actions/runner/blob/main/src/Sdk/Common/C... or https://github.com/actions/runner/blob/main/src/Sdk/Common/C... - which also mentions TFS (which is yet another acronym that used to refer to the Microsoft team-development thing).

This probably answers your question:

https://github.com/actions/runner/blob/a4c57f27477077e57545a...

> And nobody, including the current maintainers, seem to know exactly how it all works (or how it doesn't).[1]

I read through this whole issue, and I cannot find exactly what you're referring to. What message gives you the impression they don't know how it all works? Seems it's mostly people asking for updates, and eventually something similar but different got implemented.

The fact that the --once flag was implemented and just didn't work. And it didn't work for several reasons. One, the control flow in the runner is extremely convoluted and exiting out is not trivial, and two, the scheduler doesn't handle assigned jobs not being picked up.

And reason 0: it was never completely implemented, wasn't documented anywhere and wasn't supposed to be used by anyone at all.

It's all the linked GitHub issue, begin from the top.

"Wasn't supposed to be used" is all fine and good until your GitHub rep uses its existence to sell you on actions...

Is that something that actually happened, or are you talking about a theoretical case? It wouldn't surprise me if a Microsoft salesperson would do something like that, but still

I read one file, src/BrokenSomething.cs, and as an opinionated SWE I would say they could do some Separation of Concerns refactoring to clean it up.

I could do that refactoring, I suppose I could make it better, in addition to piling on about it on hacker news. ;-)

> GitHub Actions is based on Visual Studio Team Foundation Server's CI, and later Azure DevOps

Yes and no, ADO Agent (https://github.com/microsoft/azure-pipelines-agent) is far more secretive and "black-box" alike. Like stuck in old version of NodeJS, Powershell, API without documentation or even enough tests/samples...