I’m Carmine, a researcher at the University of Zurich and I am interested in supporting developers working with continuous integration (CI). I created a reporting tool that analyzes the CI logs of a project to identify deviations from accepted CI best practices.
For example, are you aware that your last changes on the branch “Fix_S1312” happened 21 weeks ago, and have not been merged yet? In your project, you typically merge branches within 6 weeks.
Or, do you know that (on average) it takes you 2 hours to fix a build failure on the master branch?
You will find this and other interesting statistics about the CI practices in your project at https://carminevassallo.github.io/detectorsIcons/summarizer-output/SonarSource_sonar-java/SonarSource_sonar-java.html
Thanks for reaching out. I had a look at the report for our project. A lot of it is simply nonsensical, or irrelevant.
More precisely, the “late merging” analysis seems to be completely missing the target. All of the branches cited are been handled for quite a long time already, are not existing anymore, or are simply unknown… Not having links to your sources/pr/commit/branch is useless at this stage. On top of that, details are redundant or badly built.
For the CI failures, we monitor them all the time, and so they are fixed at failure time (which is quite rare).
Travis CI build time is fluctuating too much to be reliable as valuable source of “expected build time”. Averaging per week is nice… but give at least the value which have been used for such computation.
Thanks for reaching out. I had a look at the report for our project. A lot of it is simply nonsensical, or irrelevant.
Hi Michael,
first, thanks for replying!
More precisely, the “late merging” analysis seems to be completely missing the target. All of the branches cited are been handled for quite a long time already, are not existing anymore, or are simply unknown… Not having links to your sources/pr/commit/branch is useless at this stage. On top of that, details are redundant or badly built.
You’re obviously right. For now we are mainly considering information available on TravisCI…so we should definitely consider the repo at least for deleted branches.
For the CI failures, we monitor them all the time, and so they are fixed at failure time (which is quite rare).
Indeed, our report says that you are quite fast in solving them…
Travis CI build time is fluctuating too much to be reliable as valuable source of “expected build time”. Averaging per week is nice… but give at least the value which have been used for such computation.
We are aware about such issues connected with a use a free version of TravisCI. We tried to mitigate them reporting only the cases where the trend becomes worrisome (we perform statistical operations).
Thank you Carmine for sharing this report. On my side I found the report to be interesting (but of course not perfect!). Build times is indeed a very critical aspect of being able to effectively work on a project, as is broken CI, skipped tests and late merging. I’ve just answered your survey.
Yes, please consider that this is a prototype. So my main goal is to have feedback on the idea and obviously the suggestions given by @Michael regarding Late Merging can only improve the accuracy of our detection!
