final step for removal of ConditionsService

[rlcee]

The ConditionsService is obsolete and several previous PR's removed the references to it. This PR should be the last step of removing the service itself. There are still two references to ConditionsService as part of a path, and those should remain for now. There should also be no more references to ConditionsHandle. The ConditionsEntity header must remain for use by GlobalConstantsService. There are still references to ConditionsService in other repos, but they have all be declared "won't fix" or "fix as needed later" by repo experts.

[FNALbuild]

Hi @rlcee,
You have proposed changes to files in these packages:

• Mu2eInterfaces
• /
• ConditionsService

which require these tests: build.

@Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main.

⌛ The following tests have been triggered for b6db422: build (Build queue - API unavailable)

About FNALbuild. Code review on Mu2e/Offline.

[FNALbuild]

☀️ The build tests passed at b6db422.

Test	Result	Details
test with	✅	Command did not list any other PRs to include
merge	✅	Merged b6db422 at 5b02c13
build (prof)	✅	Log file. Build time: 08 min 33 sec
ceSimReco	✅	Log file.
g4test_03MT	✅	Log file.
transportOnly	✅	Log file.
POT	✅	Log file.
g4study	✅	Log file.
cosmicSimReco	✅	Log file.
cosmicOffSpill	✅	Log file.
ceSteps	✅	Log file.
ceDigi	✅	Log file.
muDauSteps	✅	Log file.
ceMix	✅	Log file.
rootOverlaps	✅	Log file.
g4surfaceCheck	✅	Log file.
trigger	❓	Log file. Return Code 1.
check_cmake	✅	Log file.
FIXME, TODO	✅	TODO (0) FIXME (0) in 5 files
clang-tidy	✅	0 errors 0 warnings
whitespace check	✅	no whitespace errors found

N.B. These results were obtained from a build of this Pull Request at b6db422 after being merged into the base branch at 5b02c13.

For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.

[oksuzian]

I'll review this pull request by examining its details and changes.Now let me check whether there are any remaining references to ConditionsService or ConditionsHandle in the codebase that this PR might miss:Now let me check whether there are any remaining references to ConditionsService or ConditionsHandle in the codebase outside of the ConditionsService/ directory that might not be just path references:Here's my review of PR #1773:

Summary

This PR removes the obsolete ConditionsService by deleting 7 files in the ConditionsService/ directory and updating 2 remaining files. It's a net deletion of 356 lines with only 3 lines added. The CI build has passed (all tests green except the trigger test which returned code 1 with a ❓ status).

Issues Found

1. 🔴 ConditionsEntity.hh — Incomplete include guard update

In Mu2eInterfaces/inc/ConditionsEntity.hh, the header guard is being renamed from ConditionsService_ConditionsEntity_hh to Mu2eInterfaces_ConditionsEntity_hh, which is correct since the file lives in Mu2eInterfaces/. However, the file already exists on main at that path with the old guard name. Any downstream code that references the old guard macro name in a conditional check (e.g., #ifdef ConditionsService_ConditionsEntity_hh) could break silently. This is a minor concern but worth noting.

2. 🟡 ConditionsService/ directory not fully removed

The PR deletes all files inside ConditionsService/ (CMakeLists.txt, data, inc, src), but the ConditionsService/ directory itself will remain as an empty directory in the repository after merge. Git does not track empty directories, so this should be fine in practice — the directory will disappear. However, if there are any .gitkeep or other untracked files, verify the directory is truly empty.

3. 🟡 Remaining path-based references to ConditionsService in the codebase

The PR description acknowledges this, but for completeness — the following files still reference ConditionsService as part of a data file path (not an #include or library dependency):

• CaloReco/fcl/common.fcl — "OfflineData/ConditionsService/CsI-waveform-2020-02-12.root"
• CaloMC/fcl/prolog.fcl — "OfflineData/ConditionsService/CsI-propag-2020-07-29.root"

These are paths to external data files (in the OfflineData package), not to the service code, so they are correctly left unchanged. However, this creates a potentially confusing situation where ConditionsService appears as a directory name in data paths after the service is removed. A follow-up to rename these data paths would improve clarity.

4. 🟡 Trigger test returned non-zero exit code

The CI build comment shows the trigger test returned code 1 (❓ status). While the PR author and CI system seem to treat this as a known/non-blocking issue, it's worth confirming this is a pre-existing flaky test and not a regression from this removal. If the trigger configuration references ConditionsService anywhere, this could be the cause.

5. ✅ No remaining #include references to deleted headers

I searched the codebase and confirmed there are no remaining #include directives for ConditionsService/inc/ConditionsService.hh or ConditionsService/inc/ConditionsHandle.hh outside of the deleted files themselves. The removal appears clean from a C++ dependency standpoint.

6. ✅ No remaining CMake/build dependency on Offline::ConditionsService

No other CMakeLists.txt files reference Offline::ConditionsService as a library dependency outside the deleted directory.

Verdict

This is a clean removal PR with no obvious showstoppers. The main actionable item is to investigate the trigger test failure (issue #4) to confirm it's unrelated. The include guard rename in ConditionsEntity.hh is correct and the deletion is thorough. The remaining ConditionsService string references are data file paths and are appropriately left for later cleanup as noted in the PR description.

[FNALbuild]

📝 The HEAD of main has changed to b4e91ff. Tests are now out of date.

[rlcee]

I think copilot comments don't need an follow-ups