This is an archive of the discontinued LLVM Phabricator instance.

[lldb-cmake-matrix] Fix environment leak across runs
ClosedPublic

Authored by fdeazeve on Aug 17 2022, 8:25 AM.

Details

Summary
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

Diff Detail

Event Timeline

fdeazeve created this revision.Aug 17 2022, 8:25 AM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: mgorny. · View Herald Transcript
fdeazeve requested review of this revision.Aug 17 2022, 8:25 AM
fdeazeve added a comment.EditedAug 17 2022, 8:29 AM

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:

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/5042/execution/node/52/log/?consoleFull

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

Michael137 accepted this revision.Aug 17 2022, 8:35 AM

nice! lgtm

This revision is now accepted and ready to land.Aug 17 2022, 8:35 AM
aprantl accepted this revision.Aug 17 2022, 9:04 AM
kastiglione added inline comments.
zorg/jenkins/monorepo_build.py
1070

the default dest name would be lldb_test_compiler, is there a reason to override with squished case?

1071

what is the benefit of specifying type=pathlib.Path? Its value is used as a string.

fdeazeve added inline comments.Aug 17 2022, 9:26 AM
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

fdeazeve updated this revision to Diff 453309.Aug 17 2022, 9:33 AM

Addressed review comments

kastiglione accepted this revision.Aug 17 2022, 9:36 AM
kastiglione added inline comments.
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.

JDevlieghere added inline comments.
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?

fdeazeve updated this revision to Diff 453317.Aug 17 2022, 9:41 AM

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 :)

This revision was landed with ongoing or failed builds.Aug 17 2022, 9:46 AM
This revision was automatically updated to reflect the committed changes.