Exclude API folder from publishing to Production (Docker deployment)

Feature Request
#1

Idea: To have option to exclude needed folders for publishing. This option should be unique for each project and not global.
Explanation: During development I’m collecting all my test API action under /api/test folder and during deployment (publishing) to production I want to exclude them.
Reference topics: Ignore a Folder When Using PUBLISH and Exclude a local folder from publishing

#2

I’ve changed the title to include “Docker deployment” - if this is not the case, let me know

#3

Can’t you use the .dockerignore file?

#4

Can you please provide example of using .dockerignore for specific target and API folder?

#5

To exclude the the folder in your .dockerignore file, add the following line:

/api/test

This will instruct Docker to ignore the /api/test folder when building the Docker image.

Make sure to create a file named .dockerignore in the root directory of your project and add the line above to it.

#6

.dockerignore file is already pre-created in Wappler project folder in root and contains some entries, but with your solution /api/test folder will be excluded from all targets, but my main request is to have ability to set - in which which deployment target not to upload specific folder.

Since I have 3 deployment target: DEV, UAT, PROD I want so that /api/test won’t be published only in PROD.

#7

Ah yeah. That target stuff. It’s mainly why I don’t use targets with Wappler. All my build stuff is done outside of Wappler to have more flexibility.

There is a solution based on environment variables where you have one .dockerignore file per environment like .dockerignore.dev and .dockerignore.prod.

Then inside your dockerfile you copy the appropriate file to .dockerignore

COPY .dockerignore.${ENV} .dockerignore

Doing the same for targets would be easy as that information is known by Wappler.

Unfortunately Wappler doesn’t allow customizing the docker build command. So you wouldn’t be able to pass the environment as an argument.

@george would it make sense to add the target as an argument in the docker build command?

docker build --build-arg TARGET=<value> …

Or allowing to customize the build arguments per target. This would allow more flexibility.

1 Like
#8

isnt it something where you could just use a library action to check if the current version is production, if so just return response 401 or something? or check to make sure only admin can run it?

Thats just what I’m currently doing.

2 Likes
#9

That would be a very good workaround @Hinky

Here a middleware to disable all /api/test/* routes and return 404 only for production.

exports.before = function (app) {
    if (process.env.NODE_ENV === 'production') {
        app.use('/api/test/*', (req, res, next) => {
            res.status(404).sendfile('404.html', { root: 'public' });
        });
    }
};
1 Like
#10

I’m a bit lost - where to put code you provided?

#11

Hi @JonL

I’d be very Interested to understand more about building outside of Wappler - this would solve a few headaches we have with our CI/build cycle

#12

Save that snippet into a js file whatever.js and place it in:

extensions/server_connect/routes

Create a 404.html file and place it in /public

If you just want to send a 404 response and not a 404.html page add this snippet instead:

exports.before = function (app) {
  if (process.env.NODE_ENV === 'production') {
    app.use('/api/test', (req, res, next) => {
      res.status(404).send('Not found');
    });
  }
};
1 Like
#13

I only use one target in Wappler. My development target then I push my changes to the remote repo and take it from there.

In my case I use github repo and github actions to test, build the project, and deploy.

1 Like
#14

What are those? In case I have faced them before.

#15

Simply being tied to the UI and wanting to push off deployment to another team who can manage the release or reject it. Another annoyance is having pushed to live, it remains the target and you forget so the next test release goes to live. Then it’s backing out from Git etc…

Be much nicer to push it off to others and move on

#16

I understand. Then yes, using Wappler just to build in one target and push to remote would fit your needs, but there is at least one caveat. One that I’ve been facing.

Knex migrations. If you are using them you need to define the extra targets to migrate the changes through your database landscape. Not ideal as you will have a window of time where code and database is not in sync due to this manual action.

Or you create some scripts in your ci/cd pipeline to handle them and also perform the changes that wappler_migrations tables expect so no errors occur next time you use Wappler’s database manager.

There are a few FR regarding this topic, including the request of a Wappler CLI that we can run in the ci/cd, exposing the knexfile, etc

#17

The Wappler CLI and some docs as to what we’re building would be ideal. Thanks :pray: