Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[enhancement]: DownloadFileshareArtifactsV1 - should not fallback on FileShare (or it should be an option) #20666

Open
dcrespo-isaac opened this issue Nov 15, 2024 · 0 comments

Comments

@dcrespo-isaac
Copy link

Task name

DownloadFileshareArtifactsV1

Describe your feature request here

Hi Team,


Context

I have a classic build pipeline that creates an artifact and publishes it to a file share each time it succeeds.
To deploy this artifact, I created a nightly scheduled release pipeline based on it, the configuration of the artifact :

Default version : "Latest from specific branch with tags"
Branch : Master | V6.00 | V5.12 ....
Tags :

The pipeline failed the first night because the artifact was not found on the file share. The cleaning task ran over it and delete the minor version. That's expected sometimes. What I did not expect is the behavior that the pipeline had: it tried to download the whole file share, and let the system drive of the machine's agent with no space. The DownloadFileshareArtifactsV1 task downloads the whole fileshare instead of failing when not found.

Potential issues

  • Saturated disk space or 0 space left on disk

    • On the system drive (which is the default installation if you run the deployment group script), in the best case scenario, the pipeline fails. You can access the machine to wipe everything, but it's a little slow, and other processes on the machine start to fail due to low space. In the worst case scenario, the machine crashes and shuts down, then you cannot restart it properly.
    • On other drives, it impacts other processes, but you can still access and clean.
  • Wasteful use of resources

    • Let's say there is enough space on the machine, and the entire fileshare is copied. The artifact still won't be found, and the directory structure may not be as expected since it contains the whole fileshare, leading to a pipeline failure.
    • There is a counter-argument here: you can prepare for such a scenario where the fileshare is successfully copied. Yes, but that seems like an odd way to handle the pipeline, possibly indicating a poor design choice.

Workarounds

  • Make sure that the cleaning of the file share and the retention of the build pipeline are in sync.
  • If using one of the "latest from *****" options when creating release pipeline, always be sure that the latest artifact for the specific branch is always kept on the fileshare.

Enhancement

The task should simply try to download the artifact. If not found, then fail the pipeline and let the team do their troubleshooting. Provide an option to fallback to the fileshare or another group of tasks in the release pipeline.

Since it's been like this for 6 years, people may be used to it. I understand if this enhancement is taken in reverse and the option becomes "Fail pipeline if artifact not found in fileshare." That would be obvious, but the whole point of this request is to make visible a default behavior that is not that predictable.

When adding an artifact to the release pipeline, the form should contain a checkbox for this option. The same should apply to other views that might use this task.


Thank you for the time taken with this issue
Have a great day.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant