Does GARM support pre-job runners?

[alexec]

I've been told that GARM creates one runner per job. I have a case where my runners (Kubernetes Pods) can only run code from specific pull requests. When the runner starts it is associated with the specific PR . They cannot run any job. I was planning to use runs-on to do this.

    # only on a cloud workspace runner
    - cloud-workspace
    # and is for this PR (this is `${pull_number}/merge`)
    - "${{ github.ref_name }}"

[gabriel-samfira]

Hi @alexec

GARM maintains pools of homologous ephemeral runners. All runners in a specific pool haave the same characteristics, including labels which is what you use in the runs-on stanza. When a PR is created a workflow job is triggered with a set of labels. GARM receives a webhook in which the labels defined in runs-on are included. It then tries to find a pool matching those labels and spins up a runner in that pool, if one is not already available due to min-idle-runners.

Once the runner comes online, the runner itself connects to github and subscribes to any jobs that match the set of labels that were defined in the pool you created in GARM. if the labels match, the runner consumes the job and starts running it. This is outaide of the control of GARM. The scope of GARM ends when the runner is spun up with the requested labels. GARM then comes back into scope once the runner has finished running a job and needs to be cleaned up.

To spin up runners specific to one PR, you would need to create a pool with a label that matches the value of the expanded variable ${{ github.ref_name }}. But that is probably not feasible, as you'd have to create the PR first, get the value of that variable and define a pool in GARM with a label that matches it. Or pre-define a pool with it if you already know what the value will be.

May I ask why there is a need to uniquely associate a specific set of runners to a PR? There may be an easier way to achieve the desired result.

[alexec]

When a pull request is opened I want to create a workspace for the pull request, start-up the application in the workspace, and then run some tests against it. Using GitHub actions means I don’t need to write any software for running the tests.

[gabriel-samfira]

Hmm. If you use workspaces, that means that there is a proper devcontainer setup already created in your repo. That should take care of installing all needed dependencies in the workspace. You could theoretically just run the tests in the workspace using the same command that the workflows would run.

For example, here's the devcontainer setup for containerd:

https://github.com/containerd/containerd/tree/main/.devcontainer

Anyone can just fork, start a workspace and run make test and it just works.

GARM can help to set up self-hosted runners, but those are different than the compute component in GitHub that makes workspaces possible.

My apologies if I misunderstood the goal. Bare with me.