[FEATURE] Optionally accept manually-generated $RUNNER_TOKEN instead of $GITHUB_PAT

[willhaines]

Is your feature request related to a problem? Please describe.

My GitHub account owns many repositories, and it would be safer to provide a token scoped to a single repo or organization, rather than a PAT with admin access to every repository/org. I'm referring to the token that is provided when going through these steps https://docs.github.com/en/actions/hosting-your-own-runners/adding-self-hosted-runners.

Describe the solution you'd like

Take advantage of the changes implemented in redhat-actions/openshift-actions-runners#10, which may include resolving #9. Additionally, this would include a pre-install (and maybe pre-upgrade) hook in the chart to run registration.sh as a Job before creating the Deployment.

Describe alternatives you've considered

Currently, I could supply a bogus $GITHUB_PAT along with a valid $RUNNER_TOKEN, and everything would work until the Pod is recreated, at which point the runner would fail to authenticate because the RUNNER_TOKEN would have expired and the local creds file would be deleted.

Additional context

I should have time to make a PR for this in the next week or two, unless someone pipes up that this is actually impossible, or that it would not be merged for some reason.

[tetchel]

@willhaines with your PR redhat-actions/openshift-actions-runners#10 merged into the runner image repository some time ago, are you interested in making this change in the chart, too?

[willhaines]

@tetchel I would very much still like to see this implemented, but due to a shift in team priorities, likely will not have time to work on it until September. In planning this work, I think it will require some significant changes to the chart, but maybe you an see a simpler path?

1. Adding support for PV(s) in general, likely including logic to create one/them or accept a reference to existing PV(s).
2. Scaling up to multiple runners with persistent storage may require the use of a StatefulSet instead of a Deployment
3. Launch a Job using chart hooks to auth with RUNNER_TOKEN and initialize PV(s) before creating/updating Deployment or StatefulSet

[tetchel]

1 & 2 should be implemented anyway. Then we can evaluate how to add 3.

[koalalorenzo]

I am very interested in this feature too :D