Portability · 04 of 06 · The proof

One release, start to finish, on GitLab

This is the acceptance test for phase 3: a new Skyport service, scaffolded from Tower, built, signed, released to a Flight environment and rolled back, with no GitHub anywhere in the path. Every step already exists on GitHub; the only new parts are the drivers.

One release, start to finish, on GitLab Sequence diagram across five lifelines: developer, GitLab, Glidepath, registry and Argo CD. The developer pushes and opens a merge request; GitLab sends a project webhook to Glidepath; Glidepath pushes the image and its signature to the registry and posts a commit status back. The developer merges; GitLab sends a tag event; Glidepath opens a release merge request on the gitops repo; GitLab sends the merge request event and Glidepath posts a status per gate. The developer approves and merges through the protected branch, the merge gate, highlighted. Argo CD pulls the gitops repo and pulls the image by digest from the registry. PUSH + MRWEBHOOKIMAGE + SIGSTATUSMERGETAG EVENTRELEASE MRMR EVENTGATE STATUSESAPPROVE + MERGEPULL GITOPS REPOPULL BY DIGESTDevelopersigned commitsGitLabapp + gitops-<app>GlidepathPaC + Tekton + brokerRegistryGitLab CR or HarborArgo CDthe target clusterLEGENDEvent or callStatus or pullThe merge gateUnchanged engine

Principle honored

Glidepath's engine does not change. Pipelines as Code already accepts GitLab webhooks and reports commit statuses, and Argo CD already pulls from any git host.

What changes

  • The webhook is per project, so onboarding creates it as an scm.hangar.io Webhook.
  • The merge gate is a protected branch with required approvals and "pipelines must succeed".
  • Release MR, comments and statuses go through the scm CLI.

Done when

Not run yet. The lab has no GitLab group. Phase 3 is done when this sequence has run live, end to end, including a rollback, and the merge gate refused a merge with a red gate.

Hangar · Portability