outputVariable has disappeared, not working about azure-devops-extension-tasks HOT 6 CLOSED

One of my pipelines was using the outputVariable parameter and as a result broke. Was able to get my pipeline working again with this information. Thank you.

from azure-devops-extension-tasks.

See: https://stackoverflow.com/questions/73609332/use-an-output-variable-as-a-global-variable-in-azure-yaml-pipeline/73609482#73609482

I've updated the task to always register the value as an output variable and we've taken away the ability to specify it.

Instead, just name the task and the variable will always add: .Extension.Version.

If that doesn't work for you, consider adding @3.2.123 instead or @3 to revert back to the version before this change, instead if relying on latest v3.

Version 3.5 uses the same syntax as V4 does now.

Version 3.5 removed the need to set anything and always registers an output variable:

steps:
- task: QueryAzureDevOpsExtensionVersion@3
  displayName: 'Query Extension Version: jessehouwing.jessehouwing-vsts-variable-tasks'
  name: Query
  inputs:
    connectedServiceName: Marketplace
    publisherId: jessehouwing
    extensionId: 'jessehouwing-vsts-variable-tasks'
    versionAction: Patch

You can then reference the variable using Query.Extension.Version in the same job or with: dependencies.JobA.outputs['Query.Extension.Version'] across jobs.

from azure-devops-extension-tasks.

Sorry for breaking you folks.

from azure-devops-extension-tasks.

I know that this issue is closed, but I'm curious why the change was also made to the v3 of the task? Was that breaking change done intentionally? If not could a new version of the task be released that reverts the breaking change to v3?

I'm sure there's a good reason for the change in general, but I'd expect that breaking changes to inputs only happen in major version releases and that users could evaluate changes without needing to implement emergency workarounds.

from azure-devops-extension-tasks.

@smkell it happened because of a versioning thing that turned out to be a mistake.

I upped the version to @4 prior to the release of the Node16 handler updates to accommodate this breaking change. But that meant the query version would have had version @5 for Node16, where all other tasks would have had @4. So I backported the latest versions of each task into the extension for backwards compatibility. I had forgotten about the breaking change, breaking you, and I would now break the people who made the fix.

The whole outputVariable parameter has been marked deprecated for a long time and there is an easy workaround by specifying an exact version number or implementing the 'correct' way to reference the variable.

On top it that, everyone needs to move to the new @4 anyway due to the Node16 handler updates.

So I had to make a call and so far only 3 people have had an issue with it. I'm really sorry I broke you, but it feels it was the right call.

from azure-devops-extension-tasks.

@smkell managed to find the reason for the bug I was fighting to support both the new and the old handling and found a workaround. Pushing a new version of the task that should unbreak @3.

Thanks for keeping me honest, but please do upgrade to @4 ;).

from azure-devops-extension-tasks.