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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 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:

 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.
 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.
 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).
 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.

 Are there more options? Which should we use?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20564#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs