Error expanding VariableGroup variables

[markdebeer]

Describe what happened

While trying to create a new variable group in Azure DevOps I have been getting errors when running pulumi up.

Sample program

const variableGroup = new azuredevops.VariableGroup("my_variable_group", {
        projectId: "myproject",
        name: "variablegroupname",
        description: "my description",
        allowAccess: false,
        variables: [
            {
                name: "key1",
                value: "val1",
            },
        ]
    });

Log output

error:   sdk-v2/provider2.go:520: sdk.helper_schema: Expanding variable group resource data: `key1` variable can have either only `value` attribute or both `is_secret` and `secret_value` attributes: provider=azuredevops@3.4.0
    error: 1 error occurred:
        * Expanding variable group resource data: `key1` variable can have either only `value` attribute or both `is_secret` and `secret_value` attributes

Affected Resource(s)

azuredevops.VariableGroup

Output of pulumi about

CLI
Version 3.137.0 Go Version go1.23.2 Go Compiler gc

Plugins KIND NAME VERSION resource azuredevops 3.4.0 language nodejs unknown resource port 2.0.21

Host
OS darwin Version 15.0.1 Arch arm64

This project is written in nodejs: executable='/Users/mdebeer/.nvm/versions/node/v20.18.0/bin/node' version='v20.18.0'

Backend
Name
URL s3:// User mdebeer Organizations
Token type personal

Dependencies: NAME VERSION @port-labs/port 2.0.21 @pulumi/azuredevops 3.4.0 @pulumi/pulumi 3.137.0

Additional context

I've tried different variations of the variables value. One with just secrets, one iteration with both secrets and regular variables but no matter what I get the same error message.

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

[danielrbradley]

Thanks for reporting this @markdebeer

I've managed to reproduce this issue myself. This affects all languages, not only Typescript.

This error is being thrown by a new piece of validation logic which was added in the upstream provider in v1.2.0 and therefore affects this provider's version v3.2.0 and above. Here's the change which added the extra validation:

• https://github.com/microsoft/terraform-provider-azuredevops/pull/1075

It appears our bridging framework is presenting the interpreted values to the provider slightly differently to when using terraform directly.

        name := ctyVariableAsMap[vgName].AsString()
        valueSet := !ctyVariableAsMap[vgValue].IsNull()
        secretValueSet := !ctyVariableAsMap[secretVgValue].IsNull()
        isSecretSet := !ctyVariableAsMap[vgIsSecret].IsNull()

The validation code is expecting unpopulated values to come through as Nulls, whereas via the bridge they're being populated with their default values ("", and false).

I'll open an issue to investigate this further in the bridge.

[danielrbradley]

We need to address this in the short term in this repo rather than the bridge. Current options to investigate:

1. Remove the defaults so we don't set any values automatically and just leave them all undefined.
2. See if there's a hook where we can intercept and fix the defaults before they get passed back to the upstream provider.
3. Move from a Go package reference to using a submodule and introduce a manual patch to change the validation logic.