Skip to content

ci(jobnik-manager): drive the delivery pipeline off a generated matrix - #11

Open
CptSchnitz wants to merge 2 commits into
migration/08-release-configfrom
migration/09-delivery-pipeline
Open

ci(jobnik-manager): drive the delivery pipeline off a generated matrix#11
CptSchnitz wants to merge 2 commits into
migration/08-release-configfrom
migration/09-delivery-pipeline

Conversation

@CptSchnitz

Copy link
Copy Markdown
Collaborator

Replace the placeholder build with the manager's own former delivery
pipeline (fetched from the now-frozen jobnik-manager repo's
.github/workflows/build-and-push.yaml, since it predates this
monorepo's history), kept exactly as it stood: push-to-next is dev,
a prerelease GitHub release is qa, a stable release is prod, each
opens a site-values PR under the same labels and target paths, and a
stable release additionally syncs qa/integration.

Two adaptations, both required by the move into this monorepo:

  • The container build is now a generated matrix
    (scripts/generate-matrix.mjs, ported from the reference monorepo)
    over every apps/* package that declares a dockerfile field (ticket
    05 already added that field to jobnik-manager). The image is pushed
    under the matrix's service (the package name, "jobnik-manager"),
    not the repository name -- the repository is now named for the
    product, so the old repository-name-derived image tag would resolve
    to "jobnik" instead. The chart push and the site-values chart
    input still use the repository name unchanged, since that now
    correctly resolves to the umbrella chart's own name for free.

  • The release trigger only proceeds past tags matching jobnik-v*.
    Ticket 08's linked-versions group means one version bump produces a
    separate release, and a separate tag, for jobnik, jobnik-manager and
    jobnik-openapi alike; without a guard this pipeline would run three
    times per bump. The root component's tag is the one guarded on,
    since it's the one that means "a deployment is described by a
    single number" regardless of how many apps eventually join the
    matrix. Its jobnik- prefix is stripped before use, so the
    resulting image/chart tag scheme is unchanged from before.

Also moved the carried-over "skip bot commits" step's use of
github.event.head_commit.message into an env var -- actionlint
flagged the direct interpolation as a script-injection risk on
untrusted input; behavior is unchanged.

Refs: .scratch/monorepo-migration/issues/09-manager-delivery-pipeline.md

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com


Stack created with GitHub Stacks CLIGive Feedback 💬

Replace the placeholder build with the manager's own former delivery
pipeline (fetched from the now-frozen jobnik-manager repo's
.github/workflows/build-and-push.yaml, since it predates this
monorepo's history), kept exactly as it stood: push-to-next is dev,
a prerelease GitHub release is qa, a stable release is prod, each
opens a site-values PR under the same labels and target paths, and a
stable release additionally syncs qa/integration.

Two adaptations, both required by the move into this monorepo:

- The container build is now a generated matrix
  (scripts/generate-matrix.mjs, ported from the reference monorepo)
  over every apps/* package that declares a `dockerfile` field (ticket
  05 already added that field to jobnik-manager). The image is pushed
  under the matrix's `service` (the package name, "jobnik-manager"),
  not the repository name -- the repository is now named for the
  product, so the old repository-name-derived image tag would resolve
  to "jobnik" instead. The chart push and the site-values `chart`
  input still use the repository name unchanged, since that now
  correctly resolves to the umbrella chart's own name for free.

- The release trigger only proceeds past tags matching `jobnik-v*`.
  Ticket 08's linked-versions group means one version bump produces a
  separate release, and a separate tag, for jobnik, jobnik-manager and
  jobnik-openapi alike; without a guard this pipeline would run three
  times per bump. The root component's tag is the one guarded on,
  since it's the one that means "a deployment is described by a
  single number" regardless of how many apps eventually join the
  matrix. Its `jobnik-` prefix is stripped before use, so the
  resulting image/chart tag scheme is unchanged from before.

Also moved the carried-over "skip bot commits" step's use of
github.event.head_commit.message into an env var -- actionlint
flagged the direct interpolation as a script-injection risk on
untrusted input; behavior is unchanged.

Refs: .scratch/monorepo-migration/issues/09-manager-delivery-pipeline.md

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Aug 23, 2026

Copy link
Copy Markdown

Coverage Report for apps/jobnik-manager

Status Category Percentage Covered / Total
🟢 Lines 100% (🎯 80%) 767 / 767
🟢 Statements 100% (🎯 80%) 784 / 784
🟢 Functions 100% (🎯 80%) 112 / 112
🟢 Branches 100% (🎯 80%) 219 / 219
File CoverageNo changed files found.
Generated in workflow #9 for commit 10dcfc9 by the Vitest Coverage Report Action

Follow-up from code review: the previous commit fixed the "skip bot
commits" step's use of the untrusted commit message by routing it
through env:, but left the release tag name -- the same kind of
event-supplied string, used right next to it and again in the config
step -- interpolated directly into the shell script. Same fix, same
reasoning, for consistency.

Also correct a checkbox this ticket had marked complete: the
deployment-configuration change can't actually land from this
repository (site-values isn't part of this monorepo), so it's left
unchecked with a note pointing at the prepared change and at whoever
applies it.

Refs: .scratch/monorepo-migration/issues/09-manager-delivery-pipeline.md

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@CptSchnitz
CptSchnitz marked this pull request as ready for review August 23, 2026 13:16
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