Repository navigation
feat(arc): let the ARC role manage an install that uses its own names - #9
Merged
Merged
Conversation
github_runner_arc_controller_release_name and github_runner_arc_controller_namespace default to arc and actions-runner-controller, as before. The controller install, its anti-affinity selector, the stale-listener lookup, the heartbeat's RBAC and the namespaces the platform ensures all use them, so the role can manage a controller that an existing install created under other names instead of adding a second one. The heartbeat script reads the controller's namespace from HEARTBEAT_CONTROLLER_NAMESPACE. The role passes it only when it differs from the script's default, so an unchanged configuration leaves the heartbeat Deployment as it is.
github_runner_arc_manage_image_pull_secret separates the pull Secret from the App and heartbeat Secrets that github_runner_arc_manage_secrets covers, and follows it unless set, so existing configurations behave as before. When false, the role writes no pull Secret in any namespace, needs no registry credential, skips the image pull check, and checks before changing anything that the Secret named by github_runner_arc_image_pull_secret_name exists. This suits a pull Secret that something else mints and keeps current, such as one made from a GitHub App installation token. With github_runner_arc_manage_secrets false the role no longer resolves an installation ID either, since it only goes into the App Secret the role does not write, so an org needs no private_key in that case.
…abels A profile's namespace and release_name replace the names derived from its suffix, an org's app_secret_name replaces <org>-github-app, and a profile's scale_set_labels sets the whole scaleSetLabels list in place of runs_on_label, with an empty list setting none so that jobs target the release name. Left unset, every name and label is derived exactly as before. Validation still requires valid Kubernetes names, and now also rejects two of an org's profiles sharing a release name, since that is the scale set's name on GitHub. A profile's own max_runners now sets maxRunners through the role's overlay, so it applies with a values file too and takes precedence over sizing. The expanded profile carries the resulting value, which is sizing's ceiling on an ordinary profile without max_runners, as before.
meta/argument_specs.yml lists every variable the role reads, with its type and purpose, so ansible-doc can show them and a wrongly typed value fails when the role starts. Org and profile entries are described but not restricted key by key, because the arc_profiles filter already checks their structure.
|
🎉 This PR is included in version 1.1.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The ARC role could only manage an install it had created itself: the controller was always release
arcinactions-runner-controller, each scale set<org>-runners<suffix>inarc-runners-<org><suffix>, the App Secret<org>-github-app, and every release got ascaleSetLabelsentry. Pointed at a cluster whose ARC install uses its own names, it would install a second controller and scale set next to the existing ones. This makes each of those names configurable so the role can upgrade an existing install in place.New settings:
github_runner_arc_controller_release_nameandgithub_runner_arc_controller_namespace(defaultsarcandactions-runner-controller). The controller install, its anti-affinity selector, the stale-listener lookup, the heartbeat's RBAC and the platform's namespace list all use them.scripts/heartbeat.shreads the controller namespace fromHEARTBEAT_CONTROLLER_NAMESPACE; the role only passes it when it isn't the default, so the heartbeat Deployment is untouched for existing configurations. A non-default namespace needs a heartbeat image built from this change.namespaceandrelease_nameoverride the suffix-derived names; per org,app_secret_nameoverrides<org>-github-app. The autoscaler's RBAC and environment, and the Secret checks, follow them through the expanded profile.scale_set_labelssets the wholescaleSetLabelslist in place ofruns_on_label. An empty list sets none, for installs whose jobs target the release name.github_runner_arc_manage_image_pull_secret(followsgithub_runner_arc_manage_secrets) lets the role use a pull Secret something else creates and keeps current, by name, without a registry credential. Withgithub_runner_arc_manage_secretsfalse the role also stops resolving the installation ID, which only ever went into the App Secret.max_runnersnow setsmaxRunnersthrough the overlay, so it applies with a values file too and takes precedence oversizing. Before, it was only read by the role's default values template, andsizingoverrode it.Validation also rejects two of an org's profiles sharing a release name (it's the scale set's name on GitHub) and invalid controller names. The role now has a
meta/argument_specs.ymlcovering all its variables; org and profile entries are left to the filter's own checks. The role README has a section on managing an existing install.Every default reproduces the previous names, so a fleet that sets none of these sees no change. I checked that by running a fleet's
arc.yml --check --diffwith helm-diff on the host, once against the released 1.0.2 collection and once against this branch built on 1.0.2: both report the controller release, both scale-set releases, the heartbeat and autoscaler Deployments and every Secret and RBAC object asok, and the only difference in the task list is the new validation item and the argument spec check. After rebasing onto 1.0.3 the result is the same once the platform images are held at 1.0.2.For the other direction I mapped an existing install with its own controller and scale-set names, an out-of-band App Secret and pull Secret, no
scaleSetLabelsand an externally computed runner ceiling onto these settings, ran the role's validation and rendered its controller and scale-set values locally (no cluster involved). The release names, namespaces, Secret names,--setvalues and merged Helm values came out identical to what that install currently deploys.yamllint, ansible-lint (production profile), the playbook syntax checks, the unit tests (new ones cover the name overrides, label lists and
max_runnersprecedence and validation) and the collection build all pass locally.