openova/.github
e3mrah db332f6767
fix(ci): services-build auto-bumps chart patch + dispatches blueprint-release (#874)
* fix(bp-catalyst-platform): bump 1.4.8 -> 1.4.9 to republish with current services-auth image (#871)

Chart 1.4.8 was published from commit 95a06f56 BEFORE the deploy-bot
updated templates/sme-services/auth.yaml's image pin from
services-auth:fa4395f -> services-auth:95a06f5 (which has the
/auth/send-pin alias from PR #869). The blueprint-release workflow
fired on 95a06f56 only, so the OCI artifact for 1.4.8 was published
with the OLD image SHA in chart bytes. otech103 reconciled 1.4.8 and
rendered the auth Deployment with the OLD image -> /auth/send-pin
returns 404 -> SME marketplace signup blocked.

Same deploy-step race documented in feedback_idempotent_iac_purge.md
and the overnight DoD bookmark. Long-term fix is a double-bump
sequencing PR (file separately); short-term fix is bumping the chart
version so blueprint-release republishes the artifact with the
current image pin.

No template change. Lockstep slot 13 pin in
clusters/_template/bootstrap-kit/13-bp-catalyst-platform.yaml bumps
from 1.4.8 -> 1.4.9.

Closes #871

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(ci): services-build deploy auto-bumps chart patch + dispatches blueprint-release (#872)

Eliminate the recurring race between services-build's deploy commit
and blueprint-release's path-trigger on chart-version-bumping PRs.

Before: a PR bumping `products/catalyst/chart/Chart.yaml` AND touching
`core/services/**` triggered both workflows on the same merge SHA in
parallel. blueprint-release packaged the chart at the merge commit
(which still held the OLD image SHAs) and published the bumped
chart version with stale image refs. services-build's deploy commit
landed AFTER, but per GitHub Actions design GITHUB_TOKEN-authored
pushes do NOT re-trigger workflows, so blueprint-release never fired
again on the corrected chart. A manual no-op chart bump PR was the
only way to republish (PR #865 chasing PR #864 was the live incident).

After: services-build's deploy step
  1. sed-rewrites image: lines under products/catalyst/chart/templates/sme-services/*.yaml (unchanged)
  2. Pure-bash semver patch-bumps Chart.yaml `version:` and `appVersion:` atomically
  3. Single commit captures both rewrites
  4. Explicit `gh workflow run blueprint-release.yaml -f blueprint=catalyst -f tree=products` dispatches the chart publish (matches catalyst-build's PR #720 pattern)
  5. Idempotent push retry re-reads origin/main and bumps from THAT version on conflict, so concurrent CI runs produce strictly increasing patch versions instead of clobbering each other

Adds `actions: write` to the deploy job permissions so the
gh workflow run dispatch doesn't return HTTP 403.

The manual chart-version field in author PRs becomes a floor; CI
auto-bumps from there. PR authors should NOT bump the patch
themselves any more — the deploy step does it. Major/minor bumps
remain the author's call.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: hatiyildiz <hatice.yildiz@openova.io>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-05 08:32:34 +04:00
..
workflows fix(ci): services-build auto-bumps chart patch + dispatches blueprint-release (#874) 2026-05-05 08:32:34 +04:00
dependabot.yml chore(ci): add Dependabot for npm and GitHub Actions dependency updates 2026-03-19 13:42:02 +01:00