Skip to content

ci: deploy on merge and track latest stable API Platform - #690

Open
vincentchalamon wants to merge 1 commit into
mainfrom
ci/deploy-on-merge
Open

vincentchalamon wants to merge 1 commit into
mainfrom
ci/deploy-on-merge

Conversation

@vincentchalamon

Copy link
Copy Markdown
Contributor

Production was only reachable by pushing a tag, so cd.yml listening on push: tags made every GitHub release a deployment trigger rather than a versioning act. A security fix could not ship without inventing an off-semver number, and ^4.3.19 capped the upgrade workflow to the current major.

This deploys from main and drops releases entirely.

Deployment

  • cd.yml triggers on push to main instead of tags.
  • concurrency serializes helm deployments. Two close merges would otherwise run two concurrent helm upgrade prod and leave the release in pending-upgrade. cancel-in-progress: false is deliberate: interrupting a helm upgrade --wait blocks the next deployment.
  • The :<ref_name> image tag is dropped. On main it would duplicate :latest for the same digest. :<sha> (the tag actually deployed) and :latest (scanned by security.yml) are kept.
  • deploy.yml derives release and url from inputs instead of re-deriving them from github.event_name, which coupled a reusable workflow to its caller trigger. --atomic rolls back a failed deployment instead of leaving production half migrated.
  • workflow_dispatch allows redeploying the tip of main after a half-failed upgrade. It is pinned to refs/heads/main at the job level: a dispatch can target any ref, so without that guard it would deploy a feature branch to production unreviewed.

Upgrade workflow

  • Targets the latest stable release, majors included, resolved from Packagist. The previous git diff composer.lock | grep -oP parsing was capped by the Composer constraint, which is why chore: upgrade API Platform to 4.4.0 #689 proposes 4.4.0 while 5.0.0 is out.
  • A maintenance tag on an older branch of core is ignored: the demo is never downgraded, the run is a green no-op.
  • concurrency at workflow level. Core dispatches one run per tag and regularly tags several majors the same day.
  • The run declines when any release/api-platform-* pull request is open, so create-pull-request never force-pushes over manual fixes made on an upgrade branch.
  • Failures open an issue: the run is dispatched by the GitHub App, so nothing notifies a human otherwise.

Deprecations

failOnDeprecation is already enabled in phpunit.xml.dist, so a deprecation from api/src/ fails the suite, but only where tests cover the code. phpstan/phpstan-deprecation-rules catches calls to @deprecated APIs statically, and withComposerBased(symfony: true) lets Rector auto-fix Symfony ones. Both run in CI already.

Measured before adding them: PHPStan reports no pre-existing deprecation debt on 4.3.19. Rector proposed 5 files, applied here, mostly #[Autowire(%env(X)%)] to #[Autowire(env: X)], plus removing User::eraseCredentials(), which Symfony 8.1 no longer declares on UserInterface and which nothing calls.

Also

ci.yml had branches: [main, \d+.\d+]. GitHub branch filters accept globs, not regexes, so that second pattern never matched anything. Consequence: nothing ever wrote the refs/heads/main buildx cache scope, and every Docker build in this repository has been running cold. Fixing the filter lets CI populate the shared scope.

Verification

  • phpstan analyse and rector process --dry-run: clean.
  • helm lint: passes.
  • All workflow YAML parses; triggers and job conditions checked.
  • Version resolution run for real against api/composer.lock: current=4.3.19, latest=5.0.0, and the in-flight guard correctly declines because chore: upgrade API Platform to 4.4.0 #689 is open. Comparison verified on 4.3.19, 4.4.0, 4.4.1, 4.10.0, 5.0.0, 5.0.1.

Follow-up, not in this pull request

  1. Harden the main ruleset (20735297, currently deletion + non_fast_forward only). Once this merges, a direct push to main is a direct push to production. Requires deciding on required_approving_review_count.
  2. Close chore: upgrade API Platform to 4.4.0 #689 and delete 4.3. main was created rather than renamed, so 4.3 still exists at the same SHA with no rules at all, and the upgrade workflow will stay blocked until chore: upgrade API Platform to 4.4.0 #689 is closed.
  3. Delete 3.2 to 4.2. Verified: none has a commit missing from main, and each tip is covered by a tag. Check external links first, a deleted branch gets no redirect.

Production was only reachable by pushing a tag, so every deployment required
creating a GitHub release. Deploy from main instead, and drop releases.

- cd.yml: trigger on push to main instead of tags, serialize helm deployments,
  drop the redundant :<ref_name> image tag, and pin production to main so a
  workflow_dispatch cannot deploy a feature branch unreviewed
- deploy.yml: derive release and url from the caller inputs rather than from the
  event, add --atomic, and export namespace so the debug step can use it
- upgrade-api-platform.yml: target the latest stable release including majors,
  ignore maintenance tags on older branches, never force-push over an upgrade
  already in flight, and report failures as an issue
- ci.yml: drop the versioned branch filter, which was a regex and never matched
- enable phpstan deprecation rules and the Rector Symfony set, so deprecations
  surface in the upgrade pull request and are fixed there
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant