Repository navigation
v5.7.0
Minor Changes
-
New top-level
reviewAppsconfig: decide whether merge/pull requests deploy their review apps — every MR/PR (deploy: "auto", default), opt-in or opt-out by label (optIn/optOut, labelscatladder:review-app/catladder:no-review-app), or only on request (manual) — and what drafts run (drafts: "likeReady" | "checksOnly" | "skip"). With anything but the defaults, the docker → deploy → verify chains of all components wait for one switch per MR/PR, so pipelines no longer build docker images for review apps nobody deploys; tests, lint and audit always run.- GitHub: like gitlab, the review workflow decides at its start from the PR's labels and draft state and deploys in the same run (one app build) when the policy says so. Later changes go through a new
▶️ catladder deploy reviewworkflow: the review workflow dispatches it once green when the policy now says deploy but the run didn't, switching the label on deploys right away (off stops the review apps), and anyone can dispatch it with a PR number (gh workflow run catladder-deploy-review.yml --ref <branch> -f pr=<n>). Its guard reuses the PR's greencatladder ✅instead of rerunning tests.catladder review app ✅, the last job of whichever run deploys, is the stable result for merge gates and is also reported as the commit statuscatladder review appon the PR (dispatched runs aren't listed on pull requests otherwise). - GitLab: a
🚀 deploy reviewjob is the switch — automatic or manual depending on labels and draft state, withallow_failureso an unplayed switch keeps the pipeline green.catladder mr review-app-on/review-app-offset the label and trigger a pipeline (gitlab doesn't start one for label changes).
Fix: on GitHub, a review deploy with
when: "manual"no longer removes the whole review workflow (tests, lint and the requiredcatladder ✅check disappeared) and no longer deploys to a shared…-review-unknowninstance — it now runs through the same review deploy workflow with the PR number. - GitHub: like gitlab, the review workflow decides at its start from the PR's labels and draft state and deploys in the same run (one app build) when the policy says so. Later changes go through a new