Repository navigation
Skip cloning software-layer-scripts when debugging builds interactively - #1832
Conversation
…ive builds, as they were introduced in EESSI/software-layer-scripts#321
Neves-P
left a comment
There was a problem hiding this comment.
Looks good to me!
I checked this by going to a failed build and replacing the bot/build.sh with the modified version here. If I then run the script with ${EESSI_INTERACTIVE_BUILD} and have renamed the software-layer-scripts directory, then it fails because it does not have the software-layer-scripts there. If I clone the directory and try it again, it runs as expected without attempting to clone over an existing software-layer-scripts dir, which is also what we want.
So this is good to go 🥳
@casparvl , I've never handled PR's that needed changes to the EXPECTED_CHECKSUM variable, so I'm not totally sure how this works. I'm assuming the checksum is that of bot/build.sh itself?
|
It is. The only reason it is there, is to make sure that no one inadvertently or maliciously changes |
|
Understood, thank you! I also did So I can also verify that the checksum of the PR matches the one from the actual file 👍 |
EESSI/software-layer-scripts#321 introduces the ability to debug our builds interactively, in a way that is virtually identical to how the bot does it. Essentially, this is done by running:
in the job directory left behind by the build bot.
One issue with that approach is that
bot-build.slurmcallsbot/build.shfromsoftware-layer. This tries to (re)clonesoftware-layer-scripts, which fails (and exits, because ofset -e) when this is done in an existing staged job directory left behind by the build bot.This PR solves that by making bot/build.sh skip cloning of software-layer-scripts for interactive builds (i.e. if EESSI_INTERACTIVE_BUILD is non-empty).