CI: 2023 05 05

Attendees

Dan presented a demo that's looking really nice!
Next step is to deploy it, either overwriting the existing site or making a new -dev one.
Related: we should include size in the index.json to avoid a requiring S3 access to build this site.
We should also investigate similarly refreshing packages.spack.io as time allows so these two companion sites have a similar look & feel

Our cluster upgrade last week did not go as smoothly as we would have liked, but we are now at a point where all our services are operational again. We will keep an eye on our dashboards to make sure we're not experiencing a higher-than-usual failure rate from our GitLab CI pipelines.
That being said, the cluster migration did complete successfully, so we're hoping to see reduced data transfer costs in the coming weeks.
Jake is making progress with new prometheus queries that will allow us to better capture cost-per-job and per-package stats.

Scott drafted a design document outlining how we will implement this new type of release + snapshot buildcache.
Some decisions that we made during this meeting:
- Create new snapshot releases on a weekly basis
- Use the same strategy for snapshot mirrors and point release: copy existing packages from the develop/release buildcaches.
- Use the lock file from the successful develop pipeline to determine what packages should be included in the snapshot buildcache.
- Keep snapshots for 6 months
Alec & Todd are going to discuss how to smoothly handle upgrading from one snapshot to the next

Install a new cronjob to prune the develop buildcache.
Implement and deploy our new strategy for release pipelines.
Push a live public demo for the redesign of cache.spack.io.
Keep an eye on costs & pipeline success rate. Respond swiftly if success rates drop below 97%.
Keep working towards on costs-per-job & better per-package metrics.