Skip to content

Add deployment-id sync units#6

Merged
findolor merged 1 commit into
mainfrom
feature/deployment-id-runner
May 26, 2026
Merged

Add deployment-id sync units#6
findolor merged 1 commit into
mainfrom
feature/deployment-id-runner

Conversation

@findolor
Copy link
Copy Markdown
Collaborator

@findolor findolor commented May 23, 2026

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

  • keep the existing legacy local-db-sync.service and local-db-sync.timer
  • keep legacy runtime paths under /etc/local-db-remote/env, /var/lib/local-db-remote/bin, and /var/lib/local-db-remote/work/local-db
  • make local-db-remote-run backwards-compatible: without LOCAL_DB_DEPLOYMENT_ID, it uses the legacy paths
  • add deployment-id validation and per-deployment paths when LOCAL_DB_DEPLOYMENT_ID is set
  • add local-db-sync@<deployment_id>.service and local-db-sync@<deployment_id>.timer
  • create shared host directories for named deployment env, binary, and work state

Checks

By submitting this for review, I am confirming I have done the following:

  • made this PR as small as possible
  • unit-tested any new functionality
  • linked any relevant issues or PRs
  • included screenshots (if this involves a front-end change)

Validated locally with:

  • bash -n nixos/local-db-remote-run.sh
  • nix 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'

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 23, 2026

Warning

Review limit reached

@findolor, we couldn't start this review because you've reached your PR review rate limit.

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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 7944235c-849f-4b1a-80ff-af03d0662db0

📥 Commits

Reviewing files that changed from the base of the PR and between b10da84 and 42a67ea.

📒 Files selected for processing (2)
  • nixos/local-db-remote-run.sh
  • os.nix
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feature/deployment-id-runner

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Collaborator Author

findolor commented May 23, 2026

@findolor findolor self-assigned this May 23, 2026
@findolor findolor changed the title feat: add deployment-id sync units Add deployment-id sync units May 23, 2026
@findolor findolor force-pushed the feature/deployment-id-runner branch from bca4841 to 4698d75 Compare May 24, 2026 16:22
@findolor findolor force-pushed the feature/deployment-id-runner branch from 4698d75 to 8698a0c Compare May 26, 2026 08:05
Copy link
Copy Markdown
Collaborator Author

findolor commented May 26, 2026

Merge activity

  • May 26, 3:00 PM UTC: A user started a stack merge that includes this pull request via Graphite.
  • May 26, 3:02 PM UTC: Graphite rebased this pull request as part of a merge.
  • May 26, 3:02 PM UTC: @findolor merged this pull request with Graphite.

@findolor findolor changed the base branch from chore/local-db-op to graphite-base/6 May 26, 2026 15:00
@findolor findolor changed the base branch from graphite-base/6 to main May 26, 2026 15:00
@findolor findolor force-pushed the feature/deployment-id-runner branch from 8698a0c to 42a67ea Compare May 26, 2026 15:01
@findolor findolor merged commit 282c4f2 into main May 26, 2026
1 check passed
findolor added a commit that referenced this pull request May 26, 2026
## 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`
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.

3 participants