0

I'm working on an Azure DevOps extension with a pipeline task. Currently I've published a public "official" version (ID: pr-commentator) of the extension and a private version (ID: pr-commentator-dev) for testing. I want to have both versions installed on my test ADO project to be able to test them, however, I'm struggling to figure out how to distinguish the tasks from each when setting up a pipline, as I seem to only be able to reference the non-unique name of the task:

# azure-pipelines.yaml

steps:
- task: PrCommentator@0 # Same name in both extensions
  inputs:
   # ...

The extension IDs and IDs for the tasks in each extension are all unique as required, but the task names are the same. Since there's no requirement for the name to be unique I'd assume there was a way to reference the one from the specific extension, but I can't figure out how.

I tried things like - task: pr-commentator-dev:PrCommentator@0 and - task: pr-commentator-dev@PrCommentator@0, but the YAML editor doesn't seem to recognize that.

Is this simply not achievable (which means extensions can actually be incompatible)? I'm trying to simplify my extension publish workflow, but I'm wondering if I need to maintain different task names too.

Xerillio
  • 4,855
  • 1
  • 17
  • 28

1 Answers1

1

Turns out I missed it in this article in the documentation. From the docs:

steps:
- task: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #format example
- task: qetza.replacetokens.replacetokens-task.replacetokens@3 #working example

In my case, this worked:

# azure-pipelines.yaml

steps:
- task: xerillio.pr-commentator-dev.task.PrCommentator@0
  inputs:
   # ...

Taken from these parts of the manifest files:

// vss-extension.json
{
    "id": "pr-commentator-dev",  // == 'myExtensionId'
    "publisher": "xerillio",     // == 'myPublisherId'
    // ...
    "contributions": [
        {
            "id": "task",        // == 'myContributionId'
            "type": "ms.vss-distributed-task.task",
            "targets": ["ms.vss-distributed-task.tasks"],
            "properties": {
                "name": ".task"
            }
        }
    ]
}

// task.json
{
    "name": "PrCommentator",     // == 'myTaskName'
    // ...
}

Unfortunately, the Azure DevOps web designer/YAML editor isn't very helpful when using this fully qualified name, as it just displays this warning:

String does not match the pattern of "^PowerShell@2$". Value is not accepted. Valid values: "PowerShell@2", "PowerShell@1", ... [long list follows]

But running the pipeline works and runs the expected task.

Xerillio
  • 4,855
  • 1
  • 17
  • 28
  • Since the contributionId is reflected in the long name, think long and hard about the name you pick. Like the extensionId and the task.Name these values will haunt you forever. You can also reference an exact task by using the taskId@version syntax. – jessehouwing May 22 '23 at 21:21
  • 1
    Relevant: https://stackoverflow.com/a/56029399/736079 – jessehouwing May 22 '23 at 21:27
  • @jessehouwing Thanks, there's some great points I'll consider and probably implement in my current setup, which uses variable collections to set different ext. IDs. I'll probably create a test organisation to avoid some headaches. – Xerillio May 23 '23 at 16:40
  • @jessehouwing Is there anything specific I should take into consideration regarding the contributionId? I only have one task (no current plans for others in that extension) so it seems like an arbitrary pick for me. – Xerillio May 23 '23 at 16:42
  • 1
    Just that `task` is very generic... and singular. So far I've opted to just replicate the task-name as the contribution. If needed postfixed by `task`. I've made some bad choices in the past and due to arbitrary validation rules, once you pick a taskname and a contributionId it's terribly hard to change them. This old blogposts vents some frustration around that topic: https://jessehouwing.net/azure-devops-renaming-an-azure-pipeline-task-in-an-existing-extension/ – jessehouwing May 23 '23 at 18:19