adding sharing=locked into /var/cache/spack mounts in containers/eic/Dockerfile

[SebastianPaucar]

Briefly, what does this PR introduce? Please link to any relevant presentations or discussions.

This PR sets sharing=locked on the /var/cache/spack cache mounts in containers/eic/Dockerfile, so it prevents concurrent builds from interfering with each other's cache operations.

This is intended to fix FileNotFoundError failures during eicweb/eic_container CI builds. Check this #388 (comment)

Draft for now. cc @wdconinc

What is the urgency of this PR?

• High (please describe reason below)
• Medium
• Low

What kind of change does this PR introduce?

• Bug fix (issue #__)
• New feature (issue #__)
• Optimization (issue #__)
• Updated documentation
• other: __

Please check if any of the following apply

• This PR introduces breaking changes. Please describe changes users need to make below.
• This PR changes default behavior. Please describe changes below.
• AI was used in preparing this PR. Please describe usage below.

[github-actions]

Capybara summary for PR 413

• rec_dis_10x100_minQ2=1000_epic_craterlake_amd64 (Δ: 1) (new artifact) (ref artifact)
• rec_dis_10x100_minQ2=1_epic_craterlake_amd64 (Δ: 1) (new artifact) (ref artifact)
• rec_dis_18x275_minQ2=1000_epic_craterlake_amd64 (Δ: 1) (new artifact) (ref artifact)
• rec_dis_18x275_minQ2=1_epic_craterlake_amd64 (Δ: 1) (new artifact) (ref artifact)
• rec_dis_5x41_minQ2=1_epic_craterlake_amd64 (Δ: 1) (new artifact) (ref artifact)
• rec_dis_5x41_minQ2=1_epic_craterlake_amd64_vs_arm64 (Δ: 4219)
• rec_dis_5x41_minQ2=1_epic_craterlake_arm64 (Δ: 1) (new artifact) (ref artifact)
• rec_e_1GeV_20GeV_epic_craterlake_amd64 (Δ: 1) (new artifact) (ref artifact)
• rec_e_1GeV_20GeV_epic_craterlake_amd64_vs_arm64 (Δ: 3506)
• rec_e_1GeV_20GeV_epic_craterlake_arm64 (Δ: 1) (new artifact) (ref artifact)
• rec_pi_1GeV_20GeV_epic_craterlake_amd64 (Δ: 1) (new artifact) (ref artifact)
• rec_pi_1GeV_20GeV_epic_craterlake_amd64_vs_arm64 (Δ: 3456)
• rec_pi_1GeV_20GeV_epic_craterlake_arm64 (Δ: 1) (new artifact) (ref artifact)
• sim_dis_10x100_minQ2=1000_epic_craterlake_amd64 (Δ: 1) (new artifact) (ref artifact)
• sim_dis_10x100_minQ2=1_epic_craterlake_amd64 (Δ: 1) (new artifact) (ref artifact)
• sim_dis_18x275_minQ2=1000_epic_craterlake_amd64 (Δ: 1) (new artifact) (ref artifact)
• sim_dis_18x275_minQ2=1_epic_craterlake_amd64 (Δ: 1) (new artifact) (ref artifact)
• sim_dis_5x41_minQ2=1_epic_craterlake_amd64 (Δ: 1) (new artifact) (ref artifact)
• sim_dis_5x41_minQ2=1_epic_craterlake_amd64_vs_arm64 (Δ: 395)
• sim_dis_5x41_minQ2=1_epic_craterlake_arm64 (Δ: 1) (new artifact) (ref artifact)
• sim_e_1GeV_20GeV_epic_craterlake_amd64 (Δ: 1) (new artifact) (ref artifact)
• sim_e_1GeV_20GeV_epic_craterlake_amd64_vs_arm64 (Δ: 359)
• sim_e_1GeV_20GeV_epic_craterlake_arm64 (Δ: 1) (new artifact) (ref artifact)
• sim_pi_1GeV_20GeV_epic_craterlake_amd64 (Δ: 1) (new artifact) (ref artifact)
• sim_pi_1GeV_20GeV_epic_craterlake_amd64_vs_arm64 (Δ: 346)
• sim_pi_1GeV_20GeV_epic_craterlake_arm64 (Δ: 1) (new artifact) (ref artifact)
  ^{_{Last updated 2026-09-08T18:41-04:00 9d20421}}

[SebastianPaucar]

Hi @wdconinc, is there an EICweb infrastructure issue? This PR’s push to EICweb fails with HTTP 502, and #388 had repeated GHCR connection timeouts during the EICweb CI, even though the concretization and build steps succeeded. Could these be related? Is there something I’m missing? Happy to dig into it from my side if possible

[wdconinc]

is there an EICweb infrastructure issue?

Yes, we've had some backend instability yesterday, and today the whole frontend went down as well.

[SebastianPaucar]

is there an EICweb infrastructure issue?

Yes, we've had some backend instability yesterday, and today the whole frontend went down as well.

Could the heavy autopush workload from #388 have contributed to the EICweb backend instability, or are the GHCR timeouts likely unrelated? Just trying to understand what happened

[wdconinc]

Could the heavy autopush workload from #388 have contributed to the EICweb backend instability, or are the GHCR timeouts likely unrelated? Just trying to understand what happened

This is likely unrelated. The autopush functionality hardly contributes to bandwidth to the registry on eicweb at all. Even though we have probably O(10k) tags in the OCI buildcache, most of them are a few 10 MB at most. What drives the eicweb registry load is the publishing of docker layer caches, primarily those of the CUDA-enabled images which are O(20 GB) large.

[wdconinc]

I'm willing to just merge this in master, since the only way we will be able to assess if it works is not in a PR but in production by keeping an eye on these intermittent failures.

If you are ok with it, please just mark as ready for review, and I will merge it.

[SebastianPaucar]

I'm willing to just merge this in master, since the only way we will be able to assess if it works is not in a PR but in production by keeping an eye on these intermittent failures.

If you are ok with it, please just mark as ready for review, and I will merge it.

Sounds good, I’ll mark it ready for review. Let me know how the production testing goes.