Problem
When a deploy runs while a pipeline (wpcomposer pipeline) is in progress, there are potential race conditions:
- The deploy restarts the web server, which is harmless on its own
- But if the pipeline is in its build/deploy phase, both processes could call
deploy.Promote and swap storage/repository/current concurrently
- Two concurrent builds could write conflicting rows to the
builds table
The pipeline binary stays in memory (Linux keeps the old inode), so it won't crash — but the results could be unpredictable.
Possible solutions
- Lock file — pipeline acquires a lock (e.g.
storage/pipeline.lock) before starting; deploy task checks for it and skips the service restart or waits
- Deploy skips restart if pipeline is active —
systemctl is-active wpcomposer-pipeline check in the Ansible deploy task
- Pipeline guards its own deploy step — only
Promote if no other build was promoted since the pipeline started
Context
The pipeline runs on a timer via wpcomposer-pipeline.service (oneshot). Deploys are triggered manually via Ansible. Both use shared storage and the same SQLite database.
Problem
When a deploy runs while a pipeline (
wpcomposer pipeline) is in progress, there are potential race conditions:deploy.Promoteand swapstorage/repository/currentconcurrentlybuildstableThe pipeline binary stays in memory (Linux keeps the old inode), so it won't crash — but the results could be unpredictable.
Possible solutions
storage/pipeline.lock) before starting; deploy task checks for it and skips the service restart or waitssystemctl is-active wpcomposer-pipelinecheck in the Ansible deploy taskPromoteif no other build was promoted since the pipeline startedContext
The pipeline runs on a timer via
wpcomposer-pipeline.service(oneshot). Deploys are triggered manually via Ansible. Both use shared storage and the same SQLite database.