Merge garden-project.yml and garden.yml into one format?

[edvald]

It bothers me a little that we have one type of file called garden-project.yml and then garden.yml files in module directories. Both the aesthetics of it, and for a practical reason, which is that a project will be able to reference other repos. So when you’re in a repository that contains a single module, there is no garden-project.yml and we’ll have a weird usability issue (what happens when you run garden in a module repo root?).

My proposal is this: We merge the two spec files into one garden.yml, and add top level project and module keys (and possibly a plural modules or external-modules key, to facilitate adding multiple references to other repos).

Example

Project root:

project:
  name: hello-world
  environments:
    local:
      providers:
        docker:
          type: kubernetes
          context: docker-for-desktop
        gcf:
          type: local-google-cloud-functions
    dev:
      providers:
        docker:
          type: google-app-engine
        gcf:
          type: google-cloud-functions
          default-project: garden-hello-world
  variables:
    my-variable: hello-variable

Module:

module:
  description: Hello world container service
  type: container
  services:
    hello-container:
      command: [npm, start]
      endpoints:
        - paths: [/hello]
          containerPort: 8080
      healthCheck:
        httpGet:
          path: /_ah/health
          port: 8080
      dependencies:
        - hello-function
  build:
    dependencies:
      - hello-npm-package
  test:
    unit:
      command: [npm, test]
    integ:
      command: [npm, run, integ]
      dependencies:
        - hello-function

I feel like this'd feel a bit cleaner, plus it opens up a bit of flexibility in our configuration down the road imo. Thoughts?

[edvald]

Another example, where you have a single-module project:

project:
  name: hello-world
  environments:
    local:
      providers:
        docker:
          type: kubernetes
          context: docker-for-desktop
  variables:
    my-variable: hello-variable
module:
  description: Hello world container service
  type: container
  services:
    hello-container:
      command: [npm, start]
      endpoints:
        - paths: [/hello]
          containerPort: 8080
      healthCheck:
        httpGet:
          path: /_ah/health
          port: 8080
  test:
    unit:
      command: [npm, test]

[thsig]

+1.

I think a garden.yml file intuitively means "here is some Garden config, contextualized to this directory". That is, bits and pieces of the total config, all using the same DSL.

I can't think of any good reason for maintaining the garden.yml/ garden-project.yml split, and as you say, this new design would be more flexible going forward. E.g. if we later wanted to add more configuration categories than "project" and "module".

[eysi09]

Agree. Would it make sense, for those inclined to do so, to allow specifying everything in the top level garden.yml.

Something like:

project:
  name: hello-world
  environments: ...
modules:
  - name: module-a
     dir: /path/to/module-a
     description: Module A description
     type: container
  
  - name: module-b
     dir: /path/to/module-b
     description: Module B description
     type: container

[edvald]

That'd be a fairly simple addition. I just wonder if we should be allowing multiple ways to declare stuff... I can see the merit though, if people generally prefer a single file to declare stuff.

[edvald]

Done in #57