Make unknown task warnings clearer & provide guidance to login for auto-detection

[asdkant-bf]

I'm refactoring a pipeline in vscode and similar to #404 I'm getting the "String does not match the pattern of" warning but with the tasks below:

• SonarCloudPrepare@1
• SonarCloudAnalyze@1
• SonarCloudPublish@1
• replacetokens@3
• android-manifest-package-name@1
• motz-ios-entitlement-transform@1
• ios-bundle-version@1
• ios-bundle-identifier@1
• AppStoreRelease@1

I've read elsewhere that this happens due to the tasks not being in the schema, but it doesn't sound maintainable to me to keep updating the schema with the whole list of tasks available in the marketplace (most of these are from the marketplace).

At the very least, how do I suppress these warning messages?

[ismayilov-ismayil]

Hi @asdkant-bf, could you please share sample pipeline where you get error?

[asdkant-bf]

@ismayilov-ismayil this one triggers the issue:

trigger:
- main

pool:
  vmImage: ubuntu-latest

steps:

- task: SonarCloudPrepare@1
  inputs:
    SonarCloud: 'SonarCloud'
    organization: 'orgname'
    scannerMode: 'CLI'
    configMode: 'manual'
    cliProjectKey: 'projKey'
    cliProjectName: 'ProjName'
- task: SonarCloudAnalyze@1
- task: SonarCloudPublish@1
  inputs:
    pollingTimeoutSec: '300'

[asdkant-bf]

I managed to get rid of the warnings by logging in with the Azure Pipelines extension, but I still think it'd be nice to have a fallback that doesn't require logging in... if logging in just queries for the schema in that particular org, the warning could happen if I try to use a task that is not yet available. There should be an obvious way to tell vscode "this task is valid, don't worry".

The warning is also unhelpful, instead of a string matching error it should say something along the lines of "task not found in the schema, to fix this you can do such and such".

[50Wliu]

This is good feedback, thanks Ariel. I agree that the default schema validation warning is quite unhelpful - maybe we can try to suppress it and surface a custom warning instead.

Since technically everything is working as expected, I'm going to rename this issue to better reflect the feature you're requesting.