Skip to content
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

Pull arch information out of the Dockerfiles and into the base-spack matrix #90

Open
CodeGat opened this issue Aug 28, 2023 · 1 comment
Labels
priority:low A low priority issue - 'nice to haves' or issues that don't impact functionality type:feature New feature or request

Comments

@CodeGat
Copy link
Member

CodeGat commented Aug 28, 2023

We might want to test various architectures with our CI rather than just linux-rocky8-x86_64. Since this information is used in both base-spack (for installing the compiler) and build-<model> (for installing the packages), it must be done early in the matrix strategy.
Potentially in a [[compiler x arch] x model] format. So:

--- build-and-push-image-build ------ base-spack (comp1, linux-rocky8-x86_64) ------- build (access-om2, comp1, linux-rocky-x86_64)
                                 |                                              | --- build (access-om3, comp1, linux-rocky-x86_64)
                                 |--- base-spack (comp1, windows-10-x86_64) --------- build (access-om2, comp1, windows-10-x86_64)
                                 |                                              | --- build (access-om3, comp1, windows-10-x86_64)
                                 |--- base-spack (comp2, linux-rocky8-x86_64) ------- build (access-om2, comp2,  linux-rocky8-x86_64)
                                 | ...

Luckily, the arch information will be stored in an ENV in the base-spack image, so it is easily accessible via SPACK_ENV_ARCH.

@CodeGat CodeGat added type:feature New feature or request priority:medium A medium priority issue - has some impact on functionality labels Aug 28, 2023
@CodeGat CodeGat added priority:low A low priority issue - 'nice to haves' or issues that don't impact functionality and removed priority:medium A medium priority issue - has some impact on functionality labels Oct 16, 2023
@CodeGat
Copy link
Member Author

CodeGat commented Oct 16, 2023

Deprioritizing this issue as the need for different architectures isn't pressing. Can revisit later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority:low A low priority issue - 'nice to haves' or issues that don't impact functionality type:feature New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant