How to onboard a Lameco repo onto the shared pipeline (ci-craft / ci-symfony + deploy-php + Renovate presets). Distilled from the pilots: certo-portal, lameco-craft-website, celsian-website (full stress test, 85→0 advisory burn-down), krt-website (blocked, see failure classes).
scripts/onboarding-preflight.sh <repo>→ fix anything it lists.- Twin PRs (one per long-lived branch — they drift, check BOTH):
.github/workflows/ci.yml— thin caller, current tag (see README).renovate.json— base preset +:renovate-craftfor Craft repos.
- Merge. CI on the wiring PR is the canary: audit gate shows the advisory baseline (ratchet: only NEW advisories fail PRs), PHPStan strict-if-configured.
- Add the repo to
renovate-global.js(or wait for autodiscover once enabled). Canary run:gh workflow run renovate-selfhosted.yml -f repository=Lameco-Development/<repo>. - Security PRs arrive → review + merge greens. The Dependency Dashboard issue has retry/rebase checkboxes for stuck PRs.
- Deploy rails (optional, needs Deployer ^8 + deployer-tasks ^2.2):
deploy.yml(staging) +deploy-production.ymlwhen wanted. Add a required reviewer on theproductionGitHub Environment BEFORE merging that.
| class | symptom | fix |
|---|---|---|
master default branch |
preset routes CVEs to main → nothing lands |
rename branch (coordinate Capistrano/local clones) or pick another repo first |
| private git+ssh composer deps | every composer install fails Host key verification failed |
out of scope for now (krt-website parked on this) |
| unprovisioned deploy.php | %SERVER%/%USER% placeholders → deploy-php preflight fails with a clear error |
fill from the provisioned branch (often release/* has real values) or provision |
| scaffold repository URL | deploy.php points at craft-starter-kit | one-line fix, preflight flags it |
| Deployer <8 / deployer-tasks <2 | server-side git clone denied (no GitHub keys on Chef-managed servers) |
bump to deployer/deployer ^8 + lameco/deployer-tasks ^2.2, add set('update_code_strategy', 'local_archive'); |
| plugin schema bump w/o migrations | craft-config-update can't heal (e.g. formie 3.4.10→3.4.12); PR stays red | human: local craft up, commit config/project/** to the PR branch |
| plugin/CMS interface drift | craft-up red on a CMS bump (e.g. FieldInterface::propagateValue) |
merge the plugin's own security PR first, then rebase the CMS PR (dashboard checkbox) |
| composer.lock conflicts on Renovate PRs | tooling PRs merged to base touched the lock | tick the rebase checkbox (PR body or Dependency Dashboard), next sweep rebases |
- CI deploys ship the pushed ref:
dep deploy <env> -o branch=<ref>. The host'sbranchin deploy.php stays canonical for manualdepuse. - Gitflow guards in deploy-php: production refuses any ref but the default
branch; development pushes skip green while a
release/*branch exists (the release owns staging; resumes automatically after merge + delete). - deployer-tasks
lameco:verify_deploy_branchenforces the same policy at the Deployer level for manual runs.
- Security/CVE →
main, no cooldown. Routine →development, 3-day cooldown, patch automerge (Symfony only — the Craft overlay never automerges: a Composer bump needscraft up+ review). - Composer 2.10 advisory blocking is bypassed for the runner only
(
COMPOSER_NO_BLOCKINGin renovate-global.js): the bot proposes, the CI audit gate + review enforce. Devs and servers keep full Composer defaults including malware blocking. - Widening: flip
autodiscoverin renovate-global.js once the pilot list is consistently green. Until then, add repos to the explicit list.
ci / ci-okgreen on PRs (ratchet passes pre-existing backlog, fails new advisories).- Advisory burn-down to zero → audit gate automatically strict again.
- Staging deploys on release/development pushes; production gated by Environment approval.
- Org ruleset (once coverage is broad): require
ci / ci-okon main + development.