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.

Sign up for GitHub

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

Jump to bottom

Should we AOT the XunitLogChecker tool? #94270

Closed
ericstj opened this issue Nov 1, 2023 · 3 comments
Closed

Should we AOT the XunitLogChecker tool? #94270

ericstj opened this issue Nov 1, 2023 · 3 comments
Assignees
@agocke
Labels
area-Infrastructure-coreclr
Milestone
10.0.0

Comments

@ericstj
Copy link
Member

ericstj commented Nov 1, 2023

The XunitLogChecker targets the tool runtime today (an LKG runtime).

We don't deploy this runtime during libraries testing, nor do we really want to take a dependency on deploying that runtime to the test machines. We'll instead let the tool roll-forward and run on the test runtime.

This will work - except for the case that there is such a bad bug that the tool crashes too.

One thing @agocke suggested was that try native-AOT for the tool to make it work without a runtime dependency. This would potentially make the tool less subject to runtime breaks.
@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Nov 1, 2023
@ghost ghost added the untriaged New issue has not been triaged by the area owner label Nov 1, 2023
@ericstj ericstj added area-Infrastructure-coreclr and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Nov 1, 2023
@ghost
Copy link

ghost commented Nov 1, 2023

Tagging subscribers to this area: @hoyosjs
See info in area-owners.md if you want to be subscribed.

Issue Details

The XunitLogChecker targets the tool runtime today (an LKG runtime).

We don't deploy this runtime during libraries testing, nor do we really want to take a dependency on deploying that runtime to the test machines. We'll instead let the tool roll-forward and run on the test runtime.

This will work - except for the case that there is such a bad bug that the tool crashes too.

One thing @agocke suggested was that try native-AOT for the tool to make it work without a runtime dependency. This would potentially make the tool less subject to runtime breaks.

Author: ericstj
Assignees: -
Labels:

area-Infrastructure-coreclr, untriaged
Milestone: -

@MichalStrehovsky MichalStrehovsky mentioned this issue Nov 16, 2023
Merged
@carlossanlop
Copy link
Member

Closely related to #94722

@carlossanlop carlossanlop mentioned this issue Jan 17, 2024
Open
@JulieLeeMSFT JulieLeeMSFT added this to the 9.0.0 milestone Jan 17, 2024
@ghost ghost removed the untriaged New issue has not been triaged by the area owner label Jan 17, 2024
@agocke agocke modified the milestones: 9.0.0, 10.0.0 Aug 22, 2024
@agocke
Copy link
Member

agocke commented Sep 11, 2024

Fixed by #103795

@agocke agocke closed this as completed Sep 11, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Oct 12, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@agocke agocke

Labels
area-Infrastructure-coreclr
Projects
Runtime Infra
Archived in project
Milestone
10.0.0
Development

No branches or pull requests
4 participants
@agocke @carlossanlop @ericstj @JulieLeeMSFT