Revert "ci: disable tutorial pipeline (#3249)"#3255
Conversation
This reverts commit c3ce4ac. Signed-off-by: Gregory Becker <[email protected]>
becker33
requested review from
kwryankrattiger and
zackgalbreath
as code owners
alecbcs
left a comment
alecbcs
left a comment
There was a problem hiding this comment.
I agree with Greg's assessment here. Although it's not building a perfect tutorial stack, it's useful to continue building these packages to in the interim to ensure they continue working for the tutorial.
kwryankrattiger
left a comment
kwryankrattiger
left a comment
There was a problem hiding this comment.
Agreed. I was a bit surprised to see it disabled
|
For context, this was disabled because the packages were built with a mix of The |
|
@kwryankrattiger Is there a way to mark a pipeline |
There was a problem hiding this comment.
I agree with @alalazo's xfail suggestion. Greg's reason to revert skips over the other reason this was merged.
I think it's more important to use latest Spack in this repo (#3253), especially after concretizer related changes, than it is to build the tutorial stack. It's not for lack of trying to make both work: https://spackpm.slack.com/archives/CJUC2P5M2/p1769612032952209, it's just practically impossible (either the concretizer gets stuck for ~2h, or it runs out of memory, or it produces incorrect results).
|
Hm, no, I take back that For example the tutorial pipeline continues to block improvements to packages: #3234. Concretization consistently times out after 1h+ there. |
This is a way better reason to disable and/or I am ok with keeping this disabled if we can:
Is that workable? I agree that it is important to keep the tutorial alive -- updating it before conferences is important. Thinking particularly for ISC -- if we do not reinstate the pipeline well before that, then getting the tutorial working for ISC is going to be painful. For users who want to do the tutorial, the build cache will live on, while we work out the kinks here -- in that people doing the tutorial via our containers can still rely on the binaries -- right? |
…ntainer) (#2277)" This reverts commit 8d0701f. Signed-off-by: Gregory Becker <[email protected]>
becker33
dismissed stale reviews from tgamblin, kwryankrattiger, and alecbcs
via
36f3ed8
|
As suggested in our slack conversation, I am also reverting the changes to the tutorial pipeline to use This will result in a stack that is not usable in the tutorial, but will at least check the relevant specs/builds until we can refactor this after spack/spack#51891 goes in. |
:) |
|
@spackbot run pipeline |
|
I've started that pipeline for you! |
|
I'd still be for reverting the revert, unless somebody wants to fix 
|
| # Test package relocation on linux using a modified prefix | ||
| # This is not well supported on MacOS (https://github.com/spack/spack/issues/37162) | ||
| - - spack config add "config:install_tree:projections:${SPACK_JOB_SPEC_PKG_NAME}/${SPACK_JOB_SPEC_DAG_HASH}:'morepadding/{architecture.platform}-{architecture.target}/{name}-{version}-{hash}'" | ||
| - - spack config add "config:install_tree:projections:${SPACK_JOB_SPEC_PKG_NAME}:'morepadding/{architecture.platform}-{architecture.target}/{name}-{version}-{hash}'" |
There was a problem hiding this comment.
This introduces bugs when we have multiple instances of the same package in the DAG. Just hit one in a branch with multiple gcc-runtime.
There was a problem hiding this comment.
I'll re-submit this change in a PR.
6 participants
This reverts commits c3ce4ac and 8d0701f.
We need the tutorial pipeline to keep running in CI. Yes, it elides the differences between two of the zlib-ng specs and that's not ideal. Yes, it will be better once we merge the concretization groups PR. But we still need to keep building it for now so that errors don't accumulate.The tutorial stack as used in the tutorial is not currently buildable in CI, but the old version with an external gcc is buildable to ensure things don't break.