a year ago
How can I make sure that no cached layers or images are being used when I build my Dockerfile for deployment? Does nixpacks build using a docker build command? (i.e., can I specify --no-cache specifically as part of a custom build command?)
I've already included both "NO_CACHE=1" and "NIXPACKS_NO_CACHE=1" (found both in online docs/responses) in my environment variables. I don't believe there are any flags or arguments that can be set in the Dockerfile itself.
----- Why am I asking?
Essentially, I'm encountering build errors in railway that I previously saw locally, likely caused by a change in my npm packages (ts project). I fixed those errors locally by deleting saved docker images and node_modules, new npm install and re-building the docker image - no more local issues.
Now encountering the same errors in railway, I'm re-tracing my steps, but realizing a lot happens on railway build that I don't quite understand. I'd like to be certain that I'm re-building the image and layers from scratch.
22 Replies
Update - Railway may be using buildkit and not nixpacks - I'm not entirely certain.
I have a Dockerfile in the project github repo and we auto-deploy to railway based on updates to the 'main' branch. I believe images are being built by Railway and used for deployment since I can see the build occuring in the Railway build logs.
a year ago
project id please
a year ago
what service in what environment?
a year ago
do you mean launchschool-llm?
a year ago
first off, you are using a dockerfile, so anything nixpacks related to is not applicable
a year ago
for your context, that variable does exactly what you want, and i can confirm that your build was done without any layer cache
So the docker image used for deployment is always built from scratch with that "NO_CACHE = 1" variable?
a year ago
yep!
Then I'm stumped...... any other ideas why I would be getting build errors in railway, but no longer in my own local environment?
Is it possible to access a CLI within the environment to confirm install package versions, etc?
a year ago
yes, but in this case, no, you need something running otherwise there is nothing to ssh into
a year ago
are you running dockerfile or dockerfile.dev locally?
Typically we run dockerfile.dev for local environments, but I ran the dockerfile locally to test - i.e., built from dockerfile and used that as part of local environment. It seemed to work.
a year ago
delete the entire project locally, then re-pull it, and try again
FWIW, those same errors are occurring locally again, so there's no escaping the need to get to the root of them.
Thanks for your help!
a year ago
no problem!
a year ago
and good luck!