zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zoltán Nagy <abes...@gmail.com>
Subject Re: Infrastructure setup / CI
Date Fri, 07 Sep 2018 08:47:15 GMT
Thank you for the detailed response, Mick! This really helps me get a
better picture of where we're going.

I'm happy to watch the Git repo and website migration from the sidelines,
or help out as needed. I'm following the conversation on the mail thread
you started for that topic.

Re. releases: do you think it's necessary to gate the current “release”
automation behind code that somehow enforces community verification? And
perhaps more importantly: current “releases” (let's start calling them
nightlies then) are uploaded to Bintray and Maven Central as stable
versions, and Docker images are built with them. This shouldn't happen to
things called nightly builds :) It would be super confusing to Zipkin users
– is this then a stable release they can use, or not? If not, why is it on
Maven Central or DockerHub? Or maybe you're saying the “nightly”
distinction would be ASF-internal only? But in that case, wouldn't we be
misrepresenting how “trusted” each version is? There'd be no way to tell
from a look at a Docker image whether that's a release or a nightly.
Unless, of course, we figure out ways to differentiate these versions
clearly.

Another option might be slowing down the release cadence – keep the current
automation and release channels, just update them less frequently. We also
publish `SNAPSHOT` versions of most (all?) Maven artifacts (though I don't
think we build Docker images for them), so there's at least a somewhat
convenient way for users who need the latest changes to get them. What we
miss there is a lightweight way of saying “this version is prooobably good
enough to run, but not a proper release”, which may or may not be an issue.

Re. CI: it appears there's consensus in keeping the CI systems we have
today. Mick, just to make sure I understand 100%, are you saying ASF
projects can also use CircleCI? That's new information to me; if that's the
case, then I'm super happy :)

Cheers!

On Fri, Sep 7, 2018 at 8:23 AM Mick Semb Wever <mck@apache.org> wrote:

> Hi Zoltán,
>  I'll do my best to answer your questions, inline.
>
>
> >    - *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. https://gitbox.apache.org/ seems to be a solution to
> this
> >    whole can of worms, though I didn't look too deeply yet.
>
>
> ASF hosts git repositories in two different ways:
>  - gitbox
>  - asf git repositories
>
> The latter are only sync'd to github, ie you can't push to the github repo.
> An example of this is Cassandra.
>
> Gitbox maintains two repositories in sync, and you can push to either. One
> exists at ASF, the other at GitHub under the apache organisation.
> For example:
>  - https://gitbox.apache.org/repos/asf?p=incubator-skywalking.git
>  - https://github.com/apache/incubator-skywalking
>
> Zipkin will want the GitBox approach. And the proposal implies this under
> > "Required Resources ––> Git Repositories"
>
> This means that Zipkin's existing github repositories will need to be
> moved to
> https://github.com/apache/
> and with repository names that are prefixed with "incubator-"
>
> See SkyWalking's equivalent ticket: SkyWalking:
> https://issues.apache.org/jira/browse/INFRA-15649
>
> More info at https://reference.apache.org/committer/github
>
>
>
>
> >    - 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
> >    automation.
>
>
> First up, there's a terminology mismatch on what "release" means to Zipkin
> and what it means to the ASF.
>
> Zipkin's releases are frequent and automatic. The are not what ASF means
> as releases. A closer concept would be nightly builds.
>
> ASF releases are more formal releases. These are carefully constructed and
> tested cut releases, that provide the community a few days to test, and
> then a few days to vote upon. All legalities (digest, gpg signatures, etc)
> are sound, etc etc.
>
> The Apache Incubator expects to the community make such formal releases,
> but like once a month or so, not anywhere near the current Zipkin release
> cycle.
>
> As far as I've understood from conversations with Adrian, the best
> approach forward we presume is to make Zipkin's current releases into
> something more akin to nightly builds (and stop referring to them as
> releases), and to every now and again when there's a build that the
> community deems should be announced formally to the world go through the
> formal ASF release process.
>
>
> >    - 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.
>
> I believe that all happens automatically.
> If not, make a request to INFRA (by opening an INFRA jira ticket).
>
>
> > 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).
>
> The ASF provides a dedicated CI at builds.apache.org
> This is jenkins.
>
> Whether you want to use this or not is optional.
> We're free to use CircleCI or Travis.
>
> My opinion is the more the merrier. As Adrian mentions some of these can
> be flakey at times, so there's an advantage to using multiple despite the
> cost.
>
> The ASF builds.apache.org can be really useful for longer running
> integration tests.
>
> regards,
> Mick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> For additional commands, e-mail: dev-help@zipkin.apache.org
>
>

-- 
Zoltán Nagy
https://abesto.net

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