Environments

[jeffmccune]

Spike out a prototype design for environment support.

• Unify two cue instances, e.g. environments/ with projects/bank-of-holos/frontend/components/bank-frontend/
• Figure out a clean way for projects/platform/components/namespaces to manage all enviroments. Presumably just loop over a struct.
• BuildPlan names will be "\(#Environment.Name)-foo" for projects/foo/ which breaks the convention the BuildPlan Name is always the directory name. This is OK.
• Double check deploy files are handled OK.

We already unify multiple instances here, so maybe we just need to plumb this into the PlatformSpecComponent by adding a Paths []string field and deprecating Path.

[jeffmccune]

This should almost certainly just be a tag. Unifying multiple instances fails here

❯ holos render component ./environments/development/ ./projects/platform/components/namespaces
could not run: /Users/jeff/Holos/bank-of-holos/projects/platform/components/namespaces/namespaces.cue:4:8: reference "#Environment" not found (and 1 more errors) at internal/builder/builder.go:181
let[].Name: reference "#Environment" not found:
    /Users/jeff/Holos/bank-of-holos/projects/platform/components/namespaces/namespaces.cue:4:8

❯ cat environments/development/env.cue
package holos

#Environment: {
        Name: "development"
        Tag:  "dev"
}

[!NOTE] Explore adding arbitrary tags to PlatformSpecComponent

[jeffmccune]

Done in the v1alpha4 work. Environment is now a Component field passed from the platform to the build plan as a tag.

Only open question is if this should be a component field at all or just leave it to an user-defined tags. Seems fine to leave it as a field for now, though it will be hard to remove later...