[tor-bugs] #20564 [Metrics]: Add Jenkins configuration for running metrics-lib's unit tests and producing a .jar file

[Tor Bug Tracker & Wiki]

#20564: Add Jenkins configuration for running metrics-lib's unit tests and
producing a .jar file
-------------------------+---------------------
 Reporter:  karsten      |          Owner:
     Type:  enhancement  |         Status:  new
 Priority:  Medium       |      Milestone:
Component:  Metrics      |        Version:
 Severity:  Normal       |     Resolution:
 Keywords:               |  Actual Points:
Parent ID:               |         Points:
 Reviewer:               |        Sponsor:
-------------------------+---------------------

Comment (by karsten):

 Replying to [comment:2 iwakeh]:
 > Replying to [comment:1 karsten]:
 > > Replying to [ticket:20564 karsten]:
 > > > Just came to mind: we might have to package metrics-lib first,
 because Jenkins jobs cannot download anything from the network.
 > >
 > > weasel rightly suggests that we could have a separate job to build
 metrics-lib's .jar file and then share artifacts with the CollecTor job.
 >
 > The CollecTor build depends on an official release version of metrics-
 lib, not simply 'HEAD' of the master branch.
 >
 > Four options come to mind:

 Great list!  I could imagine us doing either of the approaches above, with
 only mild preferences for some of them.  Let's go through them:

 > 1. If there is no other (allowed) way to include an official metrics-lib
 jar, it could be part of CollecTor's git, after all descriptor-1.5.0.jar
 has only 189kB. This has the advantage that the jenkins job does exactly
 what is done during development and release.

 My only concern is that this doesn't scale well in terms of the Git
 repository growing and growing over time.  But it could be okay.

 > 2. With building metrics-lib from the release tag (which could be done
 as suggested in a separate jenkins job or  as part of the CollecTor job)
 we'd have to update the release tag version of the jenkins build when
 CollecTor switches to a new metrics-lib version.

 Right, this seems like it could produce extra work for the Jenkins admins
 every time we put out a new metrics-lib release.  We might want to avoid
 this.

 > 3. Create a metrics-lib jenkins job that builds '''all''' versions
 tagged as release (and automatically builds new release tags too) and
 provides these artifacts for all other Metrics' java builds (CollecTor,
 Onionoo, etc).

 We might even create a job that builds the last three versions of metrics-
 lib and all versions released in the past 12 months.  Or we just start
 with all versions and remember these idea in case the approach doesn't
 scale anymore.

 > 4. Well, we could introduce the metrics-lib sub-module again into the
 CollecTor project, but always set to the release tag instead of HEAD. This
 seems not that optimal to introduce something like this into the
 development setup; I think.

 Not too bad.  We should first check whether fetching a Git submodule
 counts as network access or not.

 > Are there more options? Which should we use?

 My preferred approaches are: 3, 1, 4, 2.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20564#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online