lindluni / actions-runner-manager Goto Github PK

The API allows for runners to be transferred between groups, lets implement this endpoint so when users are deleting runner groups, they have the option to move runners to new groups in order to empty the runner group before deletion.

The App configuration (private key, installation ID, ...) should be stored and read from a config file on the disk, mounted in the current directory. The user can override it using an environment variable, GITHUB_CONFIG_FILE_PATH.

Ensure all http error response paths return at the end and dont unintentionally continue

Instead of using the environment variable to authenticate, switch to authenticating via an installation token. There may be native functionality in the github-go SDK, or we can use the library Igor linked in Slack (I'll dig it up), but either way, let's get rid of our use of a raw token.

Should generate Release Notes and create a release when a tag is pushed.

Add integration tests to exercise all of the failure response codes defined by the Swagger API.

Require users transfer or remove all runners from the runner group before deletion. Alternatively they can pass the force=true parameter to delete the runner group regardless of it being empty or not.

Add CONTRIBUTING.md to instruct users on how to build, test, add tests, add API's, and exercise Make targets.

Use the users token to implement the Rate Limiter.

https://www.alexedwards.net/blog/how-to-rate-limit-http-requests

Support GitHub Enterprise by adding config option to specify API endpoint and create a client that can interact with the API

Should probably split this into a few issues for each endpoint

Implement the /ping endpoint and replace the time.Sleep calls in tests with polling on /ping instead

• On release, we will push a semantically versioned tag
• On merge we will publish an image on the short SHA

Add a CODEOWNERS file and once the repository is transferred to an Enterprise, enable CODEOWNER reviews.

Should we replace GET calls with POST calls, GET requests have limits to the length of the request where POST does not not, though it seems non-idiomatic that users are making GET requests to modify state.

Use golinter, govet and gotestsum to verify code on PR and Merge

All integration tests should use TLS, we should run a small singular test (it can even be a failing test) without TLS just to confirm functionality, but ultimately we should expect users to always be using TLS

Allow users to configure the server in TLS mode so the HTTPS protocol may be used

Pre-Reqs:

• Kubernetes Cert Manager Installed on the cluster
• Ingress Preconfigured (demo using Nginx)
• A preconfigured ASM secret with the App config

Let's start with an AWS example. This should include:

• Namespace
• A GHCR secret
• AWS ASM secret configuration
• Cert generation (assumes default https verification or Route53 verification)
• Ingress with TLS enabled using the generated certs
• A service exposing the port to the load balancer
• A deployment with a single replica

Move secrets to GitHub environment to protect them and add approvers for PR's to protect test org.

When a tag is created, generate a release and push binary assets to it: https://github.com/softprops/action-gh-release

We haven't yet documented any of the Swagger API's with failure response codes, lets add these.

Let's get this out of my personal account and somewhere more realistic for an open source project