Use `fly launch`/`dockerfile-node` instead of `.dockerignore`, `Dockerfile`, `fly.toml` & `start.sh` about indie-stack

[kentcdodds]

The apps are under the Remix fly account.

I have no issues with any changes to this stack so long as it works and is as simple or simpler

[mikeybinns]

One modification I always make to my build is to delete certain routes on deploy in the Dockerfile just before build, without deleting them locally / in the git repo. On route convention v1, this was a "_test" folder, and on route conventions v2, it's any files that start with _test.. This provides me a way to create a helpful for testing route, but ensure it doesn't leak onto production builds.

Is there a way to do this kind of code manipulation with dockerfile-node? Obviously if not, I don't expect for this to block any implementation, I'm just not 100% clear how dockerfile-node will work with regards to edits like this.

In case this isn't clear, this is the "Build the app" code from the Dockerfile for routes v2:

[MichaelDeBoey]

I have no issues with any changes to this stack so long as it works and is as simple or simpler

@kentcdodds The purpose of @rubys' suggestion is to have less files in the stack/project and let fly launch/dockerfile-node do the heavy stuff that's needed for deploying to Fly

[rubys]

One modification I always make to my build is to delete certain routes on deploy in the Dockerfile just before build

I would suggest putting this in .dockerignore?

In any case, the answer is yes: dockerfile-node is just a bunch of ejs templates, and it would be no problem to add something like:

<% if (remix) { -%>
# remove test route files from non-local builds
RUN if [ ... ] then ... fi
<% } -%>

[MichaelDeBoey]

@rubys I would suggest to support this in a generic way, like the extra dependencies that can be installed for certain stages of Dockerfile

[mikeybinns]

I would suggest putting this in .dockerignore?

omg 🤦 I can't believe I didn't think of this... This definitely would be a much easier way to do this for my use case.

I would suggest to support this in a generic way

I agree with this, I was mainly giving my use-case only an example, and I'm sure there's other things people may want to do just before or after a build.

Maybe you could provide a way to hook into the process at certain points, e.g. before_build, after_build, after_deploy where uses can execute code. I don't know anything about ejs, but seeing as it's just JS, maybe you can make it possible to just provide a function which accepts parameters like buildFiles, context, buildArgs?

[rubys]

Maybe you could provide a way to hook into the process at certain points, e.g. before_build, after_build, after_deploy where uses can execute code. I don't know anything about ejs, but seeing as it's just JS, maybe you can make it possible to just provide a function which accepts parameters like buildFiles, context, buildArgs?

Good news. Take a look at the current set of options: https://github.com/fly-apps/dockerfile-node#options

• --instructions lets you specify a file to inserted in one of three places in the Dockerfile
• --arg lets you specify build args

Can you describe what you mean by buildFiles and context? If those are generic, they can be added as flags and can benefit all node applications, not just remix ones.

[mikeybinns]

Ah amazing :) yeah I think that was exactly what I was envisioning, sorry next time I'll do a deeper dive into the documentation :)

Don't worry about those parameters as they are likely irrelevant with your current way of doing things :)

[mikeybinns]

In case this doesn't go ahead for whatever reason, there's some other updates required for the fly.toml.

As far as is documented, allowed_public_ports and auto_rollback are not valid parameters. I discovered this because "auto_rollback" didn't do anything when I accidentally deployed a bad build.

To replace auto_rollback, we should set a deploy strategy as shown here:

[deploy]
  strategy = "bluegreen"

https://fly.io/docs/reference/configuration/#picking-a-deployment-strategy