[isabelle-dev] Uses of Jenkins at TUM
makarius at sketis.net
Mon May 15 14:14:34 CEST 2017
On 25/04/17 09:41, Mathias Fleury wrote:
>> What is good about it?
> (I don't remember enough of the previous system to compare it to Jenkins.)
Lets go back to some points on this thread, now that I have finished
more implementation work.
> * automatic testing (I have forgotten to add files a couple of times).
Forgetting to add files in a commit was one of the few cases where the
remote test actually had a benefit. The start of this thread was such an
incident, see Isabelle/006a274cdbc2.
Thinking once more about the problem, it is clear that the standard
"isabelle build" tool can do that check on the spot. See now:
date: Sun May 14 20:16:13 2017 +0200
files: src/Pure/General/mercurial.scala src/Pure/Tools/build.scala
implicitly check for unknown files (not part of a Mercurial repository);
src/Pure/General/mercurial.scala | 31 +++++++++++++++++++++++++++++++
src/Pure/Tools/build.scala | 15 +++++++++++++++
2 files changed, 46 insertions(+), 0 deletions(-)
> * timings
> It is useful to see how it evolves over time.
I actually made this myself in reminiscence of the old isatest
statistics, see also various mails in the vicinity of
In that discussion it also became clear that Jenkins lacks scalable test
data management: queries via its API are very slow. This ultimately
motivated the PostgreSQL database server that is now behind
http://isabelle.in.tum.de/devel/build_status/index.html (PostgreSQL is a
great product that does its job very well without much ado.)
To reintegrate the old data source, I have added a function to download
Jenkins logs into the same log directory as the other build_status
This replaces the former chart plotting directly from Jenkins, so Lars
can now dismantle https://ci.isabelle.systems/statistics (which still
says "Generated at Tue, 18 Apr 2017 00:02:04 GMT").
More information about the isabelle-dev