refactor: Exclude the ACTS unittests from detray workflows

[niermann999]

Exclude changes in the Detray directory from triggering ACTS builds and instead adding a dedicated plugin build to the detray workflow

--- END COMMIT MESSAGE ---

[niermann999]

The dummy detray changes were added to trigger the traccc-plugin workflow and will be removed before merging. I think, the exclusion cannot be tested here, since the PR itself makes changes to the build.yml?

[github-actions]

📊: Physics performance monitoring for 00d856d

Full contents

physmon summary

• ✅ Particles fatras
• ✅ Particles geant4
• ✅ Particles ttbar
• ✅ Vertices ttbar
• ✅ Truth tracking (KF)
• ✅ Truth tracking (GSF)
• ✅ Truth tracking (GX2F)
• ✅ Truth tracking (KF refit)
• ✅ Truth tracking (GSF refit)
• ✅ CKF finding performance | trackfinding | single muon | truth smeared seeding
• ✅ CKF fitting performance | trackfinding | single muon | truth smeared seeding
• ✅ CKF track summary | trackfinding | single muon | truth smeared seeding
• ✅ Seeding trackfinding | single muon | truth estimated seeding
• ✅ CKF finding performance | trackfinding | single muon | truth estimated seeding
• ✅ CKF fitting performance | trackfinding | single muon | truth estimated seeding
• ✅ CKF track summary | trackfinding | single muon | truth estimated seeding
• ✅ Seeding trackfinding | single muon | default seeding
• ✅ CKF finding performance | trackfinding | single muon | default seeding
• ✅ CKF fitting performance | trackfinding | single muon | default seeding
• ✅ CKF track summary | trackfinding | single muon | default seeding
• ✅ Seeding trackfinding | single muon | orthogonal seeding
• ✅ CKF finding performance | trackfinding | single muon | orthogonal seeding
• ✅ CKF fitting performance | trackfinding | single muon | orthogonal seeding
• ✅ CKF track summary | trackfinding | single muon | orthogonal seeding
• ✅ Seeding trackfinding | 4 muon x 50 vertices | default seeding
• ✅ CKF finding performance | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ CKF fitting performance | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ CKF track summary | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ Ambisolver finding performance | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ IVF notime | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ AMVF gauss notime | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ AMVF grid time | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ Seeding trackfinding | ttbar with 200 pileup | default seeding
• ✅ CKF finding performance | trackfinding | ttbar with 200 pileup | default seeding
• ✅ CKF fitting performance | trackfinding | ttbar with 200 pileup | default seeding
• ✅ CKF track summary | trackfinding | ttbar with 200 pileup | default seeding
• ✅ Ambisolver finding performance | trackfinding | ttbar with 200 pileup | default seeding
• ✅ ML Ambisolver | trackfinding | ttbar with 200 pileup | default seeding
• ✅ AMVF gauss notime | trackfinding | ttbar with 200 pileup | default seeding
• ✅ AMVF grid time | trackfinding | ttbar with 200 pileup | default seeding
• 🔵️ Comparison - Truth tracking (GX2F vs KF)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[niermann999]

Ideally, the traccc plugin workflow should be trimmed down further, is there a way to only run the examples tests?

[andiwand]

preset + 15 custom args

con this be trimmed down?

[niermann999]

I hope so. I am not entirely sure what we actually need to set up the geometry conversion and the examples?

[andiwand]

not sure if this was discussed already but that setup would mask changes in our usual build so tests and especially physmon cannot be harmonized. I thought we wanted to synchronize this even though I am not sure how this would work with GPU hardware requirements.

[niermann999]

My goal was to extract that code in ACTS that can be affected by changes in detray or traccc into a separate workflow (as far as I know that is right now only the conversion/plugin/example code?) so that it can be triggered by changes in those repositories, without triggering the entire ACTS tests suite (which we know will succeed, but clogs the job queue for quite a while until the (host-)GPU tests get picked up).

Ideally, this would also get triggered by ACTS, but as things are at the moment that would mean just running the same test twice for ACTS, because I did not want to touch the ACTS builds just yet. I am not entirely sure how to best extract these tests from the current ACTS workflow so that it would no longer be a duplicate?

Happy to discuss this

[stephenswat]

Performance summary

Here is a summary of the performance effects of this PR:

Tabular

Benchmark	826c9dd		00d856d		Delta
	Throughput	CV	Throughput	CV
ODD (1 GeV, cov. on)	2.38 MHz	0.06%	2.38 MHz	0.06%	+0.00%
ODD (1 GeV, cov. off)	5.29 MHz	0.11%	5.29 MHz	0.12%	-0.02%
ODD (10 GeV, cov. on)	3.15 MHz	0.04%	3.15 MHz	0.05%	-0.01%
ODD (10 GeV, cov. off)	6.60 MHz	0.05%	6.60 MHz	0.05%	+0.01%
ODD (100 GeV, cov. on)	3.36 MHz	0.06%	3.36 MHz	0.03%	-0.02%
ODD (100 GeV, cov. off)	6.92 MHz	0.03%	6.92 MHz	0.04%	-0.02%
ODD ([1, 100) GeV, cov. on)	2.71 MHz	0.03%	2.71 MHz	0.03%	-0.00%
ODD ([1, 100) GeV, cov. off)	6.06 MHz	0.04%	6.06 MHz	0.02%	-0.06%
Toy detector ([1, 100) GeV, cov. on)	12.02 MHz	0.07%	12.03 MHz	0.13%	+0.04%
Toy detector ([1, 100) GeV, cov. off)	18.50 MHz	0.03%	18.50 MHz	0.03%	-0.02%
Wire chamber ([1, 100) GeV, cov. on)	14.89 MHz	0.01%	14.89 MHz	0.01%	-0.01%
Wire chamber ([1, 100) GeV, cov. off)	30.28 MHz	0.01%	30.29 MHz	0.02%	+0.04%

Note

This is an automated message produced upon the explicit request of a human being.