fix(platform_engineer): ask release policy before automation#335
fix(platform_engineer): ask release policy before automation#335
Conversation
There was a problem hiding this comment.
Pull request overview
Updates the platform_engineer job’s release-building guidance to ensure release automation is driven by explicitly confirmed project release policy (cadence, semantics, branching/stabilization, backports, hotfixes, publish targets) rather than implicit tooling defaults.
Changes:
- Adds an explicit “confirm release policy first” step to
setup_release_pipeline, and records the policy inrelease_docs.md. - Extends
audit_releaseto assess/record whether release policy decisions are already explicit vs. gaps requiring user input. - Tightens workflow/job review requirements to check that produced configs + docs (including AGENTS docs) match the confirmed policy.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
library/jobs/platform_engineer/steps/setup_release_pipeline.md |
Adds a required policy-confirmation phase and strengthens doc/AGENTS surfacing expectations before writing automation. |
library/jobs/platform_engineer/steps/audit_release.md |
Adds a release-policy clarity section and requires capturing unresolved policy gaps for the setup step. |
library/jobs/platform_engineer/job.yml |
Updates workflow instructions and process requirements; adds/extends output review criteria to validate policy/docs/config coherence. |
library/jobs/platform_engineer/AGENTS.md |
Documents learnings emphasizing policy-first automation and where release guidance should live. |
| - Merge-back policy: whether release or hotfix branches must merge back to the main development line | ||
| - Publish targets: GitHub Releases, Forgejo releases, registries, container images, Nix flake consumption, or other artifacts | ||
| - Consumer guidance: what users should treat as unstable versus stable (for example, `main` versus tags) |
There was a problem hiding this comment.
Step 1a includes “Publish targets” as part of the release policy to confirm up front, but later in this step the workflow still instructs using AskUserQuestion to determine publish targets during CI workflow creation. That creates conflicting guidance and can lead to asking the same question twice; please clarify one source of truth (e.g., in the CI workflow section, only ask if publish targets weren’t fully resolved in 1a, otherwise reuse the confirmed policy decisions).
| (To be populated after workflow executions) | ||
| - `release_builder` should follow the repository's standard docs convention for the canonical release doc when one exists; otherwise use `docs/releases.md` or `docs/platform/releases.md`. Keep the root `AGENTS.md` concise by linking to that doc instead of duplicating release details. | ||
| - CI-provider-specific release behavior belongs in `.github/AGENTS.md` and/or `.forgejo/AGENTS.md`. Those files should explain workflow entrypoints, required secrets, and release-specific CI expectations, while the root `AGENTS.md` only points to them. | ||
| - `release_builder` must ask the user to define the release policy before wiring automation when cadence, version semantics, stabilization, backports, hotfixes, merge-back, publish targets, or stable-versus-unstable consumption are not already explicit in the repo. The job should implement the chosen policy, not infer one from tooling defaults. |
There was a problem hiding this comment.
Terminology is inconsistent with the rest of the release policy wording in this job: elsewhere it uses “stable-vs-unstable” (and “stable vs unstable”), but here it says “stable-versus-unstable”. Standardizing on one phrase will make searching/cross-referencing across instructions and artifacts more reliable.
| - `release_builder` must ask the user to define the release policy before wiring automation when cadence, version semantics, stabilization, backports, hotfixes, merge-back, publish targets, or stable-versus-unstable consumption are not already explicit in the repo. The job should implement the chosen policy, not infer one from tooling defaults. | |
| - `release_builder` must ask the user to define the release policy before wiring automation when cadence, version semantics, stabilization, backports, hotfixes, merge-back, publish targets, or stable-vs-unstable consumption are not already explicit in the repo. The job should implement the chosen policy, not infer one from tooling defaults. |
No description provided.