Environments: staging, prod and the rest as hub objects pipelines deploy to issue #86
open andymccall opened this · 1 comment
andymccall
Andy (2026-10-26): pipelines have no idea of environments yet, and a deploy to production should be the same release that staging tested. To come back to with the GCP deployment work (issue #5 board). First of three: this, then release bundles, then promotion and air-gapped import.
Environments are hub objects, not pipeline text. An organisation or repository defines staging, prod and so on, each with:
its own variables and secrets (crate::levels gains an environment level, nearest wins as today);
protection: who must approve a deploy into it (sealed approvals, as landing has), and which bookmarks may deploy to it;
which runners may serve it: a label or pool, so prod's jobs run only on runners inside prod's network;
a deployment history: what is live there (state, run, artifacts by hash), who put it there and when, with rollback to an earlier entry.
The pipeline only refers to one:
job "deploy-prod" {
environment "prod" // its secrets, approvals and runners come from the hub
needs "bundle"
network "isolated"
}
A job naming an environment waits for its approvals (a run state like "waiting for approval"), gets only that environment's secrets, is placed only on its runners, and on success records a deployment. Jobs without environment are unchanged.
Pages: Settings › Environments (define, protect, runners); a repository's Deployments page (what is where, history, promote, roll back); the run page shows a job's environment and its approval.
Open questions: environments per repository or per organisation (probably both, as variables are); whether oh gets oh deploy list/approve.
Andy (2026-10-26): pipelines have no idea of environments yet, and a deploy to production should be the same release that staging tested. To come back to with the GCP deployment work (issue #5 board). First of three: this, then release bundles, then promotion and air-gapped import.
Environments are hub objects, not pipeline text. An organisation or repository defines
staging,prodand so on, each with:crate::levelsgains an environment level, nearest wins as today);The pipeline only refers to one:
A job naming an environment waits for its approvals (a run state like "waiting for approval"), gets only that environment's secrets, is placed only on its runners, and on success records a deployment. Jobs without
environmentare unchanged.Pages: Settings › Environments (define, protect, runners); a repository's Deployments page (what is where, history, promote, roll back); the run page shows a job's environment and its approval.
Open questions: environments per repository or per organisation (probably both, as variables are); whether
ohgetsoh deploy list/approve.