Breaking changes

[bnm27]

In the future when you push out a breaking change, could you please try to do so by incrementing the task version and/or making the code backwards compatible?

The change to require the area to be specified was silently failing to add tags to our work items. After tracing it back we noticed that our pipeline task suddenly had configuration warnings that the root area was required. It was easy enough to fix but required us to go back through every pull request to figure out when it stopped working and manually tagging each work item.

If you had put your changes into a new task version instead, then the existing task version could have continued to work (assuming the code was also backwards compatible).

I understand that sometimes breaking changes are needed, but at the very least I would prefer that our builds started failing with an error indicating the need to update the Task definition instead of tags suddenly not working and hoping someone catches it before too much times goes by.

Thanks

[bnm27]

To add on to this, now nothing is getting tagged. Looks like in the tag comparison you are now checking if the Area Path of the work item exactly matches the root area path variable, which isn't how area paths work. Items are almost always nested under the root area path.

        const currentWorkItemArea = result.fields['System.AreaPath'];
        const rootArea = tl.getInput('rootArea');
        if (currentWorkItemArea === rootArea) {
            console.log(`Updating tags on #${workItem.id} with ${rootArea} area`);
            await updateWorkItemTags(result);
        }

[aesergeev-tech]

@bnm27 Hello! I've just published an update with option whether use or not area filtering. If area filtering doesn't enabled so tagging will be applied to all work items associated with build or release.

[aesergeev-tech]

@bnm27 please let me know if everything fine now

[aesergeev-tech]

@bnm27 closing to inactivity