feat(internal/config): add workspace variable

[denysvitali]

This commit adds the ${workspace} variable, so that one can have
a single .hcl file deployed across multiple workspaces
(e.g: multi-branch gitops repo) and merge easily the .hcl files
without having to worry about a branch-dependant variable.

project = "waypoint-workspace-demo"

app "kibana-xyz" {
    build {
        use "docker-pull" {
            image = "kibana"
            tag   = "latest"
        }
    }

    deploy {
        use "cloudfoundry" {
            organisation = "some-org"
            space = "space-${workspace}"
	}
    }
}

This change is probably also useful for Kubernetes and Nomad,
as you could have a 1:1 mapping between Waypoint workspaces and
Kubernetes / Nomad namespaces. Since it's provided as a variable,
the possibilities are endless.

Example

waypoint up -workspace=default

Results, in this case in:

» Deploying...
 + Validating parameters
 + Connecting to Cloud Foundry at https://swisscom.ch
 + Selecting organisation: some-org
 + Selecting space: space-develop
 + Searching app: kibana-xyz-e6fa4bcd [not found]

---

waypoint up -workspace=staging

Results, in this case in:

» Deploying...
 + Validating parameters
 + Connecting to Cloud Foundry at https://swisscom.ch
 + Selecting organisation: some-org
 + Selecting space: space-staging
 + Searching app: kibana-xyz-6092d4c4 [not found]

[mitchellh]

I'm supportive of adding a workspace var. The way you've added it makes it only available to the current app being loaded, and therefore the workspace var can't be used outside of an app {} stanza. I think that's a fine restriction for now... but it bears some thought.

Any bikeshedding @evanphx or anyone else @hashicorp/waypoint on the name of this var?

[briancain]

Any bikeshedding @evanphx or anyone else @hashicorp/waypoint on the name of this var?

😄 workspace makes sense as long as its Waypoint Workspaces

[mitchellh]

One thought is to make workspace the map and make workspace.name the value of the workspace name, in case we want to dangle off any other information about the workspace in the future.

[denysvitali]

One thought is to make workspace the map and make workspace.name the value of the workspace name, in case we want to dangle off any other information about the workspace in the future.

Actually, this was my first implementation that I tried, but passing around the project variable was causing a dependency cycle. In addition to that, I haven't found anything useful related to the workspace that I could have fit eventually in that variable.

${workspace} is definitely shorter, but ${workspace.name} allows for extensions in the future, although I currently don't see any relevant information about the workspace other than its name yet.

Using ${workspace.name} might also be preferred, so that we are aligned, syntax-wise, with path

[krantzinator]

Would it work to add workspace (string or map) to Config? That way we don't need to add additional args in this way to the App method, and the value(s) in workspace could be more broadly available. I know we don't need it in other places right now, but I feel like that way fits our current data model a bit more cleanly.
That's my bike shed, anyway 😄

[denysvitali]

Yes, it totally makes sense to me!

[mitchellh]

Rae was on the right path, I took it a bit farther. I grabbed your PR and made some modifications:

I made the workspace name arg part of config.Load. This makes it available to all the config, not just the app stanza. So you can use workspace.name in the root part for example. I also changed the workspace var to be a map as we discussed and used workspace.name. Merging now.

[mitchellh]

Merged!

[krantzinator]

For reference: 793b8ef