Add function YAML config to ignore paths during shrinkwrap

[tatemz]

Description

This change handles an ignore_paths configuration array that prevents
specified folders and files from being copied into the handler build
folder.

This is useful for node applications where the process of copying a
handler's node_modules folder can take a long time. In such case, the
node_modules folder is not needed as it is ignored during the Docker
build process anyway.

This change also applies to file paths that are copied from the
configurations.copy array.

Motivation and Context

• I have raised an issue to propose this change (required) Shrinkwrapping with jest takes 30 more seconds due to node_modules #889

How Has This Been Tested?

Go tests and example in sample folder and stack.yml. The following commands should show that the sample/nodejs-echo/node_modules/foo is not added to the build folder

$ ./bin/faas-cli-darwin build
$ ls -lha build/nodejs-echo/function/node_modules

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have signed-off my commits with git commit -s
• I have added tests to cover my changes.
• All new and existing tests passed.

[tatemz]

Hello, consider this feature as a proposal for new functionality to address #889

A few dev notes:

• I chose to use ignore_paths for lack of a better term. I'd love some better suggestions
• I chose to ignore paths based on their destination rather than their source in order to handle files that may be copied into a function handler via the copy configuration
• I think this use case primarily addresses Node projects, but maybe there are more usecases

An alternative I thought through was to evaluate glob patterns and ignore patterns found in the .dockerignore file, which ideally should contain similar entries.

[krakrjak]

This is a really important ergonomic and space saving feature. Is it possible to get some 👀 on this one with feedback. I've been using this version of the faas-cli for a while and it is very nice to not have to worry about cleaning up explicitly after local debugging.

[derek]

Thank you for your interest in OpenFaaS. This project is maintained and made available for hobbyists and commercial users alike, so we need to balance our time across everyone's needs. Whilst we are excited in your interest in using OpenFaaS, we would also ask you to take a look at our contribution guide on Setting expectations, support and SLAs.

Commercial users can purchase support in order to get dedicated help from OpenFaaS Ltd, or they can book ad-hoc consulting hours to get an engineer to dedicate time to helping them.

If that is not a good fit for you at this time, please check out the OpenFaaS GitHub Sponsors options which are priced for practitioners like yourself. Organisations can also sponsor through their GitHub billing relationship.

When you become a sponsor as an indvidual, it will show this on your issues and PRs, so that the community can see that you are supporting our work, and can prioritise your needs.

If you are receiving this message after having received hands-on support from the OpenFaaS community, please join GitHub Sponsors to say thank you for our time.

Thank you for supporting OpenFaaS.

[alexellis]

I chose to use ignore_paths for lack of a better term. I'd love some better suggestions

There is already a convention for this, placing a file in the upper directory:

.gitignore
.dockerignore

These cannot be executed recursively with Docker, so perhaps an implementation for the CLI should work the same, if you wanted to ignore node_modules.

By removing the folder from your builds, do you then cause the latency to be taken over into Docker or your builder and its npm step? What about private npm modules? How are you handling them?

[krakrjak]

I chose to use ignore_paths for lack of a better term. I'd love some better suggestions

There is already a convention for this, placing a file in the upper directory:

.gitignore .dockerignore

These cannot be executed recursively with Docker, so perhaps an implementation for the CLI should work the same, if you wanted to ignore node_modules.

By removing the folder from your builds, do you then cause the latency to be taken over into Docker or your builder and its npm step? What about private npm modules? How are you handling them?

The process we take, in CI (so clean trees no nested node_modules) is to shrinkwrap the stack, then build and publish each container using Kaniko (in parallel) and then deploying the stack with the faas-cli. This works great and is nice.

However, when testing locally, it can be a huge pain to work inside a function and "forget" to clean the node_modules folder before using the faas-cli to do a local Docker build.

We already use .gitignore and .dockerignore files, but this is insufficient if you have function directories with node_modules within them as we pay the penalty of copying those node_modules folders for every function built that happens to be dirty due to local debugging/development. This becomes untenable when you need to make cross-cutting changes (updates to shared libraries or template enhancements) to many functions.