$PORT inconsistently being provided? race condition?
https://railway.app/project/e83cd241-4a9f-417c-9151-eee7ac5d0788/service/62746785-6a46-421e-9422-efd3d7ff869e?id=4c357709-dac5-4cb5-9ada-298507b28d2b
Run code w/ two start commands
npx quartz build --serve --port $PORT
^-- errors with RangeError: options.port should be >= 0 and < 65536. Received type number (NaN).
echo 'port'$PORT && npx quartz build --serve --port $PORT
^-- succeedsRailway
404 - Page not found
Railway is an infrastructure platform where you can provision infrastructure, develop with that infrastructure locally, and then deploy to the cloud.
28 Replies
Project ID:
e83cd241-4a9f-417c-9151-eee7ac5d0788,62746785-6a46-421e-9422-efd3d7ff869e,4c357709-dac5-4cb5-9ada-298507b28d2bThe
PORT your app runs on changes between deployments
if you want it to be static then you can manually set the PORT service variable to the port your app needs to run onI pass
$PORT to the start command
which should be provided by railway right?yea
keep in mind, it's not available during build
it's available during start command run time? or is that still considered build?
🤔 I'm not sure
the dockerfile calls the start command at the end
so i'm not sure whether it's considered part of build or not
i had also tried to use this from the railway docs
it "didn't work" where i put it in quotes because the deploy success is fuzzy already
I'd say try setting a static PORT and use that where you need it, see if it works
if it does then I guess it's not available then, if it doesn't work then something else is the problem
the auto generated PORT is not available at build time, if you need PORT to be available during build time, set a static PORT service variable like fragly said
sounds good, I will do that going forward.
for curiosity, why does my deploy sometimes still work? Sometimes PORT is available at build time
its not available at build time, i dont know how it could work, unless youve specified something somewhere
i've already updated my config to now manually provide port but I was able to a successful minimum recreation of
start server $PORT that correctly catches the railway specified port.
I feel inclined to chalk it up to magic but behavior just seemed so odd to meyes the auto generated PORT is available at runtime
bumping this then
the start command is runtime
though, something that came to mind, the start command field in the service settings is ran in exec mode and therefore does not do variable expansion
oh
now that is something
i did do something with railway.toml
when you say service settings do you mean either the GUI or railway.toml?
or only one of the two?
or other
GUI
TLDR: dockerfile issue
ok i've constructed two pretty much identical directories.
I am going to up one then up the other using a couple methods.
Trial 1: quartz, CMD in Dockerfile, providing GUI start command, deploy triggered by github commit
Start command:
echo 'port'$PORT && npx quartz build --serve --port $PORT
Result: Failure
Deploy output: port$PORT (env var not expanded)
Trial 2: quartz, CMD in Dockerfile, providing GUI start command, deploy triggered by railway up
Start command: echo 'port'$PORT && npx quartz build --serve --port $PORT
Result: Failure
Deploy output: port$PORT (env var not expanded)
Trial 3: quartz2, CMD in Dockerfile, providing GUI start command, deploy triggered by railway up
Start command: echo 'port'$PORT && npx quartz build --serve --port $PORT
Result: Failure
Deploy output: None (the build completed successfully)
Note: This identical configuration was the one that worked prior to trial 1.
Trial 4: replication of Trial 3 but I modify Dockerfile labels so railway can't cache anything, railway up
Start command: echo 'port'$PORT && npx quartz build --serve --port $PORT
Result: Failure
Deploy output: port$PORT (env var not expanded)
Note: Changing docker label has caused the deploy output to change. I am not familiar with docker but I don't think this should happen?
Trial 5: removing the GUI start command, railway up
Dockerfile CMD: CMD ["npx", "quartz", "build", "--serve", "--port", "$PORT"]
Result: Failure
Deploy output: RangeError: options.port should be >= 0 and < 65536. Received type number (NaN).
Note: I am manually providing the $PORT env variable. I did not revert the docker label change.
Trial 6: revert docker label change, railway up
Same outputs as trial 5. This is expected.
Trial 7: quartz, deploy via github commit
This trial is going back the the "original" directory
Same outputs as trial 5 and 6.
Now I am going to re-introduce the GUI start command as npx quartz build --serve --port $PORTTrial 8: quartz, no more Dockerfile CMD, github deploy
Same outputs as trials 5,6,7
Trial 9: quartz2, no more Dockerfile CMD, railway up
Same
I will now introduct an echo statement into the GUI start command. The final start command will be
echo 'port'$PORT && npx quartz build --serve --port $PORT
Trial 10: automatic redeploy due to changing config, automatically sourcing from github repo
This deploy is hanging in the build phase? I am aborting @ 2 minutes initializing
Trial 11: kill stuck deploy, railway up from quartz
Start command: echo 'port'$PORT && npx quartz build --serve --port $PORT
Result: Failure
Deploy output: port$PORT (env var not expanded)
Trial 12: reintroduce the Dockerfile CMD
I don't expect this to do anything. the start command should trump this?
Result: Failure
Deploy output: None
Trial 12: quartz2, reintroduce Dockerfile CMD
Result: Failure
Deploy output: port$PORT (env var not expanded)
I will now delete the service&project and reconstruct it from quartz2.
Trial 13: quartz2, no $PORT env variable, no start command
RangeError: options.port should be >= 0 and < 65536. Received type number (NaN).
Trial 14: define PORT in railway variables, automatic redeploy due to changing config
Error: No start command could be found
Not sure what is going on here. CMD is defined in the dockerfile still
Trial 15: change Dockerfile CMD
CMD ["npx", "quartz", "build", "--serve"]
I have removed the explicit port specification
Result: Success, server is live. default port
Is this because $PORT is not expanding in the dockerfile??
Trial 16: change dockerfile CMD
CMD npx quartz build --serve --port $PORT
Inspired by: https://stackoverflow.com/a/40454758
Result: Success, I will now remove my manually specified $PORT
Trial 17: removing $PORT, autodeploy
Error: No start command could be found
this is kinda annoying
Trial 18: doing railway up again
Result: Success
Dockerfile expanded port correctly
Trial 19: using this information...
Let's connect to my git repo again with the correct dockerfile command. I made two changes here. back to quartz (not quartz2) directory, deploy from github
Result: SuccessStack Overflow
How can I use a variable inside a Dockerfile CMD?
Inside my Dockerfile:
ENV PROJECTNAME mytestwebsite
CMD ["django-admin", "startproject", "$PROJECTNAME"]
Error:
CommandError: '$PROJECTNAME' is not a valid project name
What is the quickest
Conclusion: don't mess up Dockerfile expands lol
yep no variable expansion with exec mode
secondary comment: CLI up'd repos that provide no start command and only a Dockerfile will fail to redeploy when changing configuration due to "no start command could be found"
yeah im just being punished by never really using docker
known bug, railways auto redeploy will deploy some very old deployment
sg
cancel the popup and use this https://bookmarklets.up.railway.app/service-redeploy/
already saved haha, saw you sent in a diff thread earlier
haha awsome