Any `export` statement in a pipeline description will leak across different compiler stages or, worse, between two runs of the entire pipeline. This was seen recently in two ways: 1. The Dwarf 2 / 4 runs were using a Clang 13.0 built on a previous pipeline run, and they were failing because some tests require ToT clang. 2. The Dwarf 2 / 4 runs were trying to use Clang 13.0, but the workspace was cleaned after the previous pipeline run, resulting in a "cannot find clang" error. This commit addresses the issue by no longer using environment variables to communicate which Clang to use when building LLDB tests. Instead, we now use parameters to the `test_monorepo_build.py` script. More generally though, there are still a lot of `export` statements in the pipeline, and these should be examined in isolation to determine how to best remove them. Jenkins provides ways to set environment variables more carefully [1]; however, for the purposes of the LLDB test compiler variable, this is dangerous: we don't want such a flag to last any longer than the CMake configure step, so this commit uses the script argument approach. [1]: https://www.jenkins.io/doc/book/pipeline/syntax/#environment
Details
Diff Detail
- Repository
- rZORG LLVM Github Zorg
Event Timeline
Quoting what I said in D132004:
Looking at the logs, the Dwarf 2 and Dwarf 4 jobs do not use ToT, but rather Clang 13. For example, for the Dwarf 2 job, we see this:
"/Users/buildslave/jenkins/workspace/lldb-cmake-matrix/clang_1300_build/bin/clang" -std=c++11 -gdwarf-2 -isysroot
Which is weird, given how we don't build Clang 13 until much later on the pipeline.
I think the bot has a polluted environment somehow across runs. For example, build 5042:
ERROR:root:/Users/buildslave/jenkins/workspace/lldb-cmake-matrix/clang_1300_build/bin/clang is not a valid compiler executable; aborting...
Sometimes the Clang13 builds get cleaned up (see how sometimes the Clang 13 jobs take 30s to run, and sometimes 40min).
I'm guessing that this error shows up when the previous build got cleaned up.
Edit: I'm assuming the intent of the Dwarf 2 / 4 tests is to use ToT Clang
zorg/jenkins/monorepo_build.py | ||
---|---|---|
1070 | I thought I'd be saving diff lines by keeping the old name, but now that you mention it, I'm saving a single line in favour of a poor name. Will change! | |
1071 | I thought there would be some extra type checking by using that, but everywhere else we're using strings, so I'll change this too |
zorg/jenkins/monorepo_build.py | ||
---|---|---|
1070 | tip: ArgumentParser will automatically use lldb_test_compiler as the dest name for --lldb-test-compiler, so if you'd like you can leave the dest unspecified. |
zorg/jenkins/jobs/jobs/lldb-cmake-matrix | ||
---|---|---|
203–204 | If the export "leaks" across stages, can we avoid the duplication of this line and instead do this once at the beginning with a stage that sets up the environment? |
Removed default name for the variable
zorg/jenkins/jobs/jobs/lldb-cmake-matrix | ||
---|---|---|
203–204 | Yes, I think so, this is something I'd like to look at next. I was hoping to do this in isolation though, too many things going on with these bots right now :) |
If the export "leaks" across stages, can we avoid the duplication of this line and instead do this once at the beginning with a stage that sets up the environment?