Add deployment-id sync units#6
Conversation
|
Warning Review limit reached
More reviews will be available in 21 minutes and 2 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
bca4841 to
4698d75
Compare
4698d75 to
8698a0c
Compare
8698a0c to
42a67ea
Compare
## Depends on - #6 ## Motivation Once the host has deployment-id based systemd units, the deployment workflow needs to target one named deployment without stopping or replacing unrelated sync processes. ## Solution - add a required `deployment_id` workflow input - validate deployment IDs before any deployment work runs - scope GitHub Actions concurrency to the deployment ID - upload the runtime env and CLI artifact into the selected deployment directory - stop, replace, enable, and start only `local-db-sync@<deployment_id>.timer` and `local-db-sync@<deployment_id>.service` - include the deployment ID and instance unit names in the workflow summary ## Checks By submitting this for review, I am confirming I have done the following: - [x] made this PR as small as possible - [ ] unit-tested any new functionality - [x] linked any relevant issues or PRs - [ ] included screenshots (if this involves a front-end change) Validated locally with: - YAML parse for `.github/workflows/deploy.yaml`

Depends on
Motivation
The remote local DB host needs to run more than one sync process at a time during schema and database migrations. The existing singleton producer must keep running while a new deployment-id based sync instance is added beside it.
Solution
local-db-sync.serviceandlocal-db-sync.timer/etc/local-db-remote/env,/var/lib/local-db-remote/bin, and/var/lib/local-db-remote/work/local-dblocal-db-remote-runbackwards-compatible: withoutLOCAL_DB_DEPLOYMENT_ID, it uses the legacy pathsLOCAL_DB_DEPLOYMENT_IDis setlocal-db-sync@<deployment_id>.serviceandlocal-db-sync@<deployment_id>.timerChecks
By submitting this for review, I am confirming I have done the following:
Validated locally with:
bash -n nixos/local-db-remote-run.shnix eval '.#nixosConfigurations.local-db-remote.config.systemd.services.local-db-sync.serviceConfig.EnvironmentFile'nix eval '.#nixosConfigurations.local-db-remote.config.systemd.services."local-db-sync@".serviceConfig.Environment'