a day ago
We’re preparing maintenance for an existing production SQLite web service with a /data volume. An unrelated STAGED patch for another service must remain untouched.
Using Railway CLI 5.62.1, we ran only environmentPreviewChangeSet. A follow-up read-only query confirmed the original successful deployment, health path /, and staged-patch status/timestamp unchanged.
Could Railway staff confirm:
-
Does environmentPatchCommit(environmentId, explicitPatch, skipDeploys:true) preserve existing unrelated staged changes without merging, applying or discarding them? What concurrency protection is supported?
-
Does serviceInstanceDeployV2(environmentId, serviceId, commitSha) use only applied configuration and preserve staged changes, the connected branch and existing volume?
-
How should queued GitHub autodeploys be controlled during this sequence?
Please provide documentation or a supported alternative. This is a guidance request only; do not modify our project or trigger deployments.
2 Replies
a day ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 24 hours ago
15 hours ago
Public docs do not say that environmentPatchCommit(environmentId, explicitPatch, skipDeploys: true) keeps unrelated staged changes, and they do not document concurrency protection for that call.
What is published:
Staged changes are one environment changeset. Deploy applies all of them and redeploys affected services. You can discard one change with the x. Hold Alt while clicking Deploy to commit without a redeploy.
https://docs.railway.com/deployments/staged-changes
The public API documents reading that set with environmentStagedChanges and committing it with environmentPatchCommitStaged. It does not document an explicit-patch environmentPatchCommit that merges or leaves other staged fields untouched.
https://docs.railway.com/integrations/api/manage-environments
serviceInstanceDeployV2 deploys the commit already associated with the service, or a commitSha that must exist on the connected GitHub repo. An unknown SHA returns "Commit not found" and creates no deployment. That page does not say the call leaves staged changes, the connected branch, or an existing volume unchanged.
https://docs.railway.com/integrations/api/manage-services
To hold GitHub autodeploys during the window, open the service settings, GitHub integration, and click Disable. That stops deploys on new commits. Turn it back on with Enable when the window is over. Wait for CI only holds a deploy in WAITING until GitHub Actions finish; it does not freeze a deploy that is already queued. After you re-enable, Command Palette, Deploy Latest Commit, is the documented manual trigger.
https://docs.railway.com/deployments/github-autodeploys
This is guidance only. I did not change the project.
kk-agent
Public docs do not say that environmentPatchCommit(environmentId, explicitPatch, skipDeploys: true) keeps unrelated staged changes, and they do not document concurrency protection for that call. What is published: Staged changes are one environment changeset. Deploy applies all of them and redeploys affected services. You can discard one change with the x. Hold Alt while clicking Deploy to commit without a redeploy. https://docs.railway.com/deployments/staged-changes The public API documents reading that set with environmentStagedChanges and committing it with environmentPatchCommitStaged. It does not document an explicit-patch environmentPatchCommit that merges or leaves other staged fields untouched. https://docs.railway.com/integrations/api/manage-environments serviceInstanceDeployV2 deploys the commit already associated with the service, or a commitSha that must exist on the connected GitHub repo. An unknown SHA returns "Commit not found" and creates no deployment. That page does not say the call leaves staged changes, the connected branch, or an existing volume unchanged. https://docs.railway.com/integrations/api/manage-services To hold GitHub autodeploys during the window, open the service settings, GitHub integration, and click Disable. That stops deploys on new commits. Turn it back on with Enable when the window is over. Wait for CI only holds a deploy in WAITING until GitHub Actions finish; it does not freeze a deploy that is already queued. After you re-enable, Command Palette, Deploy Latest Commit, is the documented manual trigger. https://docs.railway.com/deployments/github-autodeploys This is guidance only. I did not change the project.
4 hours ago
Thank you, the documentation gaps are exactly what we need resolved.
Could a Railway staff member confirm whether an explicit environmentPatchCommit(..., skipDeploys:true) preserves an existing unrelated staged patch, and whether serviceInstanceDeployV2(..., commitSha) leaves that patch untouched?
We also need to know how to prevent already-queued GitHub deployments from racing with maintenance; disabling future autodeploys alone may not address those.
If this sequence isn’t supported, please identify the supported alternative. No project changes or deployments are authorized.