Ci reactivate darwin pipelines#48453
Conversation
|
@spackbot run pipeline |
|
I've started that pipeline for you! |
|
@spackbot run pipelines - tweaked local runner environment |
|
I've started that pipeline for you! |
|
@spackbot run pipelines -- due to pipeline failures in generate jobs that seem unrelated to this PR specifically? |
|
I've started that pipeline for you! |
693f8f3 to
42d4f0e
Compare
|
There is an issue with the stage dir and permissions such that files are being created which cannot be deleted! One of the first actions the gitlab-runner takes on processing a new job is to delete files from the old job, and that is failing because of the permission shown above: We do want to keep the stage dir like below, but we need the permissions to be such that the files can be cleaned-up/deleted! |
82e8eb0 to
3e9eb2c
Compare
The issue here appeared to be due to golang mod files being created with read only permissions, by design. We can simply invoke |
|
@spackbot run pipeline |
|
I've started that pipeline for you! |
|
@spackbot run pipeline |
|
I've started that pipeline for you! |
0b23a3b to
c4c32bf
Compare
|
There are a few build errors blocking this: From: bootstrap-aarch64-darwin-build From: developer-tools-darwin-build |
|
OpenMPI seems to hang forever:
|
|
@spackbot run pipeline |
|
I've started that pipeline for you! |
|
OpenMPI build freezes, never completes, resulting in job timeout: I would disable OpenMPI until this could be figured out but many packages from the Many if not all the clingo-bootstrap builds fail in |
|
For all ML pipelines, we can use any MPI provider. I recall having some kind of problem with whatever was being chosen by default and had to force it to be OpenMPI, but feel free to undo that. It may not even be needed on macOS. |
|
@spackbot run pipeline |
|
I've started that pipeline for you! |
|
The only build errors remaining here are |
|
What happens when you require mpich? |
|
I commented out the handful of failing packages and all CI is green now. I think we should merge this now to bring the darwin pipelines back. Separately, I will follow up with a PR re-enabling the failing specs where we can iterate on fixes. Let's bring it back! @adamjstewart @kwryankrattiger |
adamjstewart
left a comment
There was a problem hiding this comment.
Only approving my own pipelines, don't fully understand the other changes.
|
All CI is going to be green here. Only one gitlab job remains and it is update-index. Any final reservations @kwryankrattiger? If not, I will turn on auto-merge and we will be back in business. |
kwryankrattiger
left a comment
There was a problem hiding this comment.
Two minor things, both can be pulled out to follow ups I think as neither poses immediate risks and maybe worth experimenting with /tmp changes more before reverting back to the default.
share/spack/gitlab/cloud_pipelines/stacks/ml-darwin-aarch64-mps/spack.yaml
Outdated
Show resolved
Hide resolved
|
OK. All fixed up based on recent comments. Turning on auto-merge. Will follow up with a PR to re-enable the failing py-torch* related specs. All CI is passing now. |
|
Is it just me, or is there no darwin pipeline that has been reactivated: https://gitlab.spack.io/spack/spack/-/pipelines/995843 ? I can't find any |
* ci: darwin stacks: update tags following system updates * disable SPACK_CI_DISABLE_STACKS; only enable *darwin* stacks for testing * manually chmod u+w tmp/ before cleanup due to issue#49147 * comment out failing specs for now * re-enable logic for disabling stacks * add explanatory comment for darwin after_script additions * remove more darwin-only targetting * restore build_stage to default location * move build-job-remove out of individual darwin stacks into darwin top level config * keep build_stage in $spack/tmp for now
Re-activating the darwin CI pipelines