Skip to content

feat(hatchet-api): optional stable-named Helm hooks for install jobs - #75

Open
DrFaust92 wants to merge 3 commits into
hatchet-dev:mainfrom
DrFaust92:setup-job-stable-hook
Open

feat(hatchet-api): optional stable-named Helm hooks for install jobs#75
DrFaust92 wants to merge 3 commits into
hatchet-dev:mainfrom
DrFaust92:setup-job-stable-hook

Conversation

@DrFaust92

Copy link
Copy Markdown
Contributor

Problem

The setup and worker-token Jobs (charts/hatchet-api/templates/setup-job.yaml) are plain resources named with a randAlphaNum suffix, so they render a new name on every template pass. GitOps controllers like ArgoCD always render with .Release.IsInstall=true, so they see a brand-new Job on every reconcile — producing perpetual drift and a pile of orphaned Jobs in the namespace.

Change

Adds an opt-in installJobsAsHooks flag (default false → no behaviour change for a normal helm install/upgrade).

When true:

  • the setup and worker-token Jobs get stable names (<fullname>-setup, <fullname>-worker-token)
  • they gain pre-install,pre-upgrade hook annotations with a before-hook-creation delete policy (respecting retainFailedHooks)
  • their Role/RoleBinding become hooks at a lower weight so RBAC exists before the Jobs run

This mirrors the existing pre-upgrade migration hook and lets GitOps users deploy without drift or orphaned Jobs.

Note for maintainers

With the flag on, the setup Job runs at hook time referencing the chart ServiceAccount (a normal resource). This matches the assumption the existing pre-upgrade migration hook already makes. Happy to also gate the ServiceAccount as a hook if you'd prefer full first-helm install coverage.

Testing

  • helm lint clean
  • default render: random names, no hook annotations (unchanged)
  • installJobsAsHooks=true render: stable names + hooks on Role, RoleBinding, setup Job, worker-token Job

The setup and worker-token Jobs are plain resources named with a
randAlphaNum suffix, so they render a new name on every template pass.
GitOps controllers (e.g. ArgoCD, which always renders with
.Release.IsInstall=true) therefore see a brand-new Job on every reconcile,
producing perpetual drift and a pile of orphaned Jobs.

Add an opt-in installJobsAsHooks flag (default false, no behaviour change
for helm install/upgrade). When true, the setup and worker-token Jobs get
stable names and pre-install/pre-upgrade hook annotations with
before-hook-creation delete policy, and their Role/RoleBinding become hooks
at a lower weight so RBAC exists before the Jobs run. This mirrors the
existing pre-upgrade migration hook and lets GitOps users deploy without
drift.

Signed-off-by: Ilia Lazebnik <ilia.lazebnik@gmail.com>
Signed-off-by: Ilia Lazebnik <ilia.lazebnik@gmail.com>
Signed-off-by: Ilia Lazebnik <ilia.lazebnik@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant