azure-pipelines-vscode: Template expressions cause syntax errors in YAML files

We’re looking into when we can fund it. Now that template parameters and other template-using features have gathered some steam, the current behavior is becoming less and less defensible.

Supporting this is really important in my eyes! Please put this in a high priority bucket!

- ${{ each configuration in parameters.configurations }}: also produces errors but my guess is it’s related.

This issue has more than 2 years now. Really, MSFT? Just look how my file look like now…

Would be great to have this fixed!

Hey, any news / roadmap on this one? It would be great if this could be fixed soon

Bumping because this bug can be quite distracting for large code blocks. Are there plans to address this soon?

All right everyone, progress update. Here’s where I’m at.

For those interested, the pull request is at https://github.com/microsoft/azure-pipelines-language-server/pull/93; I plan to add some unit tests in the next few days before putting it up for review but overall I’m happy with the code changes.

Caveats

• There is absolutely no validation on whether the expression is valid. None. In fact, the logic I’m using to determine whether something is an expression is “does the key start with ${{?”. I decided the extra effort to add validation isn’t worth it at this time.
• For expressions that add the same input property in different conditions (e.g. artifact in the GIF), only the last variation will have tooltips. This is a limitation of the language server, which assumes all inputs are unique (a perfectly reasonable assumption for cases other than expressions). Again, fixing this would take considerable effort, more than I’m willing to invest.

I’m sorry to report that we haven’t made any improvements here. It’s still on my radar but continues getting starved by other projects.

1.191.0 is released and contains the initial support for template expressions! I’ve created a tracking bug for the incorrect warning validation at #420.

FWIW I have a somewhat-hacky branch on azure-pipelines-language-server that fixes this: https://github.com/microsoft/azure-pipelines-language-server/pull/93

Work really picked up these past two weeks though so I haven’t had time to revisit it and finish it up/figure out if the direction I’m taking is a good approach or not (and I haven’t brought it up yet because I’m not confident it’s the right approach).

Hi there, Issue at the stage level : The pipelines using this template run fine 🤞 to get a fix soon

Adding my voice to the chorus as we need this very much. Thanks!

@jason-ha you’ll need to follow the steps here to get the extension to recognize any custom tasks your organization has installed.

@cal5barton can you hover over the warning and tell me what it’s reporting? Likely it’s String does not match the pattern of "^[_A-Za-z0-9]*$". which I’ll target for a later release (don’t want to delay this one further), but want to double-check in case it’s low-hanging fruit.

Now that I’ve fixed the crash I was seeing, once again going to try to get a published release out next week.

Here’s a dev version of the extension that contains support for template expressions. To install, unzip it, then open VS Code and select “Install from VSIX” from the Extensions three-dot menu:

Please test it and report any issues if you can! If testing goes well, I’ll try to get a new version published next week 😃.

azure-pipelines-1.188.2-pr-409-13671ee.zip

All right everyone, progress update. Here’s where I’m at.

For those interested, the pull request is at microsoft/azure-pipelines-language-server#93; I plan to add some unit tests in the next few days before putting it up for review but overall I’m happy with the code changes.

Caveats

• There is absolutely no validation on whether the expression is valid. None. In fact, the logic I’m using to determine whether something is an expression is “does the key start with ${{?”. I decided the extra effort to add validation isn’t worth it at this time.
• For expressions that add the same input property in different conditions (e.g. artifact in the GIF), only the last variation will have tooltips. This is a limitation of the language server, which assumes all inputs are unique (a perfectly reasonable assumption for cases other than expressions). Again, fixing this would take considerable effort, more than I’m willing to invest.

Awesome!

FWIW you can see the pattern I used to match the expressions in the YAML schema. I think it is a valid tradeoff to just pattern match the brackets and not validate the expression (as it’s runtime anyways).

FYI this is a problem for steps (and since it’s valid anywhere in the yaml…everything…) - hard to believe this is a difficult to solve issue (${{ should always be a valid tag?) but good luck ppl I’ll leave this to those who javascript 🤞

The workaround from @parthmishra is a massive improvement, something similar for stages/jobs would be an easy 80/20 solution that would drastically improve the experience for most people. If this extension hasn’t been abandoned, can that get added to the default schema here and in Azure DevOps itself to at least make this usable?

This is a known issue. Template expressions as keys are not yet supported everywhere. Sorry - we’re getting to it!

@50Wliu Incorrect type. Expected “object”.

Here’s a dev version of the extension that contains support for template expressions. To install, unzip it, then open VS Code and select “Install from VSIX” from the Extensions three-dot menu:

Please test it and report any issues if you can! If testing goes well, I’ll try to get a new version published next week 😃.

azure-pipelines-1.188.2-pr-409-13671ee.zip

It’s close to being fixed for me, still have this.

Here’s a dev version of the extension that contains support for template expressions. To install, unzip it, then open VS Code and select “Install from VSIX” from the Extensions three-dot menu:

Please test it and report any issues if you can! If testing goes well, I’ll try to get a new version published next week 😃.

azure-pipelines-1.188.2-pr-409-13671ee.zip

It worked for me, thanks!

@50Wliu If I use an emoji somewhere in the YAML it breaks with at the top saying “Invalid YAML structure”.

steps:
    - pwsh: foo
      displayName: 😢 bar

How will my pipelines survive without these emojis? 😅 (We actually use emojis heavily)

Edit: Oh, that was actually an old issue. (#384) I suppose I’ll go back to the RedHat extension again 😕

I wrote some custom definitions for steps, stages, jobs, and tasks (for when you import them from a parameter)

Hopefully it’ll help some of you until MS fixes this 😃

https://gist.github.com/zleight1/a532867d1a0363e759a3e5939d36b727

Any updates on this? This bug is now forcing me to use templates.

This is my hacky workaround since I’m not familiar with JSON Schema at all so someone may have a better workaround, but what I did was clone the service-schema.json file to make a custom, modified one and added a patternProperties match for places where I use template expressions e.g.

"step": {
      "anyOf": [
        {
          "type": "object",
          "patternProperties": {
            "\\${{ .* }}": {
              "anyOf": [
                {
                  "type": "array",
                  "items": {
                    "$ref": "#/definitions/step"
                  }
                }
              ]
            }
          },
          "additionalProperties": false
        },
       ...

This silences most annoying cases of template expressions being interpreted as tasks/scripts/etc. but I haven’t thoroughly tested this.

We’re looking into when we can fund it. Now that template parameters and other template-using features have gathered some steam, the current behavior is becoming less and less defensible.

Thank you very much