Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
willhaines opened this issue Jun 1, 2021 · 4 comments · May be fixed by #25
Open

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

willhaines opened this issue Jun 1, 2021 · 4 comments · May be fixed by #25
Labels
enhancement New feature or request

Comments

@willhaines
Copy link

willhaines commented Jun 1, 2021 •
edited
Loading

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.
@willhaines willhaines added the enhancement New feature or request label Jun 1, 2021
@tetchel
Copy link
Contributor

tetchel commented Jul 26, 2021

@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
Copy link
Author

@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
Copy link
Contributor

tetchel commented Jul 26, 2021

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

@koalalorenzo
Copy link

I am very interested in this feature too :D

fridim added a commit to fridim/openshift-actions-runner-chart that referenced this issue Jan 27, 2023
@fridim
Add option for manually-generated Runner Token
5106675 
closes redhat-actions#10
@fridim fridim linked a pull request Jan 27, 2023 that will close this issue
Draft
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add option for manually-generated Runner Token fridim/openshift-actions-runner-chart
3 participants
@koalalorenzo @willhaines @tetchel