ci: Spack #3980
ci: Spack #3980
Conversation
## Walkthrough
A new GitHub Actions workflow for dependency management introduced, it has been. CI configurations now utilize custom actions instead of old shell scripts, and new scripts for OpenGL, parallel execution, Spack setup, and lockfile selection appear. Updates made to caching strategies, environment variables, and type comparisons in GitLab CI, CMake files, and core libraries. Updated hash values and comments in tests and visualization, they are. Many files changed, yes.
## Changes
| File(s) | Change Summary |
|-----------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `.github/actions/dependencies/action.yml`<br>`.github/workflows/analysis.yml`<br>`.github/workflows/builds.yml` | New GitHub Actions workflow "Dependencies" added; jobs updated to use the custom dependency action with inputs (`compiler`, `GITHUB_TOKEN`, etc.); dependency tag updated from `v5` to `v7_b7`; caching keys and build configuration parameters adjusted. |
| `.gitlab-ci.yml` | Environment variable `DEPENDENCY_TAG` updated to `v7_b7`; new variables `SPACK_VERSION` and `LOCKFILE_CACHE_DIR` added; caching sections and dependency sourcing commands modified in multiple jobs. |
| `CI/dependencies.sh` <br> `CI/dependencies/opengl.sh`<br>`CI/dependencies/parallel.sh`<br>`CI/dependencies/select_lockfile.py`<br>`CI/dependencies/setup.sh`<br>`CI/dependencies/setup_spack.sh` | Old dependency script removed; new scripts introduced for OS-specific OpenGL installation, parallel process management, lockfile selection with caching, Spack environment setup, and Spack installation cloning from GitHub. |
| `Core/include/Acts/EventData/VectorMultiTrajectory.hpp`<br>`Core/include/Acts/Utilities/EigenConcepts.hpp`<br>`Core/include/Acts/Visualization/Interpolation3D.hpp` | Type conversion in conditions modified: using `toUnderlying` instead of `static_cast`; FPE masking comments added in spline function (and extra comments in trajectory allocation). |
| `Examples/Python/tests/root_file_hashes.txt`<br>`cmake/setup_withdeps.sh.in`<br>`Examples/Algorithms/Geant4HepMC/src/EventRecording.cpp` | Hash values updated in test files; shell environment checks improved and dependency activation logic refined; additional comments inserted around BeamOn call and event abortion in the recording file. |
## Sequence Diagram(s)
```mermaid
sequenceDiagram
participant R as Runner
participant D as Dependencies Action
participant C as Cache Manager
participant S as Spack Setup
R->>D: Trigger workflow
D->>R: Check OS (macOS? etc.)
D->>C: Attempt to restore Spack cache
alt Cache Hit
C-->>D: Return cached Spack installation
else Cache Miss
D->>S: Run setup_spack.sh/setup.sh
S-->>D: Spack installed and configured
D->>C: Cache the Spack installation
end
D->>D: Install dependencies (using provided compiler if set)
D->>R: Complete workflow, hmmm.Possibly related PRs
Suggested labels
Poem
|
github-actions
bot
added
the
Infrastructure
paulgessinger
force-pushed
the
spack-ci
branch
from
c313d4d to
b1ca7e4
Compare
github-actions
bot
added
Component - Core
paulgessinger
force-pushed
the
spack-ci
branch
from
7d011eb to
463e14f
Compare
github-actions
bot
added
Component - Examples
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (8)
CI/dependencies/setup.sh (6)
73-95: Setting defaults, well done it is.
Defaults are established with care. Still, quoting variable expansions when possible, you might consider, to prevent word splitting.
102-108: Quote thy variables, you must!
When creating the destination directory withmkdir -p ${destination}, enclose the variable in quotes to guard against spaces, you should.
117-121: Handle symlink creation, you should.
In the GitLab CI branch, before linking${CI_PROJECT_DIR}/.spackto${HOME}/.spack, check if the symlink exists already, you might. Prevent surprises, it will.
125-139: Buildcache mirror setup, acceptable it is.
Adding the buildcache mirror is clever. Yet, validating the mirror URL before use, consider you must, for extra safety, yes.
177-182: Spack package installation, executed with precision it is.
Using a fixed number of CPUs (4) is acceptable, though dynamically detecting core count, you might consider for further refinement, hmmm.
184-190: Symlink creation for Geant4, handled it is.
The Geant4 data directory is prepared and linked. Before blindly creating the symlink, verifying no conflict exists, a wise improvement it would be..gitlab-ci.yml (1)
7-10: New CI variables defined, they are.
IntroducingSPACK_VERSION,LOCKFILE_CACHE_DIR, and updatingDEPENDENCY_TAGtov7_b7is a bold move. Consistency with other configurations, verify you must..github/workflows/builds.yml (1)
55-64: Configure command, effective it is.
The commandccache -z && cmake -B build -S . …successfully works around dd4hep issues; however, review the quoting in these commands to prevent word splitting, you might.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.github/workflows/builds.yml(11 hunks).gitlab-ci.yml(18 hunks)CI/dependencies/setup.sh(1 hunks)cmake/setup_withdeps.sh.in(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- cmake/setup_withdeps.sh.in
🧰 Additional context used
🧠 Learnings (1)
.gitlab-ci.yml (1)
Learnt from: paulgessinger
PR: acts-project/acts#3980
File: .gitlab-ci.yml:67-67
Timestamp: 2025-03-19T14:13:55.416Z
Learning: When reviewing file paths in CI scripts, consider the working directory context set by previous commands like `cd`. In the Acts project's CI, many scripts are executed from within the `src` directory after cloning the repository.
🪛 actionlint (1.7.4)
.github/workflows/builds.yml
141-141: shellcheck reported issue in this script: SC2086:info:6:5: Double quote to prevent globbing and word splitting
(shellcheck)
141-141: shellcheck reported issue in this script: SC2086:info:6:35: Double quote to prevent globbing and word splitting
(shellcheck)
185-185: shellcheck reported issue in this script: SC2086:info:7:6: Double quote to prevent globbing and word splitting
(shellcheck)
185-185: shellcheck reported issue in this script: SC2155:warning:11:8: Declare and assign separately to avoid masking return values
(shellcheck)
185-185: shellcheck reported issue in this script: SC2086:info:11:23: Double quote to prevent globbing and word splitting
(shellcheck)
185-185: shellcheck reported issue in this script: SC2086:info:13:6: Double quote to prevent globbing and word splitting
(shellcheck)
⏰ Context from checks skipped due to timeout of 90000ms (16)
- GitHub Check: CI Bridge / lcg_106a: [alma9, gcc13]
- GitHub Check: CI Bridge / lcg_105: [alma9, clang16]
- GitHub Check: CI Bridge / lcg_105: [alma9, gcc13]
- GitHub Check: CI Bridge / linux_ubuntu_2404_clang19
- GitHub Check: CI Bridge / linux_ubuntu_2204
- GitHub Check: CI Bridge / build_linux_ubuntu
- GitHub Check: CI Bridge / build_exatrkx
- GitHub Check: CI Bridge / build_exatrkx_cpu
- GitHub Check: CI Bridge / clang_tidy
- GitHub Check: CI Bridge / build_gnn_tensorrt
- GitHub Check: macos
- GitHub Check: linux_ubuntu
- GitHub Check: linux_ubuntu_extra (ubuntu2404_clang19, 20, clang++-19)
- GitHub Check: linux_ubuntu_extra (ubuntu2204, 20, g++)
- GitHub Check: missing_includes
- GitHub Check: build_debug
🔇 Additional comments (25)
CI/dependencies/setup.sh (9)
41-71: Command-line parsing, performed well it is.
The getopts loop robust appears; maintain vigilant error handling you must, yes.
110-116: Spack installation, proper it is.
The logic to install and source Spack if missing, clear and effective it is, hmmm.
141-144: Locate OpenGL, executed it is.
The call to${SCRIPT_DIR}/opengl.shis simple and effective. Trust in its result, I do.
146-166: Spack lock file retrieval, implemented soundly it is.
The command array forselect_lockfile.pyis structured clear and proper it is.
171-175: Spack environment creation, strong it is.
The creation of the Spack environment runs as expected. Clarity and succinctness, there is.
193-202: Python environment preparation, completed it is.
The steps to set up and install the Python virtual environment are clear and concise.
204-214: Environment variable setup, done with diligence it is.
Usingset_envto establish paths and variables shows order. Proper quoting and clarity, maintained they are.
219-222: Restoring original shell options, performed it is.
Evaluating the old state witheval "$oldstate"restores the initial setup. Ensure side effects, you must check.
1-8:❓ Verification inconclusive
Strong start, this is!
Wise you are to capture the shell option state witholdstate, hmmm. Yet, consider addingset -o pipefail(or useset -euo pipefail) for improved error detection, you must.
Enhance your error handling, you must!
InCI/dependencies/setup.sh, a strong start your code has, yes. Yet, missing the power ofpipefailit is. Improve error detection in pipelines, you will, by using it. I suggest you refactor as follows:
- In place of:
set -e set -u- Consider using:
set -euo pipefailThis change ensures that errors in any element of a pipe are caught, reinforcing your script's robustness. Verify the integration and further impacts with care, you must.
.gitlab-ci.yml (8)
27-36: Cache paths, defined they are correctly.
Caching thespackand.spackdirectories is wise indeed. Uniqueness in cache keys, maintained it appears.
37-41: Cleanup steps, clearly defined they are.
The after_script block for spack cache cleanup is thoughtful and ensures tidiness, yes.
44-44: Updated container image for clang-tidy, strong it is.
Switching to imageghcr.io/acts-project/ubuntu2404:71improves the environment.
67-67: Dependency setup command, correctly invoked it is.
Usingsource CI/dependencies/setup.sh -c clang++aligns with new conventions, yes.
117-117: Dependency script call, proper it is.
The invocationsource CI/dependencies/setup.sh -c g++in the build_exatrkx_cpu job is consistent and clear, hmmm.
190-190: Consistent dependency setup in test job, it is.
In the test_exatrkx_unittests job, the sourcing ofCI/dependencies/setup.sh -c g++is well done.
338-338: Dependency sourcing for examples test, correct it is.
The use ofsource CI/dependencies/setup.sh -c g++confirms consistency across jobs, it does.
412-412: Dependency setup in extra job, consistent it is.
Usingsource CI/dependencies/setup.sh -c ${CXX}in linux_ubuntu_extra correctly leverages the matrix variable..github/workflows/builds.yml (8)
39-44: Dependency installation, modern it is.
Employing the custom GitHub Action from./.github/actions/dependenciesfor installing dependencies simplifies the workflow, it does.
45-53: Ccache restoration, solid it appears.
The cache restore step with an improved key format is structured well. Rejoice in caching consistency, you should.
265-270: Custom action in matrix job, proper it is.
Passing${{ matrix.cxx }}as the compiler to the dependency action is consistent and enhances maintainability, yes.
271-279: Cache key for extra job, well refined it is.
Including matrix variables like${{ matrix.image }},${{ matrix.std }}, and${{ matrix.cxx }}in the key ensures uniqueness; a clever technique it is.
281-289: Configuration in extra job, tailored it is.
Using matrix values forCMAKE_CXX_COMPILERandCMAKE_CXX_STANDARDshows finesse; correctness, it ensures.
312-320: Downstream configure, updated it is.
Passing${{ matrix.cxx }}for the compiler in the downstream configure step keeps variables aligned—consistency, you have achieved.
340-345: MacOS dependency action, proper it appears.
Explicitly settingcompiler: clang++within the macOS job’s dependency action is a wise and clear choice, hmmm.
400-404: Downstream run in macOS, executed properly it is.
Prepending the dependency bin directory to PATH and running the downstream binary works well; ensure environment correctness, you must.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (7)
CI/dependencies/setup.sh (5)
97-97: Quoting variables, important it is.
When callingmkdir -p ${destination}, consider quoting the variable—as inmkdir -p "${destination}"—to avoid word splitting when spaces occur.
112-116: Symlink for .spack, cautious one must be.
For the GitLab CI branch, soft-linking the Spack configuration directory is good; however, checking if the symlink already exists before creating it may prevent errors.
120-139: Mirror configuration, consider validation you should.
The buildcache mirror is set up properly, yet it might be wise to validate themirror_urlbefore using it. Recall that trusting URLs blindly, the dark side it leads to!
179-185: Geant4 data symlink, cautious you must be.
Creating the data directory and linking it is essential; however, check if the symlink exists already before callingln -s. For example:- ln -s "${geant4_dir}/share/Geant4/data" "${view_dir}/share/Geant4/data" + if [ -e "${view_dir}/share/Geant4/data" ]; then + rm -f "${view_dir}/share/Geant4/data" + fi + ln -s "${geant4_dir}/share/Geant4/data" "${view_dir}/share/Geant4/data"This will prevent errors if the link is already present.
188-196: Python virtual environment, proceed you must.
The creation of the virtual environment and installation of packages is clear. Note that the use ofls -almay be left for debugging; consider removing it in production for a cleaner log..github/workflows/builds.yml (2)
55-63: Build configuration, efficient it stands.
The use ofccache -zand a preset CMake configuration keeps the build process neat. Good it is, though ensure paths are properly quoted to avoid word splitting.
186-203: Physics performance checks, cautious you must be.
Within the block starting at line 186, commands such asvenv_python=$(which python3)and subsequent echo commands should quote variable expansions to prevent issues. For example:- venv_python=$(which python3) - echo $venv_python - export PATH=$(dirname $venv_python):$PATH - echo $PATH + venv_python=$(which python3) + echo "$venv_python" + export PATH="$(dirname "$venv_python"):$PATH" + echo "$PATH"This will ensure robustness, it will.
🧰 Tools
🪛 actionlint (1.7.4)
188-188: shellcheck reported issue in this script: SC2086:info:7:6: Double quote to prevent globbing and word splitting
(shellcheck)
188-188: shellcheck reported issue in this script: SC2155:warning:11:8: Declare and assign separately to avoid masking return values
(shellcheck)
188-188: shellcheck reported issue in this script: SC2086:info:11:23: Double quote to prevent globbing and word splitting
(shellcheck)
188-188: shellcheck reported issue in this script: SC2086:info:13:6: Double quote to prevent globbing and word splitting
(shellcheck)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/workflows/builds.yml(11 hunks)CI/dependencies/setup.sh(1 hunks)cmake/setup_withdeps.sh.in(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- cmake/setup_withdeps.sh.in
🧰 Additional context used
🪛 actionlint (1.7.4)
.github/workflows/builds.yml
141-141: shellcheck reported issue in this script: SC2086:info:9:5: Double quote to prevent globbing and word splitting
(shellcheck)
141-141: shellcheck reported issue in this script: SC2086:info:9:35: Double quote to prevent globbing and word splitting
(shellcheck)
188-188: shellcheck reported issue in this script: SC2086:info:7:6: Double quote to prevent globbing and word splitting
(shellcheck)
188-188: shellcheck reported issue in this script: SC2155:warning:11:8: Declare and assign separately to avoid masking return values
(shellcheck)
188-188: shellcheck reported issue in this script: SC2086:info:11:23: Double quote to prevent globbing and word splitting
(shellcheck)
188-188: shellcheck reported issue in this script: SC2086:info:13:6: Double quote to prevent globbing and word splitting
(shellcheck)
⏰ Context from checks skipped due to timeout of 90000ms (8)
- GitHub Check: merge-sentinel
- GitHub Check: CI Bridge / build_gnn_tensorrt
- GitHub Check: linux_ubuntu_extra (ubuntu2204, 20, g++)
- GitHub Check: linux_ubuntu_extra (ubuntu2404_clang19, 20, clang++-19)
- GitHub Check: macos
- GitHub Check: linux_ubuntu
- GitHub Check: missing_includes
- GitHub Check: build_debug
🔇 Additional comments (15)
CI/dependencies/setup.sh (10)
4-7: Directory resolution, most clever it is!
The use of a subshell withcdandpwdto determineSCRIPT_DIRis spot on. The export ofSPACK_COLORis also clear.
8-19: Function set_env defined well, it is.
Your implementation to print and export environment variables based on whether running in GitHub Actions or not is clean. No changes required here, young Padawan.
21-34: Section control functions, you have mastered.
Thestart_sectionandend_sectionfunctions look elegant for grouping log output in CI. May the force of clarity be with you.
36-66: Command-line parsing, clear it remains.
Your use ofgetoptsfor processing options is standard and effective. Ensure that if more options are added later, proper quoting is maintained.
69-91: Defaults and error handling, strong they are.
The logic to check for unset variables and to enforce the presence of a dependency tag is sound, young one.
105-111: Spack installation, handled nicely it is.
The conditional check for thespackcommand and the subsequent installation are done in a straightforward manner.
141-160: Lock file selection, precise it appears.
Building the command array for selecting the Spack lock file is clear and maintains flexibility. Excellent work, you have.
166-170: Spack environment creation, executed with confidence.
The steps to create, inspect, and list the Spack environment are well ordered.
172-177: Parallel package installation, a fine touch, it is.
Using your customparallel.shscript to install packages is an efficient solution to avoid deadlocks.
199-209: Environment variables set with care, they are.
The use of theset_envfunction to configure paths and other variables is consistent and sound. Well done, you have..github/workflows/builds.yml (5)
23-24: Dependency tag updated, this is.
SettingDEPENDENCY_TAGtov7_b7is in line with the new dependency scheme. Consistency now, you bring.
39-44: Dependencies installation using custom action, wise decision it is.
Using the new.github/actions/dependenciesaction with thecompilerandGITHUB_TOKENinputs simplifies maintenance. Ensure that the action is well tested in your CI pipeline, you must.
45-53: Cache restore configuration, well structured it seems.
The ccache restore steps appear correct, though keep an eye on key consistency across matrix jobs for reproducibility.
269-273: Matrix usage in extra job, correctly handled it is.
In thelinux_ubuntu_extrajob, using${{ matrix.cxx }}for the compiler in both the dependency installation step and cache key now matches the matrix definition. Harmony in the force, you have achieved.
343-348: macOS dependencies, clear and concise they remain.
The macOS job uses the new custom dependency action withcompiler: clang++correctly. May your builds be swift and error-free!
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
.github/actions/dependencies/action.yml (2)
34-40: Cache extraction, well executed it is!
The cached Spack installation is extracted clearly. For better clarity, consider using “$HOME” instead of “~”, you might.
41-53: Spack setup from scratch, thorough it appears!
The sequence of running the setup script, listing spack packages, and caching the installation is methodical. Yet, adding error checking after critical commands could strengthen the order in the Force..github/workflows/builds.yml (2)
141-151: Python test block, robust it is!
The setup and execution of Python-level tests flow well. Consider if all “set +o” commands are needed—simplify, you might, for clarity.
188-204: Physics performance checks, verbose they are!
The group of commands for environment setup and performance monitoring is detailed. Quoting variables such as using"$(which python3)"to avoid word splitting is recommended, you must.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
.github/actions/dependencies/action.yml(1 hunks).github/workflows/analysis.yml(3 hunks).github/workflows/builds.yml(11 hunks).gitlab-ci.yml(18 hunks)cmake/setup_withdeps.sh.in(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- cmake/setup_withdeps.sh.in
- .github/workflows/analysis.yml
🧰 Additional context used
🧠 Learnings (1)
.gitlab-ci.yml (1)
Learnt from: paulgessinger
PR: acts-project/acts#3980
File: .gitlab-ci.yml:67-67
Timestamp: 2025-03-26T14:24:15.432Z
Learning: When reviewing file paths in CI scripts, consider the working directory context set by previous commands like `cd`. In the Acts project's CI, many scripts are executed from within the `src` directory after cloning the repository.
⏰ Context from checks skipped due to timeout of 90000ms (11)
- GitHub Check: CI Bridge / lcg_106a: [alma9, gcc13]
- GitHub Check: CI Bridge / build_gnn_tensorrt
- GitHub Check: CI Bridge / lcg_105: [alma9, clang16]
- GitHub Check: CI Bridge / lcg_105: [alma9, gcc13]
- GitHub Check: CI Bridge / linux_ubuntu_2404_clang19
- GitHub Check: CI Bridge / linux_ubuntu_2204
- GitHub Check: CI Bridge / build_linux_ubuntu
- GitHub Check: CI Bridge / build_exatrkx
- GitHub Check: CI Bridge / build_exatrkx_cpu
- GitHub Check: CI Bridge / clang_tidy
- GitHub Check: missing_includes
🔇 Additional comments (51)
.github/actions/dependencies/action.yml (6)
1-2: Well-defined metadata, it is!
The action’s name and description clearly reveal its purpose—to install dependencies from the lockfile. Clear and succinct they are.
4-17: Solid input configuration, young padawan!
The inputs (compiler, GITHUB_TOKEN, spack_version) are defined with proper defaults. This configuration sets a steady foundation for the action.
21-26: Consider error handling in prerequisites, you should!
The macOS step installs “ninja ccache” via brew. Adding error checking with an “|| { … }” clause might save you from unforeseen failures in the Force.- brew install ninja ccache + brew install ninja ccache || { echo "Brew installation failed!"; exit 1; }
27-33: Cache restoration key, robust it is!
Using spack_version and the hash of the setup script for the key is clever and steady.
54-61: Cache saving, implemented it is!
The “Save cache” step correctly captures the installation state using the cache key. Stable, this approach remains.
62-73: Conditional dependency installation, clear it is!
The logic to check if a compiler is provided—and then invoke the setup script accordingly—is both simple and effective..gitlab-ci.yml (26)
7-10: New CI variables, noted they are!
Introducing SPACK_VERSION, LOCKFILE_CACHE_DIR, and updating DEPENDENCY_TAG to v7_b7 strengthens the dependency management in our CI.
21-36: Spack cache configuration, well crafted it is!
The cache keys using file references and environment variables ensure trusty caching. Verify that the file path “CI/dependencies/setup_spack.sh” still rules in your realm.
37-41: Cleanup actions, clear they are!
The spack_cleanup after_script neatly removes extraneous files and purges pyc residues. Pristine, the environment shall remain.
44-52: Updated container image, it is!
Upgrading the clang_tidy job’s image to version 74 meets our modern standards. Steady, this move is.
53-55: Cache integration, solid it is!
Referencing the pre-defined .spack_cache for this job provides consistency across our build.
67-67: Invoke dependency setup, it does!
Sourcing the dependency setup script with “-c clang++” is proper; ensure the relative path is correct in this CI environment, you must.
96-98: Consistent cleanup, it is!
Using the spack_cleanup reference in the after_script keeps the realm tidy after the clang_tidy run.
117-117: Spack setup invoked in build_exatrkx_cpu, it is!
The call to the setup script with “-c g++” appears consistent. Always double-check the environment context, you should.
130-132: After build cleanup, essential it is!
Reusing the spack_cleanup reference post-build ensures that any remnants vanish into the Void.
159-159: Build environment setup, consistent it remains!
Invoking the dependency script in build_exatrkx with “-c g++” keeps the pattern. Confirm the working directory is as expected, you must.
171-173: Test job cleanup, proper it is!
The spack_cleanup reference post-build in test_exatrkx supports continuous order in the repository.
190-190: Unit test setup, active it is!
Sourcing the dependency setup in test_exatrkx_unittests calls for careful attention—ensure its execution context is correct, you must.
194-196: Test cleanup, wise it is!
The recurring use of spack_cleanup after unit tests keeps the environment as pure as the Force.
214-214: Python test environment, set it is!
The dependency setup for the Python pipeline using “-c g++” is consistently applied. Trust, in this method, we do.
224-226: Post-test cleanup, maintained it is!
The echo of spack_cleanup in the Python tests reaffirms our commitment to a clean state.
242-242: TensorRT build environment, correctly set it is!
Sourcing the dependency setup with “-c g++” in the TensorRT build job aligns with our other calls. Yet verify the script path remains true, you must.
256-258: Cleanup after TensorRT build, effective it is!
Reusing spack_cleanup in the after_script here continues the pattern of cleanliness across our jobs.
287-288: Script sourcing, correct path usage verified it is!
Using “source src/CI/dependencies/setup.sh -c g++” after cloning and checking out appears valid in light of the directory change.
320-321: Post-build cleanup, it remains clear!
The spack_cleanup call here ensures that any lingering files vanish into the nether.
338-338: Test environment setup, consistent it is!
Sourcing the dependency setup in the linux_test_examples job with “-c g++” keeps the routine intact.
345-345: Targeted pytest invocation, precise it is!
Running pytest for the specific “test_full_chain_odd_example_pythia_geant4” case keeps focus in the training, it does.
347-349: Test cleanup after examples, clear it remains!
Employing spack_cleanup consistently after tests preserves our environment’s purity.
372-372: Physmon setup, proper it is!
Sourcing the dependency setup in the linux_physmon job remains consistent—ensure the context is set rightly.
388-390: Physmon cleanup, effective it is!
The spack_cleanup reference here reinforces a tidy conclusion to the performance checks.
412-412: Extra job dependency setup, harmonious it is!
Invoking “source CI/dependencies/setup.sh -c ${CXX}” in the linux_ubuntu_extra job integrates matrix parameters smoothly.
448-450: Final cleanup, effective it remains!
The continued use of spack_cleanup in the afterwards step of the extra job preserves order in the build, as the Force demands..github/workflows/builds.yml (19)
23-23: Dependency tag update, approved it is!
Setting DEPENDENCY_TAG to v7_b7 harmonizes our configuration with the latest CI updates.
39-44: Dependency installation via custom action, strong it is!
Invoking the custom action to install dependencies with the proper compiler and token streamlines the build. A wise choice, this is.
268-273: Matrix-based dependency installation, clear it is!
Using the custom action with the compiler parameter from the matrix (matrix.cxx) ensures each build is honed precisely.
275-282: Enhanced cache key, it is!
Including matrix values (image, std, cxx) in the ccache key improves cache specificity. Strong, this configuration stands.
284-292: Configuration command, precise it is!
Resetting the cache and setting the compiler and standard from matrix values refines the build configuration. Harmony achieved, it is.
315-323: Downstream configure, well scripted it is!
Updating to use matrix values for C++ compiler and standard ensures consistency downstream. Trust in this change, you surely can.
343-348: MacOS dependency installation, correct it is!
The custom action for installing dependencies under macOS with compiler “clang++” fits splendidly with platform needs.
349-357: MacOS cache restore, stable it is!
The cache restore step on macOS follows the same disciplined pattern as on Linux, ensuring a balanced environment.
358-364: MacOS configuration, succinct it is!
Resetting the cache and setting the install prefix properly during configuration keeps the flow pure.
392-399: MacOS downstream configuration, proper it is!
The downstream configuration for macOS is consistent and clear, maintaining build integrity across platforms.
400-407: Downstream run, engaging it is!
Prepending the dependency directory to PATH is wise. Verify that DEPENDENCY_DIR is truly defined in the environment, you must.
268-273:
275-282:
315-323:
343-348:
349-357:
358-364:
392-399:
400-407:
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
CI/dependencies/setup.sh (1)
174-179: Installation of spack packages, executed in parallel it is.
Usingparallel.shwith its output piped throughteeand filtered viagrepis an effective way to monitor installation progress, though additional error checks could be beneficial..gitlab-ci.yml (1)
426-426: Test execution in linux_ubuntu_extra, note you must.
Thectest --test-dir buildcommand is used without the parallel flag (-j$(nproc)), which may slow testing. Consider re-enabling parallel testing if stable it is.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/actions/dependencies/action.yml(1 hunks).gitlab-ci.yml(18 hunks)CI/dependencies/setup.sh(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
.gitlab-ci.yml (1)
Learnt from: paulgessinger
PR: acts-project/acts#3980
File: .gitlab-ci.yml:67-67
Timestamp: 2025-03-26T14:24:15.432Z
Learning: When reviewing file paths in CI scripts, consider the working directory context set by previous commands like `cd`. In the Acts project's CI, many scripts are executed from within the `src` directory after cloning the repository.
⏰ Context from checks skipped due to timeout of 90000ms (22)
- GitHub Check: CI Bridge / lcg_107: [alma9, clang19]
- GitHub Check: CI Bridge / lcg_107: [alma9, gcc14]
- GitHub Check: CI Bridge / lcg_107: [alma9, gcc13]
- GitHub Check: CI Bridge / lcg_106a: [alma9, clang16]
- GitHub Check: CI Bridge / lcg_106a: [alma9, gcc14]
- GitHub Check: CI Bridge / lcg_106a: [alma9, gcc13]
- GitHub Check: CI Bridge / lcg_105: [alma9, clang16]
- GitHub Check: CI Bridge / lcg_105: [alma9, gcc13]
- GitHub Check: CI Bridge / linux_ubuntu_2404_clang19
- GitHub Check: CI Bridge / linux_ubuntu_2204
- GitHub Check: CI Bridge / build_linux_ubuntu
- GitHub Check: CI Bridge / build_exatrkx
- GitHub Check: CI Bridge / build_exatrkx_cpu
- GitHub Check: missing_includes
- GitHub Check: CI Bridge / build_gnn_tensorrt
- GitHub Check: CI Bridge / clang_tidy
- GitHub Check: CI Bridge / clang_tidy
- GitHub Check: linux_ubuntu_extra (ubuntu2404_clang19, 20, clang++-19)
- GitHub Check: macos
- GitHub Check: linux_ubuntu
- GitHub Check: linux_ubuntu_extra (ubuntu2204, 20, g++)
- GitHub Check: build_debug
🔇 Additional comments (47)
.github/actions/dependencies/action.yml (8)
1-3: Name and description, clear they are.
The action is aptly named “Dependencies” and its purpose—to install dependencies from a lockfile—is conveyed clearly, yes.
4-17: Input parameters, well-defined they are.
The inputs for compiler, GITHUB_TOKEN, and spack_version are provided with meaningful descriptions and sensible defaults.
21-26: Brew installation command, vulnerable it may be.
Usingbrew install ninja ccachewithout error handling can be risky. Consider wrapping the command to catch failures, as previously suggested.
27-33: Cache restoration, robust it appears.
The step usingactions/cache/restore@v4with a key built from the spack version and hash of the setup script is smart, it is.
34-40: Extraction of cached Spack, check its destination you should.
Movingspack_cache/spackto the current directory andspack_cache/.spackto the home directory (using~) is interesting. Confirm that placing the.spackfolder in the home directory is intended, you must.
41-53: Spack setup from scratch, methodical it is.
Running the setup script, cleaning up the installation (e.g. removing the.gitfolder), and caching the installation are steps well orchestrated.
54-61: Cache saving, handled it is.
The use ofactions/cache/save@v4with a properly referenced key ensures that the Spack installation is cached for future runs—sound this approach is.
62-73: Conditional dependency installation, clever it is.
The conditional block that checks for an optional compiler input and then calls the appropriate setup script is consistent with the overall design.CI/dependencies/setup.sh (19)
1-5: Strict mode enabled, wise practice it is.
Setting-uand-eimmediately with saving the old state ensures a robust execution environment, hmmm.
6-9: Script directory, resolved robustly it is.
DeterminingSCRIPT_DIRusing a combination ofcdandpwdis effective and reliable in diverse environments.
10-21: Function set_env, clear and effective it is.
The function echoes the variable assignment and correctly handles cases of GitHub Actions by writing to$GITHUB_ENV.
23-30: Start_section function, grouping output it does.
The use of GitHub Actions group markers withinstart_sectionprovides neat log grouping.
32-36: End_section function, simple yet effective it is.
Ending output groups viaend_sectionis implemented cleanly, yes.
38-68: Command line parsing, robust your script is.
Parsing options withgetoptsfor compiler, tag, destination, and help is clear and user-friendly.
70-81: Defaults assigned with care, they are.
Defaulting the compiler from theCXXenvironment variable and ensuring a tag is provided makes the script resilient.
83-92: Destination handling, reflective of CI context it is.
Choosing the installation destination based on whether the script runs in GitHub Actions, GitLab CI, or a local environment is logically sound.
96-98: Informative echoes and directory creation, beneficial they are.
Echoing the install tag and destination, then creating the destination directory, ensures clarity for the user.
99-105: Dynamic spack folder, defined it is.
Setting_spack_folderbased on the CI environment (GitLab vs. others) is a clever adaptation to different contexts.
107-113: Spack installation check, prudent it is.
Verifying ifspackis installed and then installing it if missing shows foresight and care.
114-119: Spack configuration for GitLab CI, properly handled it is.
Creating a personal spack configuration directory and linking it into the home directory ensures caching and consistency in CI environments.
122-141: Buildcache mirror and OpenGL location, well orchestrated they are.
Adding the buildcache mirror conditionally and calling an OpenGL locator script demonstrate proper environmental setup.
143-156: Spack lock file retrieval, methodical it is.
Collecting the architecture usingspack arch --familyand generating a lock file with the Python helper ensures a predictable environment.
168-172: Spack environment creation, successful it is.
Creating the spack environment and listing its specifications confirms the environment’s integrity.
181-187: Geant4 setup, caution is advised.
The creation of the Geant4 share directory and symlinking the data directory is done without checking for preexisting links; consider adding safety checks as recommended earlier.
190-200: Python environment creation, functional it is.
Establishing a virtual environment and installing Python packages is solid. For reproducibility, pinning package versions might be considered.
201-211: Environment variables, set they are with clarity.
Appending paths to GitHub’s$GITHUB_PATHand exporting critical variables likePATH,ROOT_SETUP_SCRIPT, and others are handled clearly.
216-217: State restoration complete, harmony restored it is.
Reinstating the previous shell state witheval "$oldstate"is a neat touch to end the script gracefully..gitlab-ci.yml (20)
7-10: New CI variables, strategic they are.
DefiningSPACK_VERSION,LOCKFILE_CACHE_DIR, and updatingDEPENDENCY_TAG(to v7_b7) enhances dependency management effectively.
37-41: Cleanup steps, tidy they are.
The after_script commands in.spack_cleanupthat remove unnecessary files and pyc files are well considered and useful.
44-45: Clang-tidy job image updated, it is.
Updating the image to version 74 for clang-tidy ensures the latest tools are in use, and consistency within the CI environment remains.
67-67: Dependency setup in clang-tidy, correctly invoked it is.
The commandsource CI/dependencies/setup.sh -c clang++ensures that the clang-tidy job uses the new dependency management script.
96-98: After-script in clang-tidy, cleanup complete it is.
Referencing the cleanup template from.spack_cleanupconfirms that artifact cleanup after the job is handled consistently.
117-117: build_exatrkx_cpu job, dependency setup invoked it is.
Usingsource CI/dependencies/setup.sh -c g++in this job guarantees that dependencies are set up correctly, confirming consistency.
159-159: build_exatrkx job, dependency script called it is.
The call tosource CI/dependencies/setup.sh -c g++is appropriately placed, showing the update from the old method.
190-190: test_exatrkx_unittests job, dependency setup proper it is.
Invoking the new dependency script in the unittests job ensures that the tests run in a correctly configured environment.
214-214: test_exatrkx_python job, setup call confirmed it is.
source CI/dependencies/setup.sh -c g++is used to prepare the environment for Python tests, assuring consistency.
242-242: build_gnn_tensorrt job, dependency invocation sound it is.
Using the new dependency setup call in this job aligns it with the updated CI strategy.
338-338: linux_test_examples job, dependency setup invoked it is.
The call tosource CI/dependencies/setup.sh -c g++continues the consistent pattern across jobs, which is excellent.
345-345: Test command clarity, improved it is.
The specific use ofpytest -rFsv -k "test_full_chain_odd_example_pythia_geant4" -v -sensures focused testing. Verify that this scope meets testing needs, you should.
372-372: linux_physmon job, dependency setup proper it remains.
The usage ofsource CI/dependencies/setup.sh -c g++here ensures that the job runs with the up-to-date environment.
412-412: linux_ubuntu_extra job, dynamic compiler usage observed.
Invokingsource CI/dependencies/setup.sh -c ${CXX}makes the job flexible for different compiler settings—clever it is.
430-430: Installation logging, beneficial it is.
Redirecting the output ofcmake --install buildtoinstall.logprovides a useful record for debugging—wise this move is.
439-439: Compiler configuration, consistent it is.
Using-DCMAKE_CXX_COMPILER=${CXX}ensures that the build uses the intended compiler, matching the variable configuration.
449-449: After-script in extra job, cleanup consistent it remains.
Relying on the cleanup settings from.spack_cleanupkeeps the workspace tidy after the build.
454-455: linux_ubuntu_2204 job, compiler variables set they are.
WithCXX: g++andCXXSTD: 20, the job adheres to modern compilation standards—good this is.
463-463: linux_ubuntu_2404_clang19 job, image update approved it is.
The job now uses an image with clang++-19, version 74; consistency and upgrade it shows.
471-472: LCG jobs image updated, harmonious it is.
Using the updated base image${OS}-base:74across LCG jobs ensures that the latest dependencies and configurations are utilized.
| .spack_cache: | ||
| cache: | ||
| - key: | ||
| files: | ||
| - CI/dependencies/setup_spack.sh | ||
| prefix: spack_${SPACK_VERSION} | ||
| paths: | ||
| - spack | ||
| - .spack | ||
| - key: | ||
| files: | ||
| - spack_lockfile_cache/digest.txt | ||
| prefix: spack_lockfile_ | ||
| paths: | ||
| - spack_lockfile_cache | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Cache key reference, consistent it must be.
The .spack_cache block currently refers to CI/dependencies/setup_spack.sh while jobs call CI/dependencies/setup.sh. Align the cache key file reference to match the new dependency script, you should.
This reverts commit 33ad090.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.github/workflows/analysis.yml (1)
109-116: Inconsistency in Python Executable Setting, Hmmm...
Notice I do, that-DPython_EXECUTABLE=$(which python3)is explicitly set in the performance job, whereas it is omitted in the debug job. If intentional this is, then fine it is; however, for consistency across jobs, consider unifying the configuration, you may.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/workflows/analysis.yml(2 hunks).github/workflows/builds.yml(13 hunks)cmake/setup_withdeps.sh.in(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- cmake/setup_withdeps.sh.in
- .github/workflows/builds.yml
⏰ Context from checks skipped due to timeout of 90000ms (24)
- GitHub Check: CI Bridge / lcg_107: [alma9, clang19]
- GitHub Check: CI Bridge / lcg_107: [alma9, gcc14]
- GitHub Check: merge-sentinel
- GitHub Check: build_debug
- GitHub Check: CI Bridge / lcg_106a: [alma9, clang16]
- GitHub Check: CI Bridge / lcg_107: [alma9, gcc13]
- GitHub Check: CI Bridge / build_gnn_tensorrt
- GitHub Check: CI Bridge / lcg_106a: [alma9, gcc14]
- GitHub Check: CI Bridge / lcg_106a: [alma9, gcc13]
- GitHub Check: CI Bridge / lcg_105: [alma9, clang16]
- GitHub Check: CI Bridge / build_linux_ubuntu
- GitHub Check: CI Bridge / lcg_105: [alma9, gcc13]
- GitHub Check: CI Bridge / linux_ubuntu_2204
- GitHub Check: CI Bridge / clang_tidy
- GitHub Check: CI Bridge / build_exatrkx
- GitHub Check: CI Bridge / linux_ubuntu_2404_clang19
- GitHub Check: CI Bridge / build_exatrkx_cpu
- GitHub Check: CI Bridge / lcg_105: [alma9, gcc13]
- GitHub Check: CI Bridge / linux_ubuntu_2404_clang19
- GitHub Check: macos
- GitHub Check: linux_ubuntu_extra (ubuntu2204, 20, g++)
- GitHub Check: linux_ubuntu
- GitHub Check: linux_ubuntu_extra (ubuntu2404_clang19, 20, clang++-19)
- GitHub Check: missing_includes
🔇 Additional comments (5)
.github/workflows/analysis.yml (5)
25-25: New Dependency Tag Environment Variable Set, It Is!
The newDEPENDENCY_TAG: v7_b7is added rightly, replacing the old dependency URL. Clear and aligned with our new strategy, this change is.
33-33: Updated Container Image in Build Debug Job, Yes!
The container image now points toghcr.io/acts-project/ubuntu2404:74. Consistent environment, this provides. Good, it is.
38-42: Dependency Installation via Custom Action, Mmm!
Using the custom action at./.github/actions/dependencieswith parameters (compiler: g++andGITHUB_TOKEN) is a clear improvement over the old script. Well structured, the configuration is.
96-96: Updated Container Image in Build Performance Job, Very Good!
The performance job now uses the updated container image (ghcr.io/acts-project/ubuntu2404:74), ensuring consistency across jobs. Satisfied with this, I am.
101-106: Reusing Dependency Custom Action in Performance Job, You Are!
The dependency installation step using the custom action in the performance job is consistent with the debug job. Maintain this clarity, you must.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
CI/dependencies/setup.sh (2)
120-141: 🛠️ Refactor suggestionBuildcache mirror and OpenGL section, validated mirror URL you should check.
The mirror URL is chosen based on the CI provider; however, validating the URL against an expected pattern, you must—for safety and clarity, hmmm.
181-187: 🛠️ Refactor suggestionGeant4 data directory patch, symlink creation improved it can be.
While the symlink is created, check if the target already exists and remove it if necessary, to avoid errors you should.-mkdir -p "${geant4_dir}/share/Geant4" -ln -s "${geant4_dir}/share/Geant4/data" "${view_dir}/share/Geant4/data" +mkdir -p "${geant4_dir}/share/Geant4" +if [ -e "${view_dir}/share/Geant4/data" ]; then + rm -f "${view_dir}/share/Geant4/data" +fi +ln -s "${geant4_dir}/share/Geant4/data" "${view_dir}/share/Geant4/data"
🧹 Nitpick comments (6)
CI/dependencies/setup.sh (6)
1-4: Strict mode setup, improve you must.
The use ofset -uandset -eis good, but missingpipefailis—set-euo pipefailyou should for more robust error handling.-oldstate="$(set +o)" -set -u -set -e +oldstate="$(set +o)" +set -euo pipefail
99-99: Directory creation—quote the destination, you must.
Unquoted${destination}may cause issues if spaces appear; better to use"${destination}"you should.-mkdir -p ${destination} +mkdir -p "${destination}"
101-105: Setting_spack_folder, caution with quoting you must take.
Enclose variable references in quotes to avoid word-splitting and globbing, wise it is.-if [ -n "${GITLAB_CI:-}" ]; then - _spack_folder=${CI_PROJECT_DIR}/spack -else - _spack_folder=${PWD}/spack -fi +if [ -n "${GITLAB_CI:-}" ]; then + _spack_folder="${CI_PROJECT_DIR}/spack" +else + _spack_folder="${PWD}/spack" +fi
114-118: GitLab CI spack configuration, caution advised there is.
Linking the project-specific Spack config is useful. Consider checking if the.spacklink already exists before linking, to prevent conflicts you might.
174-179: Installation of Spack packages in parallel, caution with pipelines you should have.
Usingteeandgrepin a pipeline is clever, yet withoutpipefailerrors might be missed; ensure thatset -o pipefailis active in strict mode, you must.
190-199: Python environment preparation, good it is—but pin package versions you might.
The creation of a virtual environment is well executed; however, for reproducibility, specifying exact versions forpyyamlandjinja2is best practice, it is.-"${venv_dir}/bin/python3" -m pip install pyyaml jinja2 +"${venv_dir}/bin/python3" -m pip install pyyaml==6.0.1 jinja2==3.1.3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
CI/dependencies/setup.sh(1 hunks)cmake/setup_withdeps.sh.in(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- cmake/setup_withdeps.sh.in
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: merge-sentinel
🔇 Additional comments (12)
CI/dependencies/setup.sh (12)
6-9: Script directory and color export, well done they are.
Using a subshell to setSCRIPT_DIRand exportingSPACK_COLOR=alwaysis clear and concise, yes.
10-21:set_envfunction, clear and simple it is.
The function handles environment variable setting for both GitHub Actions and local environments nicely.
23-30:start_sectionfunction, grouping handled it is.
Your conditional grouping for GitHub Actions is neat, it is.
32-36:end_sectionfunction, properly done it is.
Ending sections in GitHub Actions is done with clarity, hmm.
38-68: Command-line argument parsing, robust it appears.
The use ofgetoptsto capture options and display help is well implemented. Ensure all arguments are quoted when necessary, you might.
70-92: Parameter defaults, set wisely they are.
Defaulting thecompiler,tag, anddestinationbased on the environment is a thoughtful design.
94-98: Informative echoes, they are most useful.
Echoing the installation tag and destination helps with transparency in CI logs, it does.
107-113: Spack installation block, logical it is.
Checking forspackand installing it if absent is well structured; good job, you have done.
143-163: Spack lock file retrieval, elegant the command array is.
Using an array to build the command for selecting the lockfile shows clarity and modularity, it does.
168-172: Spack environment creation, properly done it is.
The steps to create, inspect, and verify the Spack environment are clearly delineated; good, this approach is.
201-212: Environment variable setup, clear and effective it is.
Appending paths for GitHub Actions and setting key environment variables usingset_envstreamlines the configuration; excellent work, it is.
214-215: Restoration of shell state, proper this is.
Usingeval "$oldstate"to restore the prior shell options shows care for external environment integrity, yes.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
.gitlab-ci.yml (2)
21-30: 🛠️ Refactor suggestionCache key file reference, inconsistent it appears.
In your .spack_cache block, the file still points to “CI/dependencies/setup_spack.sh” while your current dependency script is “CI/dependencies/setup.sh”. To keep the cache aligned with your new changes, update this reference:- - CI/dependencies/setup_spack.sh + - CI/dependencies/setup.sh
300-303: 🛠️ Refactor suggestionInconsistent path usage in linux_ubuntu job, you have detected one.
Here “src/CI/dependencies/setup.sh” is invoked instead of the conventional “CI/dependencies/setup.sh”. For consistency across the Force, change:- src/CI/dependencies/setup.sh -c g++ -e .env + CI/dependencies/setup.sh -c g++ -e .env
🧹 Nitpick comments (4)
CI/dependencies/setup.sh (3)
2-3: Stronger error handling, you must have.
Set not just “-e” and “-u” but add “-o pipefail” for a more robust failure mode. Consider changing:- set -u - set -e + set -euo pipefail
114-114: Quote your variables, you should.
When creating directories, wrap your variable in quotes to avoid word-splitting surprises. For example, change:- mkdir -p ${destination} + mkdir -p "${destination}"
201-202: Force the symlink, consider you might.
When linking Geant4 data, if the target exists an error may occur. Use the force option on “ln -s” to overcome such dark side obstacles:- ln -s "${geant4_dir}/share/Geant4/data" "${view_dir}/share/Geant4/data" + ln -sf "${geant4_dir}/share/Geant4/data" "${view_dir}/share/Geant4/data".gitlab-ci.yml (1)
7-11: New variables introduced, they are.
“SPACK_VERSION” now set to “develop-2025-03-23” and “LOCKFILE_CACHE_DIR” defined. Ensure that the SPACK version you invoke truly exists in the upstream repository, you must.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.gitlab-ci.yml(18 hunks)CI/dependencies/setup.sh(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
.gitlab-ci.yml (1)
Learnt from: paulgessinger
PR: acts-project/acts#3980
File: .gitlab-ci.yml:67-67
Timestamp: 2025-03-26T14:24:15.432Z
Learning: When reviewing file paths in CI scripts, consider the working directory context set by previous commands like `cd`. In the Acts project's CI, many scripts are executed from within the `src` directory after cloning the repository.
⏰ Context from checks skipped due to timeout of 90000ms (20)
- GitHub Check: CI Bridge / lcg_107: [alma9, gcc14]
- GitHub Check: CI Bridge / lcg_107: [alma9, gcc13]
- GitHub Check: CI Bridge / lcg_106a: [alma9, clang16]
- GitHub Check: CI Bridge / lcg_106a: [alma9, gcc14]
- GitHub Check: CI Bridge / lcg_106a: [alma9, gcc13]
- GitHub Check: CI Bridge / linux_ubuntu_2404_clang19
- GitHub Check: CI Bridge / build_exatrkx_cpu
- GitHub Check: CI Bridge / lcg_105: [alma9, gcc13]
- GitHub Check: CI Bridge / lcg_105: [alma9, clang16]
- GitHub Check: CI Bridge / build_linux_ubuntu
- GitHub Check: CI Bridge / linux_ubuntu_2204
- GitHub Check: CI Bridge / build_exatrkx
- GitHub Check: CI Bridge / clang_tidy
- GitHub Check: CI Bridge / clang_tidy
- GitHub Check: CI Bridge / build_exatrkx_cpu
- GitHub Check: missing_includes
- GitHub Check: build_debug
- GitHub Check: linux_ubuntu
- GitHub Check: macos
- GitHub Check: linux_ubuntu_extra (ubuntu2204, 20, g++)
🔇 Additional comments (14)
CI/dependencies/setup.sh (4)
137-151: Mirror configuration appears solid, yet caution you must take.
Your buildcache mirror setup is clear; however, if extra safety you desire, validate the mirror URL format before use. This may further fortify your defenses.
95-106: The “set_env” function, clear it is.
Good job printing and appending environment variables. For added safety, you might check that both key and value are non-empty, though not strictly needed in your context.
208-213: Python environment prepared well, it is.
Your virtual environment creation and package installation are done in a neat manner. Continue as you are, young Padawan.
216-227: Environment variables set you are, with clarity.
Your usage of “set_env” for critical variables is consistent and clear. No obvious disturbance in the Force there..gitlab-ci.yml (10)
67-70: Dependency setup in clang_tidy, approved it is.
Your call to invoke “CI/dependencies/setup.sh -c clang++ -e .env” and sourcing the environment is consistent and well-crafted.
120-122: Build_exatrkx_cpu job’s dependency setup, strong it looks.
The invocation of “CI/dependencies/setup.sh -c g++ -e .env” followed by sourcing “.env” is done correctly.
164-167: Build_exatrkx job, dependency setup calls are consistent.
Your use of “CI/dependencies/setup.sh -c g++ -e .env” followed by sourcing the environment remains reliably the same.
197-200: Test_exatrkx_unittests job setup, harmonious it is.
The dependency script call and sourcing of “.env” mirror the good pattern seen elsewhere.
223-225: Test_exatrkx_python job, dependency setup consistent and true.
The command “CI/dependencies/setup.sh -c g++ -e .env” followed by “source .env” is correctly applied.
253-256: Build_gnn_tensorrt job, setup procedure commendable it is.
The dependency invocation aligns with the established pattern, ensuring environment readiness.
353-356: Linux_test_examples job, dependency setup continues its consistency.
The same command pattern “CI/dependencies/setup.sh -c g++ -e .env” and sourcing is well maintained.
389-392: Linux_physmon job, the dependency setup resonates with the Force.
Your use of the setup script remains regular and strong.
431-434: Linux_ubuntu_extra job, dependency setup—clear and proper it is.
The call “CI/dependencies/setup.sh -c ${CXX} -e .env” and then sourcing “.env” follows your design accurately.
492-493: Updated LCG image, you have.
Using “registry.cern.ch/ghcr.io/acts-project/${OS}-base:74” appears to be a careful update. Verify that the image tag aligns with your deployment needs, you should.
|
PLEASE DESCRIBE YOUR CHANGES.
THIS MESSAGE ENDS UP AS THE COMMIT MESSAGE.
DO NOT USE @-MENTIONS HERE!
--- END COMMIT MESSAGE ---
Any further description goes here, @-mentions are ok here!
feat,fix,refactor,docs,choreandbuildtypes.Summary by CodeRabbit
New Features
Chores