Current mechanism does not work well due to need to upload version.
Rebuilding a container from an alder revision also leads to overriding
existing container version.
The current default version in Chocolatey, 5.28, fails to install.
This was previously worked around by pinning a newer upcoming
version, 5.28.0.20210106. However this version never got approved
into Chocolatey (for unknown reasons), so it's no longer available.
Therefore instead request the previous older version, 5.24.3.2404001,
which installs correctly.
The current default version in Chocolatey (5.28) fails to install,
with the following error:
ERROR: The response content cannot be parsed because the Internet
Explorer engine is not available, or Internet Explorer's first-launch
configuration is not complete. Specify the UseBasicParsing parameter
and try again.
This is fixed in a newer version of packaging of ActivePerl, thus request
this particular version.
The libcxx tests currently require bash to be available (although
that might change), and the bash provided with Git is enough for
fulfilling this need. (Bash can also be useful for running other
scripts in the libcxx CI chain outside of the tests themselves.)
For the main LLVM testing, this works once
https://reviews.llvm.org/D98858 is merged.
This also allows getting rid of GnuWin altogether.
The GnuWin32 tools installed by Chocolatey reside in C:\GnuWin, and
are added automatically to the path.
The CMake tools aren't added automatically to the path though, so
that entry still is useful.
(However, the Visual Studio installation also brings along
a different version of CMake that ends up found if the one we
installed via Chocolatey isn't available.)
The main LLVM build runs fine with MSVC itself, but building libcxx
isn't supported with cl.exe, only with clang-cl.
This shouldn't matter for the main LLVM build, as it still is
configured to use CXX=cl (and even then, CMake defaults to cl
if nothing is specified).
Those bindings requires extra dependencies (like Python, pybind11)
and clang-tidy fails to analyze the source files if they are not
configured properly.
Now "report" step combines result in a uniform way and processes unit test
results XML output. It works for sub-builds only started from the 'premerge'
pipeline, i.e. non-recursive. One downside is that now one has to wait until
all jobs have finished.
- Add instructions to setup python environment
- added option to do full report cycle but not call Phabricator
- use "annotations" to show build status. That lifts the need to filter ninja
and other output (thus `ph_no_filter_output` param removed) and output
everything. That is nice as script failures no longer lead to loss of logs.
- improved annotate() usability
- misc fixes
- improve messaging and add instructions how to fix the patch
- fix application of patch stack. Now base commit and order of patches
should be correct
- set origin to llvm-project fork to avoid accidental operations on origin
- use annotations to make issues visible
- create commits with original author of change
- add patches we tried to apply to artifacts
- patching / commits works locally if --push-branch=false is set
- misc renames / wordings
fixes#192
additionally:
- install python libs after scripts checkout, so we don't need to
rebuild images and restart agents only to add a new python dependency
- updated lib versions
- similar scripts checkout in steps
Previous approach had drawbacks:
- every step had to implement exporting of results in fixed format
- if step failed then failure will not be detected
Now report step will fetch results directly from Buildkite.
Agents have to be updated to have BUILDKITE_API_TOKEN env.
Previously list of projects was resolved when job run at target OS.
Now project resolution is moved to the premerge pipeline and logic
should be there.
Now we run a pre-commit hook that tries to kill any process that locked
a file in target directory.
Updated timeout interval on windows from 120 to 90 minutes.
Fixes#243
Now it's possible to allow sub-projects to define own checks and skip
"generic" ones.
To properly accomodate affected projects that might not have special
treatment we:
1. extend the set of affected projecs with dependent (e.g. add 'libc' if
'clang' was modified)
2. add custom steps for projects that define own workflow. At the moment
it's only libcxx and it has a custom trigger pipeline so it's noop.
3. add dependent projects and run generic check on them.
To illustrate: imagine that we have a dependency graph:
llvm -> clang -> openmp
and only clang was modified in a diff; also clang defines own checks.
Thus list of affected projects will be [clang, openmp].
After adding custom checks and removing their projecst: [openmp].
After adding dependencies: [llvm, clang, openmp]. Generic linux /
windows checks will be run on thouse 3 projects.
So as you can see in some scenarios projects with custom checks will
still go through generic checks.
Note that clang-format and clang-tidy checks are run only for "generic"
checks at the moment.
