Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions .controlplane/docs/testing-cpflow-github-actions.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Comment on lines +25 to +26
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Qualify claim that every wrapper has two upstream pins

This states that each generated cpflow-* wrapper has both uses: ...@<ref> and control_plane_flow_ref, but that is not true for all generated wrappers in this repo (for example, .github/workflows/cpflow-review-app-help.yml and .github/workflows/cpflow-help-command.yml only pin the uses ref). Following this wording when repinning could lead maintainers to add an unsupported with.control_plane_flow_ref input to workflows that do not accept it, causing workflow-call validation failures.

Useful? React with 👍 / 👎.


```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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The 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
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.

## Local Checks

After regenerating the flow, run these checks from the repository root. If
Expand Down
16 changes: 16 additions & 0 deletions .controlplane/readme.md
Original file line number Diff line number Diff line change
Expand Up @@ -421,6 +421,22 @@ GitHub Actions flow, update a project by regenerating the flow from the desired
`cpflow` version or branch, reviewing the diff, and keeping any local app names,
repository variables, secrets, and docs aligned with `.controlplane/controlplane.yml`.

The generated workflows are intentionally thin wrappers around reusable
workflows in `shakacode/control-plane-flow`. GitHub loads reusable workflows from
a repository ref, not from the Ruby gem, so each wrapper has a `uses: ...@<ref>`
line plus a matching `control_plane_flow_ref: <ref>`. For stable releases,
generate these files from a released `cpflow` gem; the default ref is the
matching upstream release tag, `v<gem version>`. Avoid `main` or feature-branch
refs in production. Use an immutable commit SHA only when testing unreleased
upstream changes, then move back to the release tag after the upstream release
is published.

`CPFLOW_VERSION` is a runtime gem-install override. When it is unset, the setup
action builds `cpflow` from the checked-out upstream ref. When it is set, the
setup action installs that RubyGems version instead. For normal release pins,
either leave it unset while using the matching `v<version>` workflow tag, or set
it to the same gem version without the leading `v`.

For this app, validate a regenerated flow with:

```bash
Expand Down
12 changes: 11 additions & 1 deletion .controlplane/shakacode-team.md
Original file line number Diff line number Diff line change
Expand Up @@ -51,7 +51,9 @@ Optional repository settings:
- `DOCKER_BUILD_EXTRA_ARGS`: newline-delimited Docker build tokens, such as `--build-arg=FOO=bar`.
- `DOCKER_BUILD_SSH_KNOWN_HOSTS`: custom `known_hosts` entries when SSH build hosts are not GitHub.com.
- `CPLN_CLI_VERSION`: pin a specific `@controlplane/cli` version; defaults to the generated action pin.
- `CPFLOW_VERSION`: pin a specific cpflow gem version; defaults to the generated action pin.
- `CPFLOW_VERSION`: optional runtime gem-install override. When unset, workflows build
`cpflow` from the checked-out upstream workflow ref. When set, use the RubyGems
version number without a leading `v`.
- `HEALTH_CHECK_ACCEPTED_STATUSES`: production promotion health statuses; defaults to `200 301 302`.
- `HEALTH_CHECK_RETRIES` / `HEALTH_CHECK_INTERVAL`: production health polling controls; defaults to `24` retries and `15` seconds.
- `ROLLBACK_READINESS_RETRIES` / `ROLLBACK_READINESS_INTERVAL`: post-rollback health polling controls; defaults to `24` retries and `15` seconds.
Expand All @@ -71,6 +73,14 @@ that the deploy workflow checks out trusted local actions from `master` before
passing Control Plane secrets; PR-branch composite action changes are not fully
tested until they land on `master` and a real review-app deploy is rerun.

Generated workflow wrappers point to upstream reusable workflows with
`uses: shakacode/control-plane-flow/...@<ref>` and pass the same
`control_plane_flow_ref`. For stable releases, `<ref>` should be the
`v<cpflow gem version>` tag produced by the released gem. Do not use `main` or a
feature branch for production automation. A commit SHA is acceptable for
unreleased testing, but regenerate or repin to the release tag once the upstream
release exists.

See [readme.md](readme.md) and
[Testing cpflow GitHub Actions Changes](docs/testing-cpflow-github-actions.md)
for more details.
Expand Down
2 changes: 1 addition & 1 deletion .github/cpflow-help.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ You asked for review app help. These commands are generated by [cpflow](https://
| `DOCKER_BUILD_SSH_KNOWN_HOSTS` | optional | SSH known_hosts entries when SSH build hosts are not GitHub.com. |
| `HEALTH_CHECK_ACCEPTED_STATUSES` | optional | Space-separated HTTP statuses considered healthy on promote (default `200 301 302`). |
| `CPLN_CLI_VERSION` | optional | Pin a specific `@controlplane/cli` version; falls back to the action default when unset. |
| `CPFLOW_VERSION` | optional | Pin a specific cpflow gem version; falls back to the generated default when unset. |
| `CPFLOW_VERSION` | optional | Runtime gem-install override. When unset, cpflow is built from the pinned upstream workflow ref. When set, use the RubyGems version without a leading `v`. |

</details>

Expand Down
Loading