Adds sample templates

[sympatheticmoose]

This PR adds 4 sample templates to enable pipeline creation through the Weave GitOps Enterprise GUI. These:

• ensure that 'Create a Pipeline' doesnt present the user with an empty screen by default
• should help a user author pipelines more easily

Need to validate how usable they are vs documented examples.

• visualization: to enable a basic pipeline based on 0.1 capabilities to visualise a helmrelease across environments
• namespace-isolation: shows minimal parameterisation based on a tenancy model using isolation by namespace.
• cluster-isolation: allows the user to specify the cluster name and namespace.
• pipeline-resources: template to create required resources on leaf clusters to enable PR promotion - Alert/Provider (not using HMAC...yet)

Missing resources that would need to be created:

• secret for HMAC (if used)
• secret for git (referenced)
• HelmReleases for applications - would be trivial to bootstrap if valuable (with an initial version shared or semver on dev)

Notes:

• consider whether to have pipeline and appref match or to use common structure like <name>-pipeline/helmrelease

[enekofb]

Comments added a couple of common themes

• to split responsibilities on what the app developer should add vs platform admin
• the expectations out of the add pipeline, in particular when you want to have a pipeline with promotions

[enekofb]

another comment would be how the update cycle would look in the context of early feedback from SAs

In the best case scenario they won't need to do changes but likely that they might need to do changes. Given that the templates are shipped within pipeline controller, how do we expect this journey would work?

a) SAs / Us to create new templates from the sample ones and to eventually retrofit the changes b) SAs to wait for new releases to

It make sense to decouple the availability of pipeline templates from the wge release cycle in particular in the early feedback / validation stage that we are.

[sympatheticmoose]

to split responsibilities on what the app developer should add vs platform admin

Could you expand on the specific concerns here? The params are there for the person associating the application with the pipeline; the rest of the template is what the administrator is setting as a standard/enforced.

the expectations out of the add pipeline, in particular when you want to have a pipeline with promotions

The way I've done this so far is to offer a set template where it is not handling promotions; are you suggesting something else?

Sorry, I'm not clear on these points? 🙂

[sympatheticmoose]

another comment would be how the update cycle would look in the context of early feedback from SAs

In the best case scenario they won't need to do changes but likely that they might need to do changes. Given that the templates are shipped within pipeline controller, how do we expect this journey would work?

a) SAs / Us to create new templates from the sample ones and to eventually retrofit the changes b) SAs to wait for new releases to

It make sense to decouple the availability of pipeline templates from the wge release cycle in particular in the early feedback / validation stage that we are.

These are purely default sample templates, the SAs/user could create new ones and install/manage themselves, these samples can be updated on a 2 week cadence based on current release process - which may not be reflected in a customer environment, but nonetheless, a very simple work around is possible.

The alternatives I considered were:

• new repo under https://github.com/weavegitops - seems short lived given impending use of catalog for these sort of artifacts, seemed slightly higher cost to implement.
• ship as profile - requires wrapping in a helm chart, unsure if it means it would appear as an available profile when adding clusters/apps, and that might not make sense

[enekofb]

closing ... splitting in single use case PRs by scenario and opening in enterprise repo