-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support using tags when cloning a Spack repository #98
Comments
Will be looking into this as well. We will need to verify that |
@harshula is the expectation that for some tag |
I'd like to see the same functionality that is now available for |
My issue with this is that we could run into a situation where we have multiple models which all request to deploy to different commits within a single As a compromise, could we keep the Solution 1: Config File with VersionsOption one is to have a global {
"spack-version": {
"0.20": "aabbccdd",
"0.21": "0.21-2024.07.09",
"0.22": "11122233"
}
} This file would act as a versioned piece of provenance regarding what commit of Solution 2: User-dispatchable WorkflowIn this solution, the workflow is an update to the existing |
Hi @CodeGat , How are you avoiding the same problem w.r.t. |
We haven't been able to, yet. But we shouldn't add any more possibilities for concurrent access violations. |
Then a solution must also include a fix for the current way of using tags for |
Yes, that would. In that case, solution 1 seems to be the way to go |
At the moment we appear to be able to clone
spack-config
andspack-packages
based on a tag. We don't appear to have that functionality when cloning Spack.We now have an ACCESS-NRI Spack fork where we backport essential forks from upstream's
develop
branch and/or create commits that we require. Hence, it is now important to be stricter with the state/version of the Spack repository that we deploy.The text was updated successfully, but these errors were encountered: