Fix DotNetCoreCLI@2 zipAfterPublish to preserve ZIP file location #21045
Conversation
Co-authored-by: sanjuyadav24 <185911972+sanjuyadav24@users.noreply.github.com>
Copilot
AI
changed the title
Tasks/DotNetCoreCLIV2/dotnetcore.ts
Outdated
| fs.mkdirSync(outputSource); | ||
| fs.renameSync(outputTarget, path.join(outputSource, path.basename(outputTarget))); | ||
| } | ||
| // When moveZipToOutputSource is true and zipAfterPublish is true, |
There was a problem hiding this comment.
@copilot this might be expected behavior for some customers, can we make this feature flag based to control the use case
There was a problem hiding this comment.
You're absolutely right. I've implemented this as a feature flag to preserve backwards compatibility. Added a new zipAfterPublishCreateDirectory parameter (defaults to true for legacy behavior) that controls whether the ZIP file is moved into a subdirectory or left at the original location. This way customers can choose the behavior that works best for their use case. Commit: aab9dd2
Co-authored-by: sanjuyadav24 <185911972+sanjuyadav24@users.noreply.github.com>
|
Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details. Warning Firewall rules blocked me from connecting to one or more addressesI tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
Tasks/DotNetCoreCLIV2/dotnetcore.ts
Outdated
| if (moveZipToOutputSource) { | ||
|
|
||
| // Check if we should create directory for ZIP output (legacy behavior) | ||
| if (moveZipToOutputSource && this.zipAfterPublishCreateDirectory) { |
There was a problem hiding this comment.
@copilot this change is asking customer to provide this input, make it a feature flag based check tl.getPipelineFeature
There was a problem hiding this comment.
I've implemented the change to use a pipeline feature flag instead of customer input. The zipAfterPublishCreateDirectory parameter has been removed and replaced with tl.getPipelineFeature('DotNetCoreCLIZipAfterPublishSimplified'). When the feature flag is enabled, it uses the simplified behavior (no directory creation), and when disabled it uses the legacy behavior. This maintains backward compatibility while allowing service-level control. Commit: 9d3ea7d
…y behavior Co-authored-by: sanjuyadav24 <185911972+sanjuyadav24@users.noreply.github.com>
Issue
When using the
DotNetCoreCLI@2task withzipAfterPublishset totrue, the task was removing the produced ZIP file from its original location and placing it inside a newly created directory with the same name as the output path. This resulted in a confusing directory structure where the artifact was an empty folder containing a ZIP file, rather than just the ZIP file itself.Solution
The fix removes the unnecessary directory creation and file moving logic in the
zipAfterPublishIfRequiredmethod:Now when
zipAfterPublishis true, the ZIP file remains at the original location where it was created, resulting in a simpler and more intuitive output.Testing
Created a new test case to ensure the zipAfterPublish functionality works as expected.
Fixes #20974.
Warning
Firewall rules blocked me from connecting to one or more addresses
I tried to connect to the following addresses, but was blocked by firewall rules:
cdn.fwupd.org/usr/bin/fwupdmgr refresh(dns block)pkgs.dev.azure.comnpm install(dns block)npm install @types/node @types/mocha @types/q @types/ltx @types/uuid @types/semver(dns block)If you need me to access, download, or install something from one of these locations, you can either:
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.