Proposal: Template lock file and configurable template cache location

[LucasRoesler]

I have a rather big proposal, but one I have thought about for awhile and can implicitly fix this problems like #745

We should mimick some of the behavior we see with Go modules? Specifically, we should have the equivalent of a go.mod and a go.sum file. This could look like

1. a templates.yaml, this has a format <template name>: <github repo>#<sha>
   • I picked yaml for the simplicity of parsing
2. a templates.lock or templates.sum which has the format <github repo>#<sha> <hash>
3. write the templates cache to a location dictated by OF_TEMPLATES_CACHE, defaulting to .openfaas/templates or something similar
4. the template cache writes template contents to folders with the structure OF_TEMPLATES_CACHE/github.com/repo/template_name@hash
5. (this is where we start overlapping with this issue) if the current folder has a template folder we can treat it like a "vendor" folder if it contains a special folder: templates.txt.
   if this file exists, we treat the subfolders as possible templates and we ignore this folder.
   if this file does not exist, we treat it as function content

this proposal does a couple of things

First, the files templates.yaml and templates.lock are easy to generate during faas-cli pull|build, just like Go does.

Second, this new cache scheme still allows for multiple versions of a template to be used between different projects.

Third, this also reduces the number of times a template needs to be copied to a machine.

Finally, we elimate any need to guess about colocated template folders, either they have an explicity templates.txt or not, which provides all of the needed context to decide if we should copy it into the build context, the user can easily control this.

It is important to note that this change is not backwards compatible, but we can achieve compatibility by incrementing the version in the stack.yaml . We would have version: 1.0 which stays exactly as it is today and version: 2.0 which would incidate to the CLI the new template behavior.

Version 2 would also remove the configuration.templates section because this capability is implemented by the new templates.yaml|lock

This also means we can remove the gitignore for the templates folder (if it exists) is user created.

[LucasRoesler]

Another option to enable this is to use OCI artifacts to publish and store function templates. The templates name would behave the same as docker image names, a full URI with an version tag at the end.

I have a demo of how this could work in a branch here

OCI artifacts are supported by some of the largest docker registries now, including Docker Hub, AWS ECR, and Google's GCR.