Cannot up dynamically created stacks using 3.40.2

[johnkors]

What happened?

3.40.0 can up dynamically created stacks (eg. pr pull request)
3.40.2 errors when up'-ing a dynamically created stack

Steps to reproduce

We're creating stacks dynamically using github actions:

    - name: Create new pr stack
      run: |
        pulumi stack init --non-interactive --logtostderr "${{ env.STACK_NAME }}" --copy-config-from myorg/test
      working-directory: ./infra
      env:
        PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
      continue-on-error: true # init fails if exists
    - name: Init some configs
      run: |
        pulumi config cp --non-interactive --logtostderr --stack myorg/test --dest "${{ env.STACK_NAME }}" // ex: "pull68"
      working-directory: ./infra
      env:
        PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
    - uses: pulumi/actions@v3
      id: pulumi
      with:
        command: up
        stack-name: ${{ env.STACK_NAME }}
        work-dir: ./infra
        pulumi-version: 3.40.2
      env:
        PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
        ARM_CLIENT_ID: ${{ secrets.ARM_CLIENT_ID }}
        ARM_CLIENT_SECRET: ${{ secrets.ARM_CLIENT_SECRET }}
        ARM_TENANT_ID: ${{ secrets.ARM_TENANT_ID }}
        ARM_SUBSCRIPTION_ID: ${{ secrets.ARM_SUBSCRIPTION_ID }}

Errorlog:

Run pulumi/actions@v3
  with:
    command: up
    stack-name: myorg/pull68
    work-dir: ./infra
    comment-on-pr: false
    github-token: ***
..snip
Error: code: -2
 stdout: 
 stderr: Command failed with exit code 255: pulumi stack select myorg/pull68 --non-interactive
error: could not get cloud url: could not load current project: 1 error occurred:
	* #/config: expected string or null, but got object

Expected Behavior

Being able to up the stack.

Actual Behavior

Errors:

 stderr: Command failed with exit code 255: pulumi stack select myorg/pull68 --non-interactive
error: could not get cloud url: could not load current project: 1 error occurred:
	* #/config: expected string or null, but got object

Output of pulumi about

Can be provided if necessary

Additional context

Reverting to pulumi-version: 3.40.0 fixes the issue and works as expected.

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[Frassle]

What's your Pulumi.yaml in /infra look like? Does it have "config" set?

[johnkors]

Yes.

Pulumi.yaml

name: myName
runtime: dotnet
description: someDEsc
config:
  azure-native:location: norwayeast

[Zaid-Ajaj]

@johnkors as of now, the project file doesn't read configuration from the config property, it can only be read from the stack files. This means that the config block here has basically no effect at all and can be removed. Pulumi v3.40.2 now verifies the project file against a strict schema which as of now says that config can only be a string (path to directory with stack files)

That said, I am working on Hierarchical and structured config implementation: the initial pass which make your use case viable, but it is still work-in-progress

[johnkors]

Sounds like a breaking change in a patch to me (3.40.2 now contains breaking changes compared to 3.40.0).

How about instead of throwing errors, you provide a warning explaining a way of migration to the "new" way of using config?

[Zaid-Ajaj]

Sounds like a breaking change in a patch to me (3.40.2 now contains breaking changes compared to 3.40.0).

We didn't change how config is being read, only wrote a validator to what we already supported. The config property was never used for defining configuration values at the project level. That is what my PR is going to implement.

you provide a warning explaining a way of migration to the "new" way of using config?

As of now, you can only use the config property to define a path to a directory that contains stacks. When the PR for hierarchical config lands, this option will still be available, but if you change it into an object to define configuration values, then it will work as expected for your use case.

[johnkors]

Ah, I think I understand what has happened here.

I had a Pulumi.yaml with a config section (doing nothing) using a deprecated attribute (with valid values in an earlier version of Pulumi).

In 3.40.2 you re-used this deprecated attribute for something else. Breaks back compat, but yeah - now I understand why at least.

[christophstockinger]

Same problem. After changing the version to 3.40.0, the deployment works.

Also, I find it interesting that 8 days ago version 3.40.1 was released, yet in my Github action yesterday the official Pulumi action used version 3.40.0 even though I did not specify an exact version.

[johnkors]

only wrote a validator to what we already supported

Yeah, got it. This broke for developers using a an old Pulumi.yaml not yet migrated (meaning removing their config from the YAML). I get why you don't see it as a breaking change, though — but this will probably affect everyone with an old Pulumi.yaml. Probably very common to update the CLI, but not touch the yaml. I haven't at least been aware of that I should remove the config section (again: should perhaps provide a warning about it being deprecated..?).

I think the safest option would for the new feature of config to not re-use an old deprecated attribute, but use a new one configPath or something that not has been used before as they have very different purposes in what you are describing and what was deprecated.

[Frassle]

I think the safest option would for the new feature of config to not re-use an old deprecated attribute, but use a new one configPath or something that not has been used before.

We do. "config" has never supported setting actual config options before. It used to be used to set the path to store config yaml files at, and it can still be used for that but we do also now have "configPath" to set that which will eventually be the only supported way. When we add top level config support we will also continue to allow "config" to just be a string point to the folder path but obviously if you want to make use of the new top level config support that will have to be moved to "configPath".

The only thing that changed regarding config between 3.40.0 and 3.40.2 is that now when we read the Pulumi.yaml we assert that it's actually correct. The azure-native:location: norwayeast value in that Pulumi.yaml will never have done anything before, while now we flag it as an error.

[johnkors]

Ok, sorry, sorry. Thanks for detailing this out. I have no way of verifying if it was added via tooling or a copy-paste issue, but then most likely this is then caused by me manually adding an invalid config property to Pulumi.yaml that would only be valid if added to a Pulumi.stackname.yaml. Correct? PEBKAC 🤦

I think I might have wrongly assumed it supported "default" values at some point back when.

[Frassle]

Correct?

Correct, "config" is currently only valid in Pulumi.stackname.yaml files, but we do hope to add default support in Pulumi.yaml files very very soon!

[johnkors]

Would have been hilarious if what I wrongly assumed working just started to work when you released it 😆. But if I understand, it will be solved differently to what I tried here.

Closing this issue anyways. Thanks alot!