I noticed that most/all Jenkins jobs publish to Develocity for any call to a gradle command. IMO that doesn't make sense; the principal value of Develocity is monitoring historical *test* performance. Publishing non-test gradle invocations to Develocity publishes distracting noise that needs to be filtered out when browsing Develocity.
Develocity can also be used to improve build performance generally but I think we'll just want to monitor such in the context of a build with tests. Additionally, there's a great IntelliJ Develocity plugin to do such analysis locally. https://gradle.com/blog/develocity-intellij-plugin-speed-up-gradle-builds-insights/ As a start, I simply disabled the develocity environment variable from the "smoketester" jobs. If that does the trick, and doesn't produce errors, I'll use the same technique for most of the other jobs. BTW "smoketester" has "test" in the name but it's purpose is ad-hoc checks run from a python script; not really standard tests. Develocity doesn't know what the smoketester.py script does; it only knows what gradle tasks do, with greater insights to JUnit tests in particular. Our "integration tests" (BATS) and "docker tests", which are both invoked via Gradle, both run special/non-JUnit tests, are NOT showing value in Develocity, unfortunately: https://develocity.apache.org/s/te2kp2svgfcui/tests/overview (gradle integrationTests) https://develocity.apache.org/s/tze5igco2h6he/tests/overview (gradle dockerTest) If someone wants to figure out how that could be resolved for the BATS side, that'd be great, because we'll likely eventually use the same infra to cover the Docker side likewise. Probably need to generate standardized JUnit style XML reports that Develocity probably consumes. Maybe Develocity has documentation on the requirements. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
