zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zoltán Nagy <>
Subject Infrastructure setup / CI
Date Tue, 04 Sep 2018 08:35:31 GMT
Hey folks,

So great to send a mail to a list whose address includes both Zipkin and
Apache :)
Watch out, wall of text incoming. There's a lot of context here.

After reading the previous mail threads (still before the list), and some
discussion with Andrew (whom Adrian introduced, and was a great help, are
you here, Andrew?), I'm starting to have an outline of infrastructure-y
things that need to happen.

Most of these are pretty straightforward, and I'll try to capture existing
stated preferences – do shout if I'm telling a lie.

   - *Git repository hosting*. OpenZipkin people AFAIK would prefer staying
   on GitHub if at all possible. This would imply setting up syncing to ASF
   git hosting. seems to be a solution to this
   whole can of worms, though I didn't look too deeply yet.
   - Release automation may need to be extended for the required *voting
   process* – or maybe just leave it up to human process, don't change the
   - We'll need to set up *automated notification e-mails* about commits,
   releases, that kind of stuff. For commits, it should come out of the box
   with the Git setup, and should be easy to add to the release automation.
   This is probably best done with a separate notifications@ list.

Now for the hard part: *CI*. Travis seems to be supported by ASF, but
CircleCI is not, and various OpenZipkin projects currently use one, the
other, or even both. ASF apparently also has a hosted Jenkins server (which
I can't find ATM).

*A question to mentors*: what other CI options are available under the ASF
umbrella? Links to the various solutions or documentation for them would be
especially appreciated, so we can evaluate them properly.

*A question to OpenZipkin folks*: what's your current take on our CI setup?
Here too, let me share the perspectives I've heard so far, call out any
mistakes I make:

   - Travis sometimes has stability problems (more often than “rarely”, but
   more rarely than “often”, and more often than Circle)
   - Circle is somewhat more featureful and stable, but is severely limited
   in the number of free executors (and again, is not currently ASF-approved)
   - The less we need to care about CI, the better – that includes ongoing
   maintenance, mental / process overhead when making changes, and cost of any
   - This one's mostly from me: there's a lot of duplication between the
   build definitions of our various projects, not to mention the overhead of
   “supporting” both Travis and Circle. For example, I know Jenkins has
   standard tools to deduplicate parts of build definitions (namely, shared
   libraries for pipelines); I don't know of similar solutions for Travis (and
   am happy to be pointed at some / do more research).

I'd say using a single CI system is more of a “when”, rather than a
“whether” type of question. It then boils down to a trade-off between the
cost of migration, and the perceived value of the new system. Some possible

   - We decide to minimize the cost of migration, and move Circle builds to
   Travis. Later on, we might look into deduplicating build logic between jobs.
   - We push for ASF to accept CircleCI (note, with no guarantee of success
   at this point), including funding for more executors if needed (or try to
   start a collaboration with Circle so that ASF projects get more executors),
   and migrate Travis jobs to Circle.
   - We decide to maximize perceived value, by choosing a third option
   (non-Travis, non-Circle) that helps DRY our build definitions, while also
   keeping it easy to make per-project changes as needed. I'd recommend
   leading a project like this with a PoC and evaluating the results there,
   before migrating all N>10 projects and pouring effort into finalizing the
   shared abstraction layer.

EOF wall of text. To recap, I'm super interested in what other CI options
are available under ASF (so that we know what to even think about), any
other recommendations our beloved mentors might have given all this, and
preferences / arguments / corrections from Zipkin folks.


Zoltán Nagy

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message