Use dotnet publish instead of ArchiveTests target

[ViktorHofer]

At the moment we don't publish (framework dependent) our test projects and instead just build them and then zip them up. To make different publish modes possible (ie self-contained for code coverage), we want to use dotnet publish instead and use its output as the test payload.

I don't know if dotnet publish supports creating a zip file but if not, we could do that in sendtohelix.proj.

Relevant code path:

runtime/eng/testing/tests.targets

Lines 27 to 38 in 132be64

	<!-- Archive test binaries. -->
	<Target Name="ArchiveTests"
	Condition="'$(ArchiveTests)' == 'true' and '$(IgnoreForCI)' != 'true'"
	AfterTargets="PrepareForRun"
	DependsOnTargets="GenerateRunScript">
	<Error Condition="'$(TestArchiveTestsDir)' == ''" Text="TestArchiveTestsDir property to archive the test folder must be set." />
	<MakeDir Directories="$(TestArchiveTestsDir)" />
	<ZipDirectory SourceDirectory="$(OutDir)"
	DestinationFile="$([MSBuild]::NormalizePath('$(TestArchiveTestsDir)', '$(TestProjectName).zip'))"
	Overwrite="true" />
	</Target>

In addition to that we could experiment with publishing (and incrementally restoring and building) the test projects inside sendtohelix.proj so that the output paths are known and get rid of the well known publish location.

cc @safern @Anipik

[ghost]

Tagging subscribers to this area: @safern, @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[safern]

We could also do dotnet publish and then zip it up ( similar to what we do for mobile targets) doing the zip in sendtohelix.proj doesn’t seem like the best place but that could work as well.

[ViktorHofer]

The only reason we compress the publish directory, is to send it to helix, right? That's why I played with the idea of doing that in sendtohelix.proj. It sequencing it into the publish target would mean that we would either always compress it (which we shouldn't) or again need a flag to express that (which ideally we wouldn't need).

That said, this sounds like an implementation detail, I'm fine with any solution as long as we use the publish directory instead of the bin directory.

[safern]

The only reason we compress the publish directory, is to send it to helix, right? That's why I played with the idea of doing that in sendtohelix.proj.

Yeah, but sentohelix.proj is already getting complicated enough (after addition to run coreclr stress tests) and I would like those to be decoupled, I think it is better to have that as part of the test vertical. The flag won't go away as we will still need this for wasm, so I don't mind having to pass in an extra flag.

Also, for sending manual helix jobs is helpful as well since I can just do dotnet build /p:ArchiveTests=true in an individual project and then use that for other purposes.

Compressing the testhost directory happens in sendtohelix.proj since that is just executed once and not for every project we have, so that's why I think it makes sense to make it a target that test projects have available and also consistency with wasm and other platforms.

[ViktorHofer]

Also, for sending manual helix jobs is helpful as well since I can just do dotnet build /p:ArchiveTests=true in an individual project and then use that for other purposes.

Sure, if we want to continue using the extra property then you would do dotnet publish /p:ArchiveTests=true locally.

As said, this is an implementation detail, I'm fine with any solution that makes sense.

[safern]

Sounds good. Just wanted to highlight my opinion there since the issue description mentioned removing the per-test target to generate the archives.

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.