3 months ago
Subject: GitHub-connected service keeps deploying an old commit instead of branch HEAD
Project: virtuous-amazement / production
Service: future-ip-website-v2
Repo: Richardvandev/future-ip-website-v2
Branch connected to production: main
Auto-deploy: enabled, Wait for CI: off
Problem:
Every deployment (including manual "Redeploy" and pushes) builds an OLD
commit ("Privacy: Railway-hosting + dataopslag binnen EU (Amsterdam)..."),
instead of the current HEAD of main. The branch HEAD on GitHub is several
commits ahead and contains the changes I need deployed.
Current GitHub main history (newest first):
- e31eb00 Force rebuild: directe offerte live zetten (build marker)
- 392c38e chore: trigger Railway redeploy (directe offerte)
- 297061a Directe offerte: offerte maken zonder eerst volledig opnameformulier
- 177720d Privacy: Railway-hosting + dataopslag binnen EU (Amsterdam)... <-- Railway keeps deploying THIS one
What I already tried (none worked):
- Manual "Redeploy" multiple times
- Pushing an empty commit
- Pushing a new commit with real file changes
- Disconnecting and reconnecting the branch (main)
- Fully disconnecting and reconnecting the GitHub repo + branch main
After every attempt, the new deployment still shows the old "Privacy" commit
and "Deployment successful", but the running code is the old version
(new endpoint /api/opname/direct returns 404, new frontend code is absent).
Note: this started around the time of a Railway incident ("Logs and metrics
may be slow to load"). The service was recently migrated to EU West (Amsterdam).
Request:
Please force this service to deploy the current HEAD of main (commit e31eb00),
or fix whatever is pinning it to the old commit 177720d. Thank you.
2 Replies
Status changed to Awaiting Railway Response Railway • 3 months ago
3 months ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • 3 months ago
3 months ago
how?
2 months ago
The important distinction here is Redeploy vs. Deploy Latest Commit: Railway's documented Redeploy action intentionally creates a deployment with the same source snapshot as the selected deployment, so repeatedly redeploying 177720d cannot advance the Git revision.
I would use this recovery sequence:
- In the service, open the Command Palette (Cmd/Ctrl+K) and choose Deploy Latest Commit. Railway documents that action as fetching the latest commit from the currently connected GitHub branch. Do not use the three-dot Redeploy action for this test.
- In Deployments, enable Show Skipped. If e31eb00/392c38e/297061a appear there, inspect the skip reason. A watch path can skip changes; an empty commit does not satisfy a watch path. Temporarily remove/correct the watch path, then run Deploy Latest Commit.
- Check whether a Deployment Approval is waiting. Railway can queue an approval when the GitHub commit author does not have a linked Railway account; approve that queued deployment if present.
- Before testing the URL, open the newly queued deployment and verify its displayed source SHA is e31eb00. This separates source selection from a build/runtime problem:
- If the queued SHA is still 177720d, the GitHub source integration is stale/pinned.
- If the queued SHA is e31eb00 but the endpoint is still absent, the source problem is solved; then inspect Root Directory/Dockerfile build context and the build log for stale/copied output.
- As a clean source-selection bypass, clone/check out e31eb00 locally, link the exact production project/environment/service, and run
railway up --service future-ip-website-v2 --environment production. Unlike Redeploy,railway upuploads the current local files as a new source archive. Confirm the new deployment SHA/message before moving traffic.
If Deploy Latest Commit still queues 177720d after the branch shows main, Railway's own troubleshooting path is to uninstall/reinstall the Railway GitHub App, reconnect the source, and retry once. If it remains pinned, this needs Railway support/platform repair rather than more rebuilds; include project/service/environment, repo+branch, missing SHAs and their UTC push times. The earlier migration/incident timing is useful evidence.
Official references:
Status changed to Solved richardvandev • about 2 months ago