Keep response files used for crossgenning the framework

[trylek]

Response files are a very useful artifact for reproing various
Crossgen / Crossgen2 compilation errors. I propose modifying the
test build scripts to retain these artifacts by using the --nocleanup
option and by skipping deletion of the entire output folder upon
the end of framework compilation. The Crossgen output folder is not
listed among the artifacts transferred to Helix so it should be a
non-concern w.r.t. Helix throughput. I have also put the cmd and sh
versions of the script in sync by adding "large-bubble" and "release"
flags to the Unix version.

Thanks

Tomas

/cc: @dotnet/crossgen-contrib

[janvorli]

I think the --nocleanup should be added here too, right?

[trylek]

Sure, thanks for reminding me!

[davidwrighton]

@trylek, everything in the crossgen.out directory is copied to the helix machines. See

https://helixde107v0xdeko0k025g8.blob.core.windows.net/helix-job-586ecf1a-97c7-4261-870e-9ed23c371721ea7b316d6c9426089/8c8bd01b-aa7b-424b-ac64-94799dda1546.zip

We probably should just avoid using the core_root directory for holding temporary state, and instead put the crossgen.out directory somewhere else.

[trylek]

Thanks David for the heads-up. I'm going to investigate why that's happening as I believe that our current scripts should filter the folder out according to the following clauses:

runtime/src/tests/Common/Directory.Build.targets

Line 57 in 789845f

<RunTimeArtifactsIncludeFolders Include="/" />

[trylek]

OK, I see the problem, this scripts kicks in earlier, it just defines how to populate CORE_ROOT, not how to filter its contents when zipping it up for Helix. In such case I'll modify it as David suggested, by moving the intermediate crossgen outputs somewhere under artifacts\obj.

[davidwrighton]

The change looks good, but I'm concerned by the fact that all the tests seem to be failing. Also, the Linux logs don't print out which assemblies were crossgened. You may want to make the outputs consistent between Unix and Windows.

[trylek]

I concur, I keep trying to figure out what the problem is; it's just somewhat tricky because so far none of my attempts at reproing the issue have been successful, and that includes manually reconstructing the Helix workitem environment based on the payloads and running it locally. I'll fix the logging as you suggest and I'll continue looking but I must admit that right now I'm quite desperate what else should I try.

[nattress]

I see in the helix log

+ dotnet /root/helix/work/correlation/xunit.console.dll JIT/CodeGenBringUpTests/JIT.CodeGenBringUpTests.XUnitWrapper.dll -parallel collections -nocolor -noshadow -xml testResults.xml -trait TestGroup=JIT.CodeGenBringUpTests
Fatal error. Verify_TypeLayout 'System.Object' failed to verify type layout
   at Xunit.ConsoleClient.Program.Main(System.String[])

It looks like we started running CG2 on the Xunit assemblies in Core_Root recently. That's a bit weird to do because we're likely Crossgening them against the framework under test in Core_root. On Helix we run Xunit against the shared framework, which is some other version of the framework libraries. I don't really get how System.Object changed enough to fail Verify_TypeLayout since it's a simple class but maybe we should try excluding Xunit libraries from our framework CG2 script.