CI: 2023 03 10
Zack Galbreath edited this page Mar 10, 2023
·
1 revision
- This is because amazonlinux-2's version of gpg is too old.
- Fixed in https://github.com/spack/gitlab-runners/pull/18 and https://github.com/spack/spack/pull/35976
- Do we need more self-hosted runners registered to the gitlab-runner repository so we don't have to use QEMU?
- Caching there would be great too. These links might be handy if we want to do layer caching:
- https://docs.docker.com/build/ci/github-actions/cache/
- https://github.com/tonistiigi/go-actions-cache/blob/master/api.md
- (Alec & Harmen are going to look into this as time allows)
- Scott's merge queue plan
- Should merge queue pipelines be performed by our public or protected runners?
- Benefits of protected runners:
- Can graduate binaries straight from merge queue to develop build cache; no need to rebuild in develop.
- Benefits of public runners:
- Can share binaries between PR and merge queue builds
- Benefits of protected runners:
- For now we are going to target public pipelines for merge queue branches, but if possible we would like to make this toggleable so we can test out both approaches.
Metrics we want to capture include:
- Number of rebuilds per hash
- Failures per hash
- Number of times a hash is reused from cache
New task: improve cache.spack.io
The purpose of this page is to browse the available binaries for a given public build cache.
- First step: think about what it should look like after we start publishing snapshot caches.
- Make it clear what binaries are where
- At a top level, list what build caches are available, and provide brief instructions on how to use them.
- Missing features from the current implementation:
- Mention what OS a package was built for
- Also indicate what stack the binary was built for (ie match our S3 directory structure)
- We also need to make sure that this page is automatically updated on a regular basis