Deduplicate project files with the same name in different folders #64841
Conversation
|
Tagging subscribers to this area: @hoyosjs Issue DetailsThis is a somewhat annoying aspect hitting less than 10% of the Thanks Tomas /cc @dotnet/jit-contrib
|
|
/azp run runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
This seems kind of annoying, though I suppose minor in the scheme of things.
Once again, I worry about when we go to create a new test later, we can't just create a test "context free" -- it has to obey a set of rules about naming that are global to the repo, which is unfortunate, but hopefully very easy to check. E.g., we normally create a new test by copy/paste/edit from an existing test. Now, we won't know if that name is ok until outerloop tests are run (presumably just building/running Pri-0 won't be sufficient to ensure naming rules are followed, if a new Pri-0 conflicts with a Pri-1 test, for example).
Also:
we cannot merge multiple test projects
that produce a test assembly with the same name otherwise such
assemblies stomp over each other when getting copied to the merged
wrapper folder
Hopefully the copy logic will check that there is no stomping, so there will be a noisy failure, not just a silent stomping?
|
@jkoritzinsky - regarding Bruce's (reasonable) concerns, would it be possible to somehow detect the silent overlap of two test reference assemblies with the same simple name in the merged wrapper generator and produce and actionable error message? This PR demonstrates a plethora of cases where this is happening but we have no safeguards today, the tests in question just silently disappear and I agree with Bruce that is wrong. |
|
I'm not sure how much control we have over that, as the name clashes are silently handled by the |
|
Thanks Jeremy for your feedback; I would however expect that these should boil down to differing project references as the project paths are different, it's just that the output assemblies happen to have the same filename and so they cause an overlap when copying them to the merged wrapper output folder. I'll take a more detailed look at the binlog tomorrow to see what exactly happens in the scripts and how to implement the safeguards I proposed. |
|
/azp run runtime-coreclr outerloop |
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
To cleanly resolve this issue and address Bruce's concerns, Jeremy is working on adjusting build of IL projects by replacing hardcoded |
|
In addition to generating the |
trylek
force-pushed
the
JIT-Methodical-auto-project-dedup-2
branch
from
aef62a1
to
d5788b5
Compare
|
/azp run runtime-extra-platforms |
|
/azp run runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
I've opened a PR with the validation target at #66951. That PR should catch any cases of missed coverage. I don't think auto-generating the |
This is a somewhat annoying aspect hitting less than 10% of the JIT/Methodical subtree: as the new merged wrapper logic is based on simple assembly names, we cannot merge multiple test projects that produce a test assembly with the same name otherwise such assemblies stomp over each other when getting copied to the merged wrapper folder. I have added a new option to ILTransform to include the directory name in the project names in these cases. We can remove some of this in the future when selectively merging actual test source code (compiling multiple tests into a single asssembly). Thanks Tomas
trylek
force-pushed
the
JIT-Methodical-auto-project-dedup-2
branch
from
d5788b5
to
3e644e1
Compare
|
/azp run runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
…tnet#64841) This is a somewhat annoying aspect hitting less than 10% of the JIT/Methodical subtree: as the new merged wrapper logic is based on simple assembly names, we cannot merge multiple test projects that produce a test assembly with the same name otherwise such assemblies stomp over each other when getting copied to the merged wrapper folder. I have added a new option to ILTransform to include the directory name in the project names in these cases. We can remove some of this in the future when selectively merging actual test source code (compiling multiple tests into a single asssembly). Thanks Tomas
ghost
locked as resolved and limited conversation to collaborators
This is a somewhat annoying aspect hitting less than 10% of the
JIT/Methodical subtree: as the new merged wrapper logic is based
on simple assembly names, we cannot merge multiple test projects
that produce a test assembly with the same name otherwise such
assemblies stomp over each other when getting copied to the merged
wrapper folder. I have added a new option to ILTransform to include
the directory name in the project names in these cases. We can
remove some of this in the future when selectively merging actual
test source code (compiling multiple tests into a single asssembly).
Thanks
Tomas
/cc @dotnet/jit-contrib