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

Add support to allow Helix WorkItem DownloadFilesFromResults behavior to ignore 404 #8200

Closed
2 tasks
MattGal opened this issue Nov 19, 2021 · 9 comments
Closed
2 tasks

Comments

@MattGal
Copy link
Member

MattGal commented Nov 19, 2021

  • This issue is blocking
  • This issue is causing unreasonable pain

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.

@MattGal
Copy link
Member Author

MattGal commented Nov 19, 2021

@BruceForstall FYI.

@BruceForstall
Copy link
Member

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 DownloadFilesFromResults. One of the files listed in that <HelixWorkItem> is Asmdiffs_%(HelixWorkItem.Platform)_%(HelixWorkItem.Architecture).zip, and is only sometimes generated. Currently, we see error messages if it can't be found, which appears to cause the work item to fail the AzDO job. Example log for that is here.

@BruceForstall
Copy link
Member

cc @kunalspathak

@tkapin
Copy link
Member

tkapin commented Dec 9, 2021

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.

@markwilkie
Copy link
Member

Is there a recommend for next steps?

@alexperovich
Copy link
Member

alexperovich commented Jan 13, 2022

As this is a warning, we should add warning codes to our warnings. With codes added customers can add /NoWarn:<code> in the msbuild cmd line to ignore this specific warning if they wish.

@markwilkie
Copy link
Member

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.

@BruceForstall
Copy link
Member

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).

@tkapin
Copy link
Member

tkapin commented Jan 17, 2022

Thanks for leeting us know @BruceForstall, I'm closing this issue then.

@tkapin tkapin closed this as completed Jan 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants