fix(ci): stop aliasing RAILWAY_API_TOKEN to RAILWAY_TOKEN#4392
Conversation
The Railway CLI uses two different env vars: - RAILWAY_TOKEN: project token (project-scoped commands only) - RAILWAY_API_TOKEN: account/workspace token (project list/init/etc.) Our preview scripts need account-level access (project list, project init), so the CI workflow correctly sets RAILWAY_API_TOKEN from the RAILWAY_TOKEN GitHub secret. However preview-resolve-env.sh was also copying that value into RAILWAY_TOKEN, which made the CLI treat the account token as a project token and respond with Unauthorized on every account-level call. Removing the alias restores the original behaviour from 6952242.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe PR removes the conditional fallback that previously exported RAILWAY_TOKEN from RAILWAY_API_TOKEN during preview environment initialization; the rest of the preview project/key/image resolution logic is unchanged. ChangesEnvironment Variable Resolution
🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
There was a problem hiding this comment.
Pull request overview
This PR aims to restore Railway preview CI authentication by removing an environment-variable alias that copied RAILWAY_API_TOKEN into RAILWAY_TOKEN, which can break account-level Railway CLI commands.
Changes:
- Removed the
RAILWAY_API_TOKEN→RAILWAY_TOKENexport block from the preview env resolution script.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
bootstrap.sh, configure.sh, deploy-from-images.sh and preview-create-or-update.sh all source lib.sh. The same aliasing block that broke preview-resolve-env.sh was also added there in c0baede, so removing it from only preview-resolve-env.sh left the collision in place inside the bootstrap subshell. Removing it here too. Verified locally: with both aliases gone the CI flow (source preview-resolve-env then run bootstrap with railway whoami) succeeds against Railway.
Railway Preview Environment
Updated at 2026-05-21T09:47:27.980Z |
Summary
Restore Railway preview CI by removing a token env-var aliasing that was added in
c0baede6f("some clean-up", May 19) and silently broke every preview run since.hosting/railway/oss/scripts/preview-resolve-env.shRAILWAY_API_TOKENintoRAILWAY_TOKEN.What happened
The Railway CLI exposes two different env vars that look interchangeable but are not (per docs.railway.com/guides/cli):
RAILWAY_TOKENRAILWAY_API_TOKENproject list,project init,whoami, etc.Our preview scripts (
bootstrap.sh,configure.sh,deploy-from-images.sh, ...) need account-level access because they enumerate and create Railway projects. Commit6952242c5(Feb 2026) deliberately switched the CI workflows fromRAILWAY_TOKENtoRAILWAY_API_TOKENfor that reason:On 2026-05-19 at 14:44 UTC, commit
c0baede6f("some clean-up") added this block at the top ofpreview-resolve-env.sh:That re-creates the very collision
6952242c5fixed. When both vars are set to the same account token, the CLI prioritisesRAILWAY_TOKEN(= project token semantics), and every account-level call returns:Reproduction against Railway (using a known-good account token):
The CI failure timeline confirms it:
14-check-pr-preview.yml: 2026-05-19 16:42 UTC (on a branch that pre-dated the bad commit in its merge base)setup / setupjob, regardless of branch contentsRailway authentication failed. The token appears to be invalid or revoked.fromrequire_railway_authinbootstrap.shThe GitHub secret itself is fine — the token I tested locally returns the right user and lists
agenta-oss-pr-*projects in the Agenta workspace. The bug was entirely in the script.Fix
Drop the aliasing. The workflow already exports the correct env (
RAILWAY_API_TOKEN), and the rest of the scripts already check both vars inrequire_railway_authso nothing else needs to change. Local invocations should setRAILWAY_API_TOKEN(already documented inhosting/railway/oss/README.md).Test plan
14-check-pr-preview.ymlon this PR completes thesetup / setupjob (i.e.railway whoamisucceeds insidebootstrap.sh).deployandtestsjobs run to completion (they were skipped while setup failed).RAILWAY_API_TOKEN=<acct> source hosting/railway/oss/scripts/preview-resolve-env.sh && railway whoamireturnsLogged in as ….