The current setup is configuring the "affected projects" as well
as their dependencies, and run `ninja all` followed by
`ninja check-all`.
This is quite a pessimization for leaf project which don't need to
build and run the tests for their dependencies.
For example a patch affecting only MLIR shouldn't need to build
and run LLVM and clang tests.
This patch changes this by running checks only for the affected
project. For example a patch touching `mlir` is affecting `mlir`
and `flang`. However `flang` depends on `clang`. So the list of
projects to configure is `mlir;flang;clang;llvm;`, but we want
to test only mlir and flang ; we'll run only `ninja check-mlir
check-flang`.
In practice in this example running `ninja all` builds 5658 targets
and `ninja check-all` after that adds 716 more targets. On the other
hands `ninja check-flang check-mlir` results in 3997 targets total.
Concretely the contract with premerge_checks.py is changed so that
the expected argument for the --projects flag is only the list of
affected project, dependencies are automatically added.
"git diff" handles text files encoded that is not valid UTF-8 (e.g
using ISO-8859-1) as text files and produces a diff of those (rather
saying "Binary files a/x and b/x differ").
This means that the diff output may contain such characters. Files
that did would cause clang_tidy_report.py do hit an UnicodeDecodeError
when reading the diff, including if it was on removed lines and
regardless if it was in the ignore file.
By specifying errors mode "replace" for decode() method the bytes
that are not a valid utf-8 encoding are replaced with the unicode
replacement question mark (U+FFFD). When parsing the diff
clang-tidy-diff is only looking at filenames and line numbers of the
diff, so this shouldn't be a problem if it doesn't get the exact same
byte sequence inside the actual change.
I created a new queue for the pre-merge checks so that they won't compete for resources
with the post-merge build already running. Obviously that creates some inefficiency, but is
a simple way to make sure neither build gets starved (in particular, we know that the
current setup of 4 agents running on a single 32-core VM is enough to handle the commit
traffic on the main branch whereas pre-merge testing volume is likely to be more
unpredictable.
libarcher tests (part of openmp) have been broken for the past few weeks, and nobody seems to care. As such, disable the openmp project. I hope this is the right place to do so.
That removes a wrong assumption that everything interesting is
located within first few pages. Should also reduce API load a bit (as we
will not load additional 5+ pages just in case.
Instead of a local database, this script now imports the data
into the shared postgres database. this way the data can be used
for other queries as well.
feel free to extend the data model if you
need additional columns.
This is a wild attempt to fix the pre-commit CI which has been failing
for a few hours. I think the authors of 1f2c851 are not available right
now, so I'm taking the freedom to try this out. I hope I'm not overstepping
any boundary.
using metadata tags set in #298 finds and cancels existing builds before
starting a new one.
One caveat is that no result is reported back to Phabricator for the
cancelled build. That should not be an issue in the normal usecase.
For #278
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.
That gives us a way to test e.g. pull requests by specifying
ph_scripts_refspec="pull/123/head"
Also keep "ph_" prefix to remove confusion we had between
"scripts_branch" and "ph_scripts_branch" before.
Update docs and moved "testing" sections up.
