What should be managable via .lagoon.yml?

[tobybellwood]

Currently the .lagoon.yml can be used to:

• Configure cronjobs
• Set up pre/post rollout tasks
• Define routes
• Handle private container registries
• Configure some route settings
• Manage some environment-specific overrides
  (See https://docs.lagoon.sh/lagoon/using-lagoon-the-basics/lagoon-yml#ssl-configuration-tls-acme)

What else should be managed by .lagoon.yml - is there stuff that happens elsewhere (eg in docker-compose.yml, or variable files) that should be here?

Do users want full control via .lagoon.yml, or is some level of managed support in addition to .lagoon.yml preferable?

[smlx]

Maybe project or environment-level feature flags. Currently we implement several feature flags in Lagoon via environment variables, but this is just an implementation detail. Maybe it makes sense to move those into the .lagoon.yml? That way customer environments aren't cluttered with platform configuration environment variables.

[shreddedbacon]

This one isn't specifically related to whats manageable via .lagoon.yml but more management of the .lagoon.yml specifically.

There are numerous occasions where different branches contain different versions of this file, and merge conflicts, or missing sections have caused issues. Or a customer is using some external automation tool to manage the .lagoon.yml across multiple branches and repositories to ensure state is correct.

The .lagoon.yml supports multiple environment configurations within it, and having this shared across multiple branches in a repository can be confusing, especially when trying to troubleshoot deployment issues.

I'm proposing to strip the .lagoon.yml out of branches and the repository, and have users commit the .lagoon.yml to the project in Lagoon via the API.

• Lagoon can pass this around as part of the build process and inject it into the builds.
• It gives Lagoon administrators and users instant access to the file via the API, no need to wait for it to be commit to a repo, or for a build to complete for it to be saved into kubernetes
• It gives Lagoon administrators and users the ability to modify the file via the API, as an administrator it allows you to make changes if required without having to wait for users to modify their branch(es).

I could see the interaction with the API using the CLI something like this:

lagoon get yaml --project example-com --output example-com-lagoon.yml
# user modifies file
lagoon update yaml --project example-com --input example-com-lagoon.yml

Any deployments would use the latest version from the API.

We could then fall back to whatever is in the repository if the one in the API is non-existent.