Scott Wittenburg

> it persists... curiously enough. Bug in Gitlab? Yeah, that's weird. I was tempted to think it was a bug in gitlab, but since it seems to happen consistently with...

Regarding updating the `protected-publish` job to run even if prior jobs failed: I just saw a case where I'm not sure that behavior would be desirable. In this [pipeline](https://gitlab.spack.io/spack/spack/-/pipelines/358146), all...

fyi @kwryankrattiger

Just pointing out that if the rebuild job can never get scheduled onto a pod, as in the jobs you linked above, then we definitely don't report anything to the...

Yes, by looking down that list at the other failures of the same hash, I found the one that actually got scheduled, ran, and the build failed (and said it...

Oh hum, it seems we already have one: https://github.com/spack/spack-infrastructure/blob/main/k8s/staging/custom/gitlab-setting-updater/kustomization.yaml So either it's not working, or the limit needs to be raised again (raised recently in #615).

Hi @frankwillmore, thanks for giving it a try. I'm curious if this is happening when running the spack-infrastructure setup or in your own instance of gitlab? At any rate, this...

Thanks @opadron, you're right that's an old image and probably shouldn't be used anymore. The branch on the repo I linked above (`spack-tutorial-container`) has a better and more recent example...

Oh, and I just remembered that spack `0.14.0` included the distributed builds PR, an otherwise really great feature which broke the automated pipelines (because it broke `spack install --only [dependencies|package]`,...

So I just ran through the README, starting from a clean slate, and found that with a couple exceptions, the workflow is mostly working fine. I created #18 to reflect...