22
33These commands are generated by [ cpflow] ( https://github.com/shakacode/control-plane-flow ) .
44For full setup, version-pinning, and troubleshooting details, see the upstream
5- [ CI automation guide] ( https://github.com/shakacode/control-plane-flow/blob/v5.0.1 /docs/ci-automation.md ) .
5+ [ CI automation guide] ( https://github.com/shakacode/control-plane-flow/blob/v5.0.4 /docs/ci-automation.md ) .
66
77## Pull Request Commands
88
@@ -45,10 +45,17 @@ Before the first staging deploy, bootstrap the persistent staging app once:
4545cpflow setup-app -a " $STAGING_APP_NAME " --org " $CPLN_ORG_STAGING " --skip-post-creation-hook
4646```
4747
48- ` setup-app ` creates the app identity, app secret dictionary, app secret policy,
49- policy binding, and template resources. For later template updates on an
50- existing persistent app, use ` cpflow apply-template ` and make sure the app
51- identity has ` reveal ` permission on the app secret policy.
48+ ` setup-app ` reads ` .controlplane/controlplane.yml ` 's ` setup_app_templates ` and
49+ creates the app identity, app secret dictionary, app secret policy, policy
50+ binding, and template resources. Use ` --skip-post-creation-hook ` so first-time
51+ bootstrap does not try to run database setup before an image exists. For later
52+ template updates on an existing persistent app, use ` cpflow apply-template `
53+ with the same template list and make sure the app identity has ` reveal `
54+ permission on the app secret policy.
55+
56+ Review apps are temporary and are created by the ` +review-app-deploy ` workflow,
57+ but staging and production are persistent apps and should be bootstrapped
58+ explicitly.
5259
5360Production promotion is part of the generated flow, but keep it protected:
5461
@@ -69,17 +76,32 @@ production org, using production-only secrets and values.
6976## Version Locking
7077
7178Generated wrappers pin Control Plane Flow once with the reusable workflow
72- ` uses: ` ref, for example ` @v5.0.1 ` . For stable releases, this ref should be a
73- release tag. The upstream reusable workflow automatically
79+ ` uses: ` ref, for example ` @v5.0.4 ` . For stable releases,
80+ this ref should be a release tag. The upstream reusable workflow automatically
7481loads its matching shared actions from GitHub's workflow context, so downstream
7582wrappers should not pass a duplicate Control Plane Flow ref input. If your
7683generated wrappers still include a ` with: ` block whose only purpose is to repeat
7784the same ref, regenerate them with a newer ` cpflow ` .
7885
7986Leave ` CPFLOW_VERSION ` unset so the workflow builds cpflow from the same
8087checked-out upstream source. If you set ` CPFLOW_VERSION ` , it must match the
81- release tag, for example ` CPFLOW_VERSION=5.0.1 ` with a wrapper pinned to
82- ` uses: ...@v5.0.1 ` .
88+ release tag, for example ` CPFLOW_VERSION=5.0.4 ` with a wrapper pinned to
89+ ` uses: ...@v5.0.4 ` .
90+
91+ After updating the ` cpflow ` gem in this repo, update the generated wrappers in
92+ the same PR:
93+
94+ ``` sh
95+ cpflow update-github-actions
96+ bin/test-cpflow-github-flow
97+ ```
98+
99+ If ` cpflow ` is bundled by the app, use:
100+
101+ ``` sh
102+ bundle exec cpflow update-github-actions
103+ bin/test-cpflow-github-flow bundle exec cpflow
104+ ```
83105
84106Do not leave downstream apps pinned to a moving branch such as ` main ` . For a
85107short-lived test of an unreleased upstream PR, pin to a full 40-character commit
0 commit comments