config-map failing with "Expected string, but was null" in v4.2

[mikocot]

What happened?

Pipeline failures after release of v4.2.

Pipeline code:

 uses: pulumi/actions@v4
[...]
 config-map: | # provide required configuration
   { prNumber: { value: ${{ github.event.pull_request.number }} } }

Error message
Validation failed: { "prNumber": { "value": "Expected string, but was null" } }. Object should match { [_: string]: { value: string; secret?: boolean; } }

The same happens if ${{ github.event.pull_request.number }} is provided, but it's a number, the error is then:

"Expected string, but was number"

Expected Behavior

No breaking changes in minor release.
Changes in interface communicated in release notes and PR descriptions

Steps to reproduce

See code above

Output of pulumi about

not essentiral here

Additional context

The issue can be fixed by wrapping params in double quotes or ensuring it's a string.

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).

[mikocot]

seems to be related to changes in this PR: #813
but as there is no description it's hard to say if it was intended or not.

[simenandre]

Hey, thanks for reporting this!

It's related to #813; I'll look at a fix very soon!

[mikocot]

I can imagine this was by design, but at least the previous version was more forgiving and many are likely to depend on it.
Accepting numbers / bools feels reasonable, but if they are going to be converted to strings anyway, it might be better to be explicit, so I'm not exactly opposed to that change, rather the way it was done :)

[simenandre]

I can imagine this was by design, but at least the previous version was more forgiving and many are likely to depend on it. Accepting numbers / bools feels reasonable, but if they are going to be converted to strings anyway, it might be better to be explicit, so I'm not exactly opposed to that change, rather the way it was done :)

I agree, so I'm pushing for a quick release here. My reasoning was that I naively thought the types defined in Automation APIs setAllConfigMap was what users were adhering too.

[arminrosu]

For reference, we're seeing the same kinds of errors with boolean types.

In the GHA workflow below, workflow_dispatch (manual trigger) works, but pushes to master fail with:

Error: Input does not meet YAML 1.2 "Core Schema" specification: refresh
Support boolean input list: `true | True | TRUE | false | False | FALSE`

name: Pulumi Update
on:
  push:
    branch:
      - master
  workflow_dispatch:
    inputs:
      refresh:
        description: Should pulumi run refresh?
        default: false
        required: false
        type: boolean
# ...
jobs:
  pulumi-update:
    steps:
      # ...
      - name: Run pulumi up
        uses: pulumi/actions@v4
        id: pulumi-up
        with:
          refresh: ${{ github.event.inputs.refresh }}

Probably github.event.inputs.refresh is undefined, d'uh.

I can fix it, but it's a nuisance considering this was a non-major release.

[mikocot]

I agree, so I'm pushing for a quick release here. My reasoning was that I naively thought the types defined in Automation APIs setAllConfigMap was what users were adhering too.

Haha, it might be a bit far connection for most users :)

[simenandre]

I agree, so I'm pushing for a quick release here. My reasoning was that I naively thought the types defined in Automation APIs setAllConfigMap was what users were adhering too.

Haha, it might be a bit far connection for most users :)

Yeah, I was quite naive 😅

Fix coming up!

[arminrosu]

Yeah, I was quite naive 😅

I call it "optimistic" 😉. No worries, thanks for the swift response.

[simenandre]

I hope v4.2.1 fixes the issues!

I'm closing this for now, but please let me know if it continues!