-
Notifications
You must be signed in to change notification settings - Fork 374
Document cpflow upstream ref pinning #743
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -18,6 +18,48 @@ Control Plane secrets to local composite actions. A PR branch can contain fixed | |||||||||||||||
| `.github/actions/*` files, but the deploy job still loads those local actions | ||||||||||||||||
| from `master` until the fix is merged there. | ||||||||||||||||
|
|
||||||||||||||||
| ## How Upstream Code Is Pinned | ||||||||||||||||
|
|
||||||||||||||||
| Generated `cpflow-*` workflows are thin wrappers around reusable workflows in | ||||||||||||||||
| `shakacode/control-plane-flow`. GitHub reusable workflows cannot be loaded from | ||||||||||||||||
| a Ruby gem; GitHub resolves them from a repository ref. Each wrapper therefore | ||||||||||||||||
| has two upstream pins that must stay in sync: | ||||||||||||||||
|
|
||||||||||||||||
| ```yaml | ||||||||||||||||
| uses: shakacode/control-plane-flow/.github/workflows/cpflow-deploy-review-app.yml@<ref> | ||||||||||||||||
| with: | ||||||||||||||||
| control_plane_flow_ref: <ref> | ||||||||||||||||
| ``` | ||||||||||||||||
|
|
||||||||||||||||
| `uses: ...@<ref>` chooses the reusable workflow file. `control_plane_flow_ref` | ||||||||||||||||
| chooses the same upstream checkout for shared composite actions and, when | ||||||||||||||||
| `CPFLOW_VERSION` is unset, the source used to build and install the `cpflow` gem | ||||||||||||||||
| inside the workflow. | ||||||||||||||||
|
|
||||||||||||||||
| The stable release path is still gem-driven: | ||||||||||||||||
|
|
||||||||||||||||
| 1. Install or update to a released `cpflow` gem. | ||||||||||||||||
| 2. Run `cpflow generate-github-actions --staging-branch master`. | ||||||||||||||||
| 3. The generated wrappers use `v<cpflow gem version>` as the upstream ref. | ||||||||||||||||
|
|
||||||||||||||||
| That tag should point to the same source that produced the RubyGems release, so | ||||||||||||||||
| the workflow code is locked to a release tag rather than a moving branch. Do not | ||||||||||||||||
| pin production workflows to `main` or a feature branch. For unreleased testing, | ||||||||||||||||
| pin to an immutable commit SHA, not a branch name, then regenerate or repin to | ||||||||||||||||
| the release tag after the upstream release is published. | ||||||||||||||||
|
|
||||||||||||||||
| `CPFLOW_VERSION` is separate from the GitHub workflow ref. If the repository | ||||||||||||||||
| variable is set, the setup action runs `gem install cpflow -v <version>`. If it | ||||||||||||||||
| is unset, the setup action builds `cpflow` from the checked-out upstream ref. | ||||||||||||||||
| For normal releases, either leave `CPFLOW_VERSION` unset while using the matching | ||||||||||||||||
| `v<version>` upstream tag, or set `CPFLOW_VERSION` to the same released gem | ||||||||||||||||
| version without the leading `v`. | ||||||||||||||||
|
|
||||||||||||||||
| This repo is currently pinned to an upstream commit SHA because the reusable | ||||||||||||||||
| workflow change was tested before a new `cpflow` gem release existed. That is | ||||||||||||||||
| safer than pinning a branch, but it should be treated as a temporary test pin | ||||||||||||||||
| until the next upstream release tag is available. | ||||||||||||||||
|
|
||||||||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This paragraph describes a transient repo state ("currently pinned to an upstream commit SHA") that will become factually wrong once the upstream release is published and the pin is updated to a release tag. Recommend either removing it entirely (the general guidance above it is sufficient) or converting to an HTML comment so it is hidden from rendered docs but easy to find and delete later:
Suggested change
|
||||||||||||||||
| ## Local Checks | ||||||||||||||||
|
|
||||||||||||||||
| After regenerating the flow, run these checks from the repository root. If | ||||||||||||||||
|
|
||||||||||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This states that each generated
cpflow-*wrapper has bothuses: ...@<ref>andcontrol_plane_flow_ref, but that is not true for all generated wrappers in this repo (for example,.github/workflows/cpflow-review-app-help.ymland.github/workflows/cpflow-help-command.ymlonly pin theusesref). Following this wording when repinning could lead maintainers to add an unsupportedwith.control_plane_flow_refinput to workflows that do not accept it, causing workflow-call validation failures.Useful? React with 👍 / 👎.