The current version of Python fails to build some dependencies, but
pinning the previous version works.
ActivePerl is no longer installable via Chocolatey (neither current
nor older versions) as ActiveState don't provide the downloads
without registration any longer (and even if registered, only
provide the latest, continuously updated version for free users, which
can't match the package manager checksums), see http://disq.us/p/2ipditb
for further discussion.
Replace ActivePerl with StrawberryPerl. StrawberryPerl has other
drawbacks, as it installs a whole C/C++ toolchain as part of it,
and copies of pkg-config tools that can cause package misdetections.
Remove these after installing it, see
https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/11
for discussion on the inconveniences of installing it.
This bundles clang/lld and associated tools, configured for a mingw
target, with corresponding mingw sysroots.
As we already install the 'llvm' chocolatey package, which also
provides clang (defaulting to a MSVC target), add this one last in the
path. This lets 'clang' refer to the default MSVC-targeting tool, while
one can use a GCC style triple prefixed driver name, like
x86_64-w64-mingw32-clang, to use this tool.
This allows setting up a much-needed mingw configuration for the libcxx
CI.
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).
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
- moved linux agents to a new node pool (basically renamed old one)
- removed some out of date scripts or moved them to playlists
- removed shell scrips invoked from jenkins
- minor docs updates
Some python classes methods are not used anymore and will be cleaned up
separately.
https://ccache.dev/manual/3.7.11.html#_configuration uses CCACHE_DIR to set
cache directory. CCACHE_PATH has a different meaning.
+ removed LLVM_CCACHE_DIR ccache argument to use CCACHE_DIR from env.
+ print additional info about ccache config and machine readable stats.
apt.llvm.org signature has changed, we also should use debian:stable
(=buster) as a base image to correctly install packages.
Removed jdk from the base image as it was used only by Jenkins.
Log packages version for every build.
Related issues: #112
- configured sccache on buildkite windows machines
- final result is sent to phabricator from "summary.py" that waits for both builds to complete
- extracted "add_url_artifact" to a runnable script
- reorganized code and fixed some of TODOs
I have tried to install new windows machine for buildkite and updated
some scrips and docs on along the way.
- Updated base image for k8s agent installation as it gave a warning that
previous version was old.
- Now buildkite secret is configured in a powershell script along with
tags (and possible other parameters).
- Split "windows_agent_start.ps1" to "..jenkins" and "..buildkite" as
some parameters are different.
- Created a "windows-development" machine in GCP stat can be resumed
to build docker images / expriment.
Harbormaster can send a request in url encoded form while buildkite
expects a POST request with json. Instead of modifying harbormastar or
buildkite this adds a simple proxy that accepts url encoded form and
creates a request that buildkite expects. To avoid potential abuse,
nginx asks for simple http auth credentials stored in harbormaster.
All build parameters passed by proxy are put into build metadata and as
ph_* env variables available during the build.
Secrets involved:
- harbormastert knows http-auth to proxy (stored in privatly and in k8
buildkite/http-auth as auth file);
- proxy knows buildkite api token (mine atm);
- build agent knows conduit API token (mine atm),
and SSH key of llvm-premerge-tests-bot (in k8 buildkite/github-ssh).
Sample build: https://reviews.llvm.org/harbormaster/build/64828/8/https://buildkite.com/llvm-project/premerge/builds/48
