> On 1 Dec 2015, at 00:03, Allen Wittenauer <a...@altiscale.com> wrote: > > >> On Nov 30, 2015, at 3:46 PM, Chris Nauroth <cnaur...@hortonworks.com> wrote: >> >> To be exhaustive, we'd also add the various -Drequire options for full >> inclusion of all optional native components. Unfortunately, that gets >> tricky because of the various build pre-requisites which would need to be >> present on the Jenkins hosts. This is where the Dockerfile is helpful, >> because it encapsulates all of that. Maybe this job would benefit from >> using the Dockerfile. >> > > > I’ve been noodling over the past few weeks about a tool called ‘qbt’ that > would basically manage builds like Yetus manages tests. It’d be able to use > the Yetus plug-ins to qualify the build, do reporting, etc. > > >
I've been doing some work again on some databricks-originating code to go through jenkins histories and ID flaky tests, including automated result publishing as a google doc. https://github.com/steveloughran/spark-test-failures/tree/stevel-version The original release was hard code to the spark jenkins and builds; I'm fixing my branch to work with ASF jenkins. Although the original design's publishing to google docs is cute, we could have some other reporters. Generating an HTML page would be ideal for jenkins itself. So jenkins could be used to run analytics workloads against other job histories
