## TL;DR Follow-up to gitlab-com/gl-infra/delivery#22049 based on https://gitlab.com/gitlab-com/gl-infra/delivery/-/work_items/22049#note_3366862966. The publish-stage smart sync currently syncs runway Helm charts but not fairway charts or the GitLab Release page. Adjust the sync targets: drop runway chart sync, add fairway chart sync, add release page sync. TUBE artifacts stay unsynced by design. ## Problem / Goal Audit of `release-platform-canary` post-merge shows: | Artifact | Synced today | Should sync? | |----------|--------------|--------------| | Docker container image | :white_check_mark: | :white_check_mark: keep | | Runway Helm chart (`oci://.../chart/<service-id>`) | :white_check_mark: | :x: drop (runway going away) | | Fairway Helm chart (`oci://.../<metadata.name>`) | :x: | :white_check_mark: add | | GitLab Release page (changelog, asset links) | :x: | :white_check_mark: add | | TUBE artifacts (intermediate binary builds) | :x: | :x: keep unsynced -- intermediate format, not customer-distributed, doubles storage | | Generic packages from goreleaser | :white_check_mark: | :white_check_mark: keep -- `sync-packages` filters by `package_name=${CI_PROJECT_NAME}` which goreleaser uses; TUBE publishes under different names so it's naturally excluded. No change needed in this issue. | ## Background / Context Release-platform consumers are moving from runway Helm charts to fairway-generated Helm charts. The chart path differs: - Runway: `oci://registry.gitlab.com/<project>/chart/<runway_service_id>:<tag-no-v>` - Fairway: `oci://registry.gitlab.com/<project>/<metadata.name-from-manifest>:<tag-no-v>` The current `sync-registry-artifacts` job in [common-ci-tasks/release-platform.jsonnet](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/blob/main/src/ci/components/release-platform.jsonnet) hard-codes the runway path. Replace with the fairway path (deriving `metadata.name` from `.fairway/manifest.yaml` or a component input). The GitLab Release page is currently created only on the security mirror (where goreleaser runs) and never propagated to canonical. Customers see no release notes / asset links on the public-facing canonical project. ## Proposed Solution ### 1. Drop runway chart sync Remove the second `skopeo copy` invocation in `sync-registry-artifacts` (the one targeting `/chart/<name>`). Keep the container image copy. ### 2. Add fairway chart sync Parse `$[[ inputs.fairway_manifest ]]` at runtime via `yq` to extract `.metadata.name`, then skopeo-copy: ``` docker://registry.gitlab.com/<security-path>/chart/<metadata.name>:<tag-no-v> docker://registry.gitlab.com/<canonical-path>/chart/<metadata.name>:<tag-no-v> ``` Manifest is the single source of truth (matches how Fairway itself derives the chart name). Sync image gains a `yq` install. No new component input. ### 3. Add release page sync New `sync-release-page` job in the `sync-artifacts` stage, parallel to `sync-registry-artifacts` and `sync-packages`. Copies the GitLab Release (changelog + asset links) from security to canonical via the [Releases API](https://docs.gitlab.com/ee/api/releases/): 1. `GET /projects/${CI_PROJECT_ID}/releases/${CI_COMMIT_TAG}` -- fetch source release (uses `CANONICAL_REPO_TOKEN`, api scope, SA has Developer access on security) 2. Rewrite security URLs to canonical URLs in `description` and `assets.links[].url`. Single-pass string replace covering both raw (`gitlab-org/security/<X>`) and URL-encoded (`gitlab-org%2Fsecurity%2F<X>`) forms. 3. `POST /projects/${CANONICAL_PROJECT_ID}/releases` -- create on canonical with rewritten fields. Treat HTTP 409 (release already exists) as success; do not update existing release pages (covers idempotent retry). ### 4. TUBE artifacts -- explicitly NOT synced Intermediate binary builds. Not customer-distributed (we ship Chart + Container). Doubling storage cost isn't justified. Document the design decision. ### Design decisions resolved | Question | Decision | |---|---| | Fairway chart-name derivation | Runtime parse of `$[[ inputs.fairway_manifest ]]` via yq; manifest is single source of truth | | `fairway_manifest` required? | Yes -- required for release-platform consumers. Runway is being phased out; the migration team is enabling runway deploys of fairway charts. Every release-platform consumer will produce a fairway chart, so the input must be set. Misconfiguration (empty, missing file, missing `.metadata.name`) fails generate-publish-pipeline with a clear error. | | Release-page sync placement | New `sync-release-page` job in `sync-artifacts` stage | | Asset/changelog URL rewriting | Rewrite security paths to canonical (both raw and URL-encoded forms) | | Idempotency on retry | POST; treat HTTP 409 as success; do not update existing | ## Out of Scope - Migration path for projects still on runway charts (separate concern; both pipelines can coexist short-term) - Backfilling release pages on canonical for historical releases - Syncing TUBE artifacts ## Affected Systems - [`gitlab-com/gl-infra/common-ci-tasks`](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks) -- `src/ci/components/release-platform.jsonnet` (sync-registry-artifacts job + possibly new sync-release-page job) - [`gitlab-org/software-delivery/release-platform-canary`](https://gitlab.com/gitlab-org/software-delivery/release-platform-canary) -- validation target ## Dependencies - [common-ci-tasks!1498](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/merge_requests/1498) merged (current sync-commits work) ## Resources - Parent issue: gitlab-com/gl-infra/delivery#22049 - Predecessor: gitlab-com/gl-infra/delivery#22003 - Sibling follow-up: gitlab-com/gl-infra/delivery#22121 (sync-default-branch automation) - Review comment from @nolith: gitlab-com/gl-infra/delivery#22049 (note 3366862966) ## Tasks Work split across three MRs to keep reviews scoped. Order: A and B in parallel; C after both merge. ### MR A -- swap runway chart sync for fairway chart sync ([common-ci-tasks!1551](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/merge_requests/1551)) - [x] In `sync-registry-artifacts`: drop the second `skopeo copy` (`/chart/${CI_PROJECT_NAME}`) - [x] In `generate-publish-pipeline`: install `yq`, parse `$[[ inputs.fairway_manifest ]]` for `.metadata.name`, bake `FAIRWAY_CHART_NAME` into the child pipeline; skopeo-copy `/chart/<metadata.name>:<tag-no-v>` - [x] Make `fairway_manifest` required for release-platform consumers (runway charts are being phased out; the migration team is enabling runway deploys of fairway charts, so every release-platform consumer will produce a fairway chart). Generate-publish-pipeline errors with a clear message if the input is empty, the file is missing, or `.metadata.name` is absent (yq returns literal `"null"` for absent keys; trapped explicitly). - [x] Update manitest assertions (49/49 pass; new assertions lock the fairway path, runway path is dropped, fairway_manifest required, null-key trapped, missing-file trapped) ### MR B -- new `sync-release-page` job ([common-ci-tasks!1573](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/merge_requests/1573)) - [x] Add `sync-release-page` job using `CANONICAL_REPO_TOKEN` (POST; api scope) and `CI_JOB_TOKEN` (GET; same-project) - [x] Place in `sync-commits` stage with `needs: [sync-commits]` -- the tag must exist on canonical before POST `/releases` - [x] GET source release from security mirror, rewrite security paths to canonical (raw + URL-encoded forms via jq `split`/`join` -- literal substitution, not regex) in `description` and `assets.links[].url` - [x] Preserve `released_at` in the POST body so canonical's timestamp matches the original - [x] POST to canonical; treat HTTP 4xx + body `already exists` as idempotent success (5xx fails loud) - [x] Manitest assertions: job exists once; stage + needs (version-independent); split/join rewrite; 4xx idempotency; `released_at` preserved - [x] Validated locally against canary's v1.5.12: GET + jq rewrite + POST (201 first time, 409 + "already exists" on retry) ### MR C -- docs + canary end-to-end validation ([common-ci-tasks!1576](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/merge_requests/1576)) - [x] Update `release-platform.md`: new Synced artifacts table; rewritten Child pipeline structure as stage/job/role table (3 stages, all jobs always emitted with `${SYNC_WHEN}`); `fairway_manifest` marked required when `release_platform_enabled: true`; `sync-release-page` added to `CANONICAL_REPO_TOKEN` consumer list (with `api` scope) - [x] Validate on `release-platform-canary` post-A+B+C: fairway chart at `/chart/<metadata.name>`, no runway chart copied, release page on canonical with rewritten URLs and asset links. Validated via security tag v1.5.15 -- [parent pipeline 2592219626](https://gitlab.com/gitlab-org/security/release-platform-canary/-/pipelines/2592219626) -> [child sync pipeline 2592377845](https://gitlab.com/gitlab-org/security/release-platform-canary/-/pipelines/2592377845). All 7 sync jobs green. Release page now at [`canonical/-/releases/v1.5.15`](https://gitlab.com/gitlab-org/software-delivery/release-platform-canary/-/releases/v1.5.15) with security URLs rewritten to canonical, all 17 assets, and `released_at` preserved. ### Validation incidents and fixes during canary validation Three issues surfaced while validating end-to-end. All fixed and merged before the final green run: | Issue | Symptom | Fix | |---|---|---| | Heredoc shell-expansion of jq `$sec` / `$can` under `set -u` | `generate-publish-pipeline` failed: `/bin/sh: eval: line N: sec: parameter not set` ([job 14771139878](https://gitlab.com/gitlab-org/security/release-platform-canary/-/jobs/14771139878)) | Escape jq vars in jsonnet source -- [common-ci-tasks!1577](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/merge_requests/1577) | | `modular-feature-testing/go-test@v0.1.0` emits `services: [{name: ''}]` which fails YAML lint, breaking scheduled renovate pipelines | Canary's scheduled pipelines failed at config eval with 0 jobs ([pipeline 2588825457](https://gitlab.com/gitlab-org/software-delivery/release-platform-canary/-/pipelines/2588825457)) | Pin `go-test` back to `v0.0.3` + Renovate `allowedVersions: <0.1.0` hold -- [common-ci-tasks!1578](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/merge_requests/1578) | | Renovate bumped `SKOPEO_VERSION` to `1.23.0` but `quay.io/skopeo/stable:v1.23.0` was never published | `sync-registry-artifacts` failed: `manifest unknown` ([job 14796109187](https://gitlab.com/gitlab-org/security/release-platform-canary/-/jobs/14796109187)) | Canary-only override `GL_COMMON_CI_TASKS_SKOPEO_VERSION=1.22.2` via CI/CD variable. Upstream pin-back not yet filed. | ### v1.5.14 manual backfill A security-path tag (v1.5.14) failed `generate-publish-pipeline` before MR A+B fixes landed. The commit was reconciled later via the sync MR ([release-platform-canary!140](https://gitlab.com/gitlab-org/software-delivery/release-platform-canary/-/merge_requests/140)), but the v1.5.14 tag and release page never propagated. Backfilled manually: - v1.5.14 tag created on canonical via `POST /repository/tags` at commit `b96e134a` - v1.5.14 release page POSTed to canonical using the same jq rewrite + POST flow that `sync-release-page` runs ([`canonical/-/releases/v1.5.14`](https://gitlab.com/gitlab-org/software-delivery/release-platform-canary/-/releases/v1.5.14)) ## Acceptance Criteria - [x] Runway chart no longer copied to canonical for any release-platform project ([MR A](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/merge_requests/1551)) - [x] Fairway chart copied to canonical at `<canonical-path>/<metadata.name>:<tag-no-v>` ([MR A](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/merge_requests/1551)); verified on canary v1.5.15 -- chart at `/chart/release-framework-canary:1.5.15` on canonical - [x] GitLab Release page on canonical mirrors the security mirror's release (changelog + assets) for each published release ([MR B](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/merge_requests/1573)); verified on canary v1.5.15 - [x] Validated end-to-end on release-platform-canary -- security tag v1.5.15 -> [child sync pipeline 2592377845](https://gitlab.com/gitlab-org/security/release-platform-canary/-/pipelines/2592377845) all 7 jobs green; convergence demonstrated via sync-MR fallback ([release-platform-canary!140](https://gitlab.com/gitlab-org/software-delivery/release-platform-canary/-/merge_requests/140)) which resolved the owl/tugboat divergence and restored push-mirror flow