[Feature Req] Template store to allow custom sub-directory path to "template"

justinfx commented 4 years ago

When hosting a custom template within a repository, it is a requirement that the templates live in a "template" folder at the root of the project. And the template store json can only reference the repository, following the expectation that templates live within that root folder.

It would be very flexible to allow a project to additionally host openfaas templates, and to choose where to place these within a sub-directory path. The template store should then also be able to describe the optional template path value.

I'm looking to see if this is a desirable feature, what aspects would need to be changed to be accepted, and whether there was an initial thought or effort to support this, or if I should contribute to it?

Expected Behaviour

A project that also provides openfaas templates should be able to host templates from:

projectRoot/
    docs/
    source/
        go_stuff
        python_stuff
        java_stuff
    deploy/
        faas/
            templates/
                <custom templates here>
            templates.json

template.json

[
  {
    "template": "my-template",
    "platform": "x86_64",
    "language": "Go",
    "source": "my-company",
    "description": "A custom template",
    "repo": "https://gitlab.company.com/group/proj",
    "path": "deploy/faas/templates",
    "official": "false"
  }
...

Current Behaviour

faas-cli has a hard-coded requirement that there be a root-level "template" directory in the repository, and a store can only define the repository:

projectRoot/
    docs/
    source/
        go_stuff
        python_stuff
        java_stuff
    templates/
        <custom templates here>
    templates.json

template.json

[
  {
    "template": "my-template",
    "platform": "x86_64",
    "language": "Go",
    "source": "my-company",
    "description": "A custom template",
    "repo": "https://gitlab.company.com/group/proj",
    "official": "false"
  }
...

Possible Solution

If a "path" value could be provided in a template store, it could be passed into updated api functions in faas-cli/commands package when fetching templates. The default would still be the root level "template" directory.

Context

I am working to integrate openfaas at my company, behind a restrictive proxy. My solution to providing openfaas functions and microservices is to customise the templates to use our internal container image proxy/repo, and various other custom image tweaks. I would like to host these templates within a larger project as opposed to creating a new repo solely for the templates. It would be nice for the faas-cli and template store logic to support this workflow.

Your Environment

FaaS-CLI version ( Full output from: faas-cli version ): 0.12.2
Docker version ( Full output from: docker version ): 19.03.08
Are you using Docker Swarm (FaaS-swarm ) or Kubernetes (FaaS-netes)? Kubernetes / faas-netes
Operating System and version (e.g. Linux, Windows, MacOS): linux

justinfx commented 4 years ago

I have a working local branch with this feature, should it be something that is considered valuable; I could submit a patch.

The changes affect the template store pull / list / describe commands, by allowing a template store to consider an optional "path" to use instead of "./template" at the root of the repo.

The stack yaml support is updated to also accept a "path" string field in addition to the "name" and "source" of a template.

The template pull command is also updated to allow an optional path arg after the repository.

faas-cli template pull 'https://gitlab.company.com/group/project#branch' path/to/template

alexellis commented 3 years ago

What's the issue with using a templates repo?

justinfx commented 3 years ago

It would be more convenient and align with our build and deploy system to have the templates live and be versioned with the project for which they are being used. I figure since this doesn't break existing behaviour and makes it possible to have a monorepo, that the flexibility would be a benefit and enable users to deploy templates in different ways.

openfaas / faas-cli