Azure-pipelines-tasks: PR #13450 - Breaking change for match patterns in Extract File Task

[aaronentwistle]

Question, Bug, or Feature?
Type: Bug

Enter Task Name: Extract Files Task

Environment:

Azure Pipelines (hosted services):

• isagenix
• 'One Team'
• IsaNet_QA6(Release pipeline)
• Release-3363,3364,3365

Private agent(self hosted):

• Windows 2012r2
• Agent.Version 2.168.2

Issue Description

Appears a change was made with PR #13450 on 'Extract Files' task that changed the matching of files.
Prior to task update(working):

After task update(non working):

Task logs

I don't have any debug logs as we've been updating our many pipelines to fix this, but can recreate issue if logs are required.

Troubleshooting

Checkout how to troubleshoot failures and collect debug logs: https://docs.microsoft.com/en-us/vsts/build-release/actions/troubleshooting
Changed the file matching pattern from *.zip to include a directory, ie: $(System.DefaultWorkingDirectory)\mybuild\drop*.zip

Error logs

I don't have any errors as the task doesn't fail if there are no zip files.

[kauemendes]

Awesome! I was about to open an issue as well. This has impact several builds and releases on company Azure DevOps. My suggestion is that returning a nested folder should be in some way an option, without the need to pass the entire folder. Once it´s located where it should be.

Another suggestion is... Changes like this should be fully notified in some way. It can impact the whole process inside a company with hundreds of pipelines that are using this task.

Thanks !

[acrov]

This change broke many of our release pipelines too.

While I realise the existing behaviour (recursive search) was probably not the intended behaviour it had been like that for over 12 months. Some notice that this was a breaking change (and some way of subscribing to notifications) would have been nice.

Or better still, some impact analysis before deciding to make the change.

[anatolybolshakov]

Hi @aaronentwistle @kauemendes @acrov @AndrewGretton sorry for breaking change here - there was an undocumented behavior. We are going to update documentation as well to make it more precise regarding this case, and consider impact for such cases.

The current working way to set all files in root folder and subfolder - '*/*.zip' instead of '*.zip'

[aaronentwistle]

Hi @aaronentwistle @kauemendes @acrov @AndrewGretton sorry for breaking change here - there was an undocumented behavior. We are going to update documentation as well to make it more precise regarding this case, and consider impact for such cases.

The current working way to set all files in root folder and subfolder - '**/_.zip' instead of '_.zip'

I guess that makes sense - I remember looking at it and saying "That works? Weird. Ok I guess"

Also to clarify do you mean */.zip?

[annaisalwaysawesome]

Our pipeline broke as well. We had only '*.zip' in the File patterns.

[anatolybolshakov]

@annaisalwaysawesome @aaronentwistle yes, thanks, correct - '*/.zip' should work, I fixed my comment above.
Please let us know if you have any issues with it

[JBorras-summar]

HI!
Changing '*/.zip' instead of '.zip' works fine in all my pipelines!!
Thank you!

[annaisalwaysawesome]

Hi, just an fyi that this was a pretty huge breaking change across many of our pipelines, causing them to fail suddenly without anyone having any idea why. All the known issues have been fixed, mostly by the developers just being specific to the file they needed, but the impact was pretty significant.

[SinZ163]

Just had to deal with this today, some heads up or moving this to a major version update would have been appreciated.

[tsigereda]

This broke our pipeline too and that created a bit of a disruption in our day until i figured out that it was this that halted our releases. Nice if these changes were in major versions.

[abartelsmeier]

same issue for us too... *.zip used to search recursively, now doesn't. I can see why this change wasn't in a major version change, it was never meant to search recursively! A wider question, not sure if anyone knows the answer, but why don't ADO releases lock the specific versions of all tasks used when the release is created? Seems a bit worrying that past releases can be broken in this way...

[anatolybolshakov]

Hi everyone, we fixed issue with incorrect default '*.zip' value also for archiveFilePatterns input in PR and going to roll out briefly soon.
As a workaround - you can set archiveFilePatterns as '**/*.zip' if it wasn't specified, or replace '.zip' by '*/*.zip'
Sorry for inconvenience here - we are going to deliver such changes with major version change next time and cover it up by impact analysis

[steven-hyland]

Thanks for pinning this issue - we ran into it at my org too.

I too was confused at first why the bare *.zip worked, but just went with it. We had some broken pipelines too, but the reasoning about undocumented/unintended behavior makes sense. Thanks for the explanation of the problem and suggested fix.

[anatolybolshakov]

Hi everyone! Fix for default value of archiveFilePatterns input has been already rolled out - now it is '*/.zip' instead of '*.zip'

[guillaume-kizilian]

So just to clarify, there are breaking changes without using the Azure DevOps Tasks Versioning, that break tested and trusted releases ? And that's normal ?
I'm sure i can find an analogy between Azure DevOps and Vietnam...

[anatolybolshakov]

Hi everyone, I'm going to close it at the moment since we rolled out a fix for issue with wrong default value - please feel free to ask any other questions regarding it

[awts7807]

hi @anatolybolshakov I saw this has been close but I notice just today that deployment still fails using the task.
luckily using the workaround below from one of comments earlier works though. Does that mean you will not bring back the old behavior anymore?
**/*.zip

[anatolybolshakov]

Hi @awts7807 yes, */.zip is valid pattern here and should work

[fowl2]

Hi everyone, I'm going to close it at the moment since we rolled out a fix for issue with wrong default value - please feel free to ask any other questions regarding it

Unless I'm misunderstanding, changing the default value doesn't fix all the pipelines that were broken by this change?

It's really _Not Cool_ to make breaking changes like this with no version bump or warning. Regardless of any documentation *.zip worked on zip files in sub directories up until this PR.

In my case this was a particularly nasty as it was a silent breakage - there was no error or warning just a Found: 0 files to extract: hidden in the logs. But the deployments weren't.. deploying. 😢

Please consider restoring the permissive behavior and making this fix in only in a new version of the task. The UI doesn't appear to allow selecting minor versions so this would likely have to be a "major" version.

Yes, we can laboriously review/fix all our pipelines for impact, but that leaves all existing releases in a non-working state.

Thanks!

[BobBuildingCode]

Yes, same here. We have ~100 release jobs that we now need to rewrite, since fixing the default value doesn't help with all the already created tasks. Luckily for us we don't release that often, but I can imagine this being a nightmare for people with tons of release jobs they use more often.

_But on the bright side this pushed us into switching from classic releases to YAML Pipelines instead 😅_