search

eth-cscs / stackinator

https://eth-cscs.github.io/stackinator/
BSD 3-Clause "New" or "Revised" License
19 stars 15 forks source link

Question: manipulating spack mirrors and other defaults? #116

Closed j-ogas closed 1 year ago

j-ogas commented 1 year ago

Greetings.

We need to always override the spack clone's default mirrors.yaml and bootstrap/spack-install/metadata.yaml to use internal resources.

I've been experimenting with: a) managing my own spack clone, for example, checking out v0.20.0, editing the corresponding files, and committing the changes to a branch, e.g., internal-v0.20.0; (b) bind-mounting the corresponding files over {{build_path}}'s spack in our sandbox; and (c) bind mounting stuff in/etc/spack in the sandbox. All of which feel overly complex; I do not appear to be able to manipulate these defaults with the recipe/system-config templates.

Am I missing a simpler solution for this?

bcumming commented 1 year ago

Hi! You can specify the git repository and branch/commit in the config.yaml recipe file, e.g.: https://github.com/eth-cscs/stackinator/blob/master/unittests/recipes/host-recipe/config.yaml Can you point that to your own git repo + branch?

j-ogas commented 1 year ago

You can specify the git repository and branch/commit in the config.yaml recipe [...]

Indeed, that is what we do now. However, maintaining a local clone of Spack just to modify a couple of files to force bootstrapping and fetching from an internal mirror is a pain, especially for multiple tags.

I was hoping we could perhaps have the ability to specify these changes with this tool somehow, perhaps in the config.yaml? The idea is that we could always rely on fresh clones of Spack and target any branch, tag, etc., without having to maintain local commits for each.