Azure-pipelines-tasks: DownloadPipelineArtifact permissions lost on ubuntu

[Justin-DynamicD]

Type: Bug
Enter Task Name: DownloadPipelineArtifact

Issue Description

When using PublishPipelineArtifact with DownloadPipelineArtifact on ubuntu-latest (assuming other distros as well), the artifacts published then downloaded will not maintain execution rights.

An example of this would be using the -outfile option in Terraform, which will bundle downloaded plugins into the generated artifact. If the plugin files do not have execution permissions set once extracted to the target deployment agent, the subsequent Terraform steps will fail due to permission issues.

As a quick workaround I run a bash script after the DownloadPipelineArtifact step to chmod +x the plug-ins, but it would be preferable to maintain the file permissions using the task itself.

[t3mi]

The other case - release shell scripts with proper defined execute permission in git which go to artifact as simple files. And during release that permission is lost and bash task prints at least a warning about that. That's definitely a bug.

[herenhuang]

Just to give an update here from the Artifacts team. It does seem like a bug, so we'll track this like one and update here when possible.

[Lectem]

Same issue here, and I have a lot of executables bundled in the artifact.
Using chmod +x on all of them is not very practical.

It does seem like a bug

I think this should probably be documented in the meantime.

[Justin-DynamicD]

@herenhuang thank you for the update. I looks like it was changed from a bug to an enhancement in Jan, so if it is agreed to be a bug, we may need to flip that back.

[ElvenSpellmaker]

Just ran into this issue too, it's very surprising to not keep permissions, running a chmod is a bit of a hack tbh.

[tusharb86]

@herenhuang Hi there - I'm trying to understand why this is considered an enhancement instead of a bug? Is it required that consumers of artifacts keep a list of executable files and mark them as executable (chmod +x) after the artifact is downloaded? This certainly feels like a bug in the implementation of artifacts. Many teams are having to put in their own hack/workaround to deal with this issue. Is there any plan to work on improving this in the near future?

[Lectem]

Note that github actions followed the same path and has the same issue.
to mitigate this they document (only on the upload task, not download, which is not that easy to find) that one can simply tar.gzip the directory before (but then you have to do filtering of files yourself).

I think an Ok(ish) solution would be to have the task use tar.gz for storage instead of Zip based on a parameter of the task
At least it would be easily discovered and fixable.