-
Notifications
You must be signed in to change notification settings - Fork 352
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
Add support to allow Helix WorkItem DownloadFilesFromResults behavior to ignore 404 #8200
Comments
@BruceForstall FYI. |
A little more context, if it helps: Our runtime-coreclr superpmi-asmdiffs AzDO pipeline needs to upload some generated files from Helix to the AzDO artifacts for users to then download. Some of these files are only generated in some scenarios, not all the time. The set of files to download is found here using |
One thought on the proposed implementation. Although ignoring non-existent files would be opt-in, the ambiguity with real 404s worries me. Another solution might be creating list(s) of the files (a.k.a. manifests) in scope of the task as they get created, upload them to results and then use them to determine which files to download. Helix SDK could be then extended by something like manifest_%(HelixWorkItem.Platform)_%(HelixWorkItem.Architecture).txt to get the exact list of files. |
Is there a recommend for next steps? |
As this is a warning, we should add warning codes to our warnings. With codes added customers can add |
Is this something you'd like to pursue w/ a PR yourself @BruceForstall ? The work makes sense to do, but we're not going to be able to do it for the foreseeable future given the other business priorities. |
We've worked around this issue (in dotnet/runtime#62368) by simply always creating all files, even if the files are actually empty, so I'm not going to address this in Helix (which is a complex and foreign (to me) dev experience). |
Thanks for leeting us know @BruceForstall, I'm closing this issue then. |
As originally added in #2103, the DownloadFilesFromResults Metadata Item causes error logging in the 404 (file not found) case. The specific custom usage done by the SuperPMI pipeline ends up getting error messages when files they want to copy to Azure DevOps artifacts are not present.
This will, unfortunately, not likely be able to differentiate which files are OK to 404 and instead be for the whole work item, but this can be addressed later via msbuild or other means.
The text was updated successfully, but these errors were encountered: