introduce own "deploy.yml" files with sensible defaults

[Aleksion]

There's currently a lot of redundancy in the deployment.yaml. There might definitely be cases where I as a developer want to change what I use (deployment/service/ingress/secrets?), but couldn't we either make them configurable in a more brief config language or just allow users to manually override by providing their own k8s.yml.

Meaning we look for either a deploy.yml or a k8s.yml. Where the latter is what you currently have, but the first one is a subset that would allow for the following:

name: Example
namespace: Example
version: 1.0  # (maybe this should be implicitly handled by default?)
image: DOCKER_IMAGE
root-domain: https://example.com

which would then be interpreted and used to generate the k8s.yml file. In Clojure I'd use something like this: https://github.com/nubank/k8s-api

[stephenlacy]

I like the idea, I also agree for a majority of cases k8s config is too verbose. In essence we are creating a yaml DSL abstraction for a container backend? I could see this used to point generic config to several backends such as docker compose or k8s.

name: Example
version: 1.0  # Retrieved from a lerna.json/package.json and or implicitly handled?
image: DOCKER_IMAGE # Optional - this would use the `packages/package-name/Dockerfile` and build the image on deploy
domain: https://example.com

mono up or mono up package-name

[stephenlacy]

One interesting aspect is the concept of migrating a single package deployment to a future mono-repo. For instance, a project starts with a single package in the root directory. A single deploy.yaml and mono up would suffice. As the project progresses, the root package could be moved into a packages folder and have sibling packages.

[Aleksion]

I like it a lot. In theory we could make it default all those values, so getting started is as simple as possible:

• If we're not in a monorepo, mono automatically figures out what to run and deploy (let's make it easy and start with Docker. So it runs the Dockerfile in the root)
• It defaults the name, the version and assigns a generic URL - if possible?
• all of it it is overridable in our on DSL abstraction.