Helix arcade reporter creates URLs for HTML attachments of any .log file found, but doesn't upload them

• Is this issue blocking: no, users can work around by getting relevant .log files copied into the HELIX_WORKITEM_UPLOAD_ROOT path.
• Is this issue causing unreasonable pain : debatable, but it’s a bug.

@alexperovich FYI.

Summary:

As mentioned in this PR, the ASP.NET team expects .log files to all be specially uploaded, but unless files outside the regular console and harness log (and various XML-based test results) are put into the appropriate path, they don’t get uploaded.

Further, it’s entirely possible that users have .log files inside their Helix work item folder that are large and undesired for propagation, so forcibly trying to upload these doesn’t make sense to me.

Relevant code snippets:

This line: https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.Helix/Sdk/tools/azure-pipelines/reporter/test_results_reader/__init__.py#L81 Chooses HELIX_WORKITEM_ROOT as the folder to do a recursive walk on, and this line: https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.Helix/Sdk/tools/azure-pipelines/reporter/test_results_reader/__init__.py#L44 Constructs a bunch of URLs without uploading them (upload IS automatic when contained in the upload root path)

Since the listdir() call isn’t recursive, this doesn’t even traverse HELIX_WORKITEM_UPLOAD_ROOT and thus the files don’t get included unless they’re in two places currently.

Thoughts on fix:

I’ll defer to @alexperovich here but my thought is to only upload .log files from HELIX_WORKITEM_UPLOAD_ROOT and if this variable is undefined to either upload them itself or to print out “not uploading .log file because…” (this is only important for certain ancient, non-updated Helix clients).

[alexperovich]

PRs into arcade will use whatever changes you have made. There isn’t a real way to test locally, but you can make a PR and use the build to see what it does.

[chcosta]

Per discussion with @HaoK , this is low priority for their team.

Given the feedback, from @ChadNedzlek , that fixing this the right way would not be a minor investment; closing this issue and we can re-evaluate if the impact grows or this becomes problematic.