gitlab ci install binary deps faster#33248
Conversation
08dd758 to
4d1af00
Compare
4d1af00 to
5d6b6ba
Compare
|
For reference:
or
|
e042d71 to
82cb426
Compare
|
@trws funnily enough we're hitting a broken |
|
Unfortunately the GNU make situation in our builders is rather sad:
Bootstrapping gmake is an option... |
253ae0b to
0e8b9fa
Compare
|
@spackbot run pipeline |
|
I've started that pipeline for you! |
lets do that, or grab a statically linked one, or upgrade it from the package managers, or something. |
|
@spackbot run pipeline (@zackgalbreath @scottwittenburg: seems like the above has triggered on the old HEAD of this PR -- I've force pushed and if you follow the link below, you get Merge 253ae0b into 0de1f98 but the force pushed commit was 0e8b9fa as you can see above). |
|
I've started that pipeline for you! |
|
It's a one-liner to install julia's cross-compiled version, more people should use julia as a package manager |
b9ec4a0 to
5b3c49b
Compare
|
Now seeing https://gitlab.spack.io/spack/spack/-/jobs/3862768 which is probably #31387, added #33478 and #33477 to improve at least the error... (I don't think it's a blocker since gitlab will retry and it happens at the start) |
100248f to
7756eab
Compare
kwryankrattiger
left a comment
There was a problem hiding this comment.
Two gripes that don't need to be fixed, mostly just notes for me later when we get to the CI module refactor
- Downloading the make isn't my favorite, but I don't have a better solution, so end of gripe 😞
- Windows CI, whenever ever it happens, will likely not work well with this. So it will eventually need to be an option instead of always on. Other options would be adding Ninja (@haampie and I talked about this briefly) or adding finer-grained parallel install support in spack itself.
Thanks for your work on this @haampie
|
For windows we'd need to do some refactoring anyways, since we're now generating and executing a shell script. There's already room for |
|
@spackbot run pipeline |
|
I've started that pipeline for you! |
|
how do I make gitlab ci pass on this pr... Merge develop into here? |
|
@spackbot run pipeline |
|
I've started that pipeline for you! |
|
merging develop s.t. hopefully the openblas hash changes by in something more favorable... |
|
@zackgalbreath what can I do to make this PR pass? Apparently merging develop doesn't change the openblas hashes. Why is it failing in this PR? |
|
ping @scottwittenburg / @zackgalbreath / @kwryankrattiger, no clue how to proceed here. |
881fe02 to
83a527e
Compare
|
I'm not sure what you can do while there is a broken |
|
It's not an emergency, but this is a ridiculous situation to be in... I don't need to fix openblas here, it's unrelated to my PR. Now my PR is blocked by it :|. |
I agree it's unfortunate, sorry. But what policy do you disagree with specifically? That we fail PRs that generate broken hashes? Or just that it affects this particular PR? Keep in mind that one policy is not to prune "untouched" specs from a stack if the PR touched the @tgamblin in case you're interested in discussing whether any of these policies should be revisited. |
|
@zackgalbreath unmarked openblas cause it's a buildmachine related issue (apparently their makefile still checks the host arch even wtih DYNAMIC_ARCH=1, and the cpu type of the build node was something weird?) |
|
@spackbot run pipeline |
|
I've started that pipeline for you! |
alalazo
left a comment
There was a problem hiding this comment.
We should eventually bootstrap make and tar too.
* Fast Gitlab CI job setup, and better legibility * Use a non-broken, recent GNU Make
* Fast Gitlab CI job setup, and better legibility * Use a non-broken, recent GNU Make
This PR does a few things:
spack -dflags, so we get to see the build logs before hitting the max log size....
This PR is built on top of these parts:
--use-buildcacheflag. #33315