Enhancement: Use act as a self-hosted runner for github actions

[ChristopherHX]

Some people want to have more platform support for self-hosted runners than dotnet provides. What about reusing the runner of act to create a self-hosted runner written in go?

I have written a proof of concept prototype which (partially) implements github's / microsoft's proprietary azure pipelines protocol and executes the job via act.

Does this fit into the goals of act? I guess this breaks

"Think globally, act locally"

from the ReadMe.

I thinks this improves compatibility for workflows tested against act, because less lines of the workflow are interpreted by github.

My problems using act as library are:

• No way to disable localcheckout
• No way to provide the repository owner and name without a checkout
• No way to use an existing github context (needs depends on an exitsting PR)
• Cannot fully instantiate a runcontext from scratch (outside of the act module), I only want to run one job at a time

What works

• translating steps from githubs job request into acts step model
• live logs on github.com
• logs foreach step are uploaded to github.com

Sample Test Run of my prototype:

My prototype currently doesn't have a cli parser and needs small code changes to be registered against github or my own actions server, Implemented now

[igagis]

I'm trying @ChristopherHX 's runner at the moment, it looks very promising for my needs.

[catthehacker]

I don't see it happening in a near future. I assigned us to this but it's not something that is planned to be implemented in act. It would be nice to see if there is any demand for it but act is mostly useful to eliminate the need to trigger GitHub Actions.

I've also explained here why it's not recommended for now to do such things. The ultimate priority for now is to match full compliance with GitHub Actions workflow behaviour, since we still have a lot of issues with that (e.g.: env: not properly parsed).

[igagis]

It would be nice to see if there is any demand for it but act is mostly useful to eliminate the need to trigger GitHub Actions.

I'm currently using @ChristopherHX 's runner based on act due to some bug in official github runner, and it doesn't seem like they will fix it anytime soon, see https://github.com/actions/runner/issues/1168.

[catthehacker]

By demand, I meant volume of it, and quite a big one if we want to consider implementing such big change at all.

[ChristopherHX]

Well I have implemented it already, so it will keep a different Project for now. There is no need to change the existing code of act, other than make it to match github actions more closely. For example the timeout-minutes is an interger, but it is an expression on github actions. The protocol could live in an external github repo, then only some step translations needs to be intergrated into act.

[catthehacker]

There is no need to change the existing code of act, other than make it to match github actions more closely

[StevenACoffman]

@ChristopherHX I was wondering how much more remains to be upstreamed from your fork to make nektos/act match github actions more closely? I use both your fork and nektos/act and would love to have the diff be as small as possible

The protocol could live in an external github repo, then only some step translations needs to be integrated into act.

@catthehacker would you be supportive of this incorporating the step translations into nektos/act (with a flag or something to disable it by default)?

[catthehacker]

(with a flag or something to disable it by default)?

if it will be useful for act, then I don't see why it would be under a flag.

[ChristopherHX]

I was wondering how much more remains to be upstreamed from your fork

More or less this is still pending

• local step runner, nektos/act has only a docker implementation. I added a hostexecutor which implements the current container interface. Depends on runtime actpath, since without container runtime we get path collision if running > 1 jobs parallel
• force remote checkout flag in config, since a selfhosted runners doesn't have any local checkout it could copy
• make docker optional, needed for freebsd, netbsd, plan9 etc.
• pass shell command directly to the container implementation, nektos/act cannot call cmd on windows without any error
• GHES / gitea add the protocol to the cli switch cannot bind to http://github.localhost ( only https://github.localhost works ) The offical runner supports this
• gitea allow custom GITHUB_API_SERVER, e.g. http://gitea.localhost/api/v1. The offical runner supports this
• Allow cancellation of running steps
• Allow to control tty allocation without tty check
• Move container --rm to the jobexecutor, to make shure we don't skip cleanup
• Custom source for the github context, since we receive one from the github actions service / runner.server

match github actions more closely

This is more or less optional, I meant only quality / usablilty improvements.

Technically if only the docker executor is required, We could skip over to

• it might be possible build github-act-runner directly with nektos/act
• copy my code into new package(s) for nektos/act
• Integrate the configure, remove and run commands for selfhosted runner support I'm not shure if this would confuse some people, after nektos/act has these subcommands.