Recognize the new core project-level config block

[aq17]

Fixes #369

[Frassle]

My understanding of @AaronFriel's explanation around this was that YAML was going to stop looking at the config block directly and look at config and configSecretKeys in the run request from the engine instead.

[aq17]

So YAML would use the Go SDK to do things like conf.TryInt("instanceSize") instead of the project file config block? If so, would it make sense to have a separate syntax instead of interpolated expressions to get a config value, i.e. conf.instanceSize

cc @iwahbe

[iwahbe]

We already use the go SDK to pull config values, see

pulumi-yaml/pkg/pulumiyaml/run.go

Lines 845 to 850 in 0197f65

	case ctypes.String:
	if isSecretInConfig {
	v, err = config.TrySecret(e.pulumiCtx, k)
	} else {
	v, err = config.Try(e.pulumiCtx, k)
	}

In the past, we needed to read the config to known what values to pull into scope, and what defaults to provide. If defaults will be handled for us, we can just inject config values into our scope and error (during topologicallySortedResources) when attempting to use missing values.

I don't see why changing the implementation should change the user syntax.

[iwahbe]

It would be great to start seeing tests for getPulumiConfNodes

[iwahbe]

Misclicked on approve

[aq17]

For updating our examples and being able to convert YAML->PCL, we may need to parse the config block? @iwahbe

[iwahbe]

For updating our examples and being able to convert YAML->PCL, we may need to parse the config block? @iwahbe

Parsing the config block is complicated already, and will get more so when we introduce new sources of config. Even now, consider the following 3 files:

Pulumi.yaml:

name: proj
runtime: yaml
main: src/Main.yaml
config:
  prefix: 
    default: abc

Pulumi.dev.yaml:

config:
  pros:tag: tag2

src/Main.yaml:

resources:
  bucket:
    type: aws:s3:Bucket
    properties:
      bucket: ${prefix}-bucket
      tags:
        stackTag: ${tag}

I can see how we will need the information though. Right now, I think we can continue going through configuration for this. In the future we can add the ability to describe the config when converting YAML->PCL.

[Frassle]

In the future we can add the ability to describe the config when converting YAML->PCL.

I think that might sync well with the ideas of code generating config types for the other languages. We should try to make sure those two things use the same language.

[iwahbe]

I left some comments. There are a couple places to clean up, but I think its getting close.

[iwahbe]

I left 1 very minor nit, but LGTM!