zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <adrian.f.c...@gmail.com>
Subject Re: [VOTE] Release Apache Zipkin Brave Karaf (incubating) version 0.1.2
Date Sun, 10 Feb 2019 12:13:18 GMT
FWIW the build worked on my laptop. it might be an environment nuance.
Karaf itests are sensitive, and so for example end users shouldn't
require anything delicate. For example, would you fail a build because
a user can't install docker that's a prereq? We are only vetting code
I think we should step back from signing ourselves up to make every
potential user able to run all the myriad of integration tests
possible in our environments.

On Sun, Feb 10, 2019 at 1:09 PM Zoltán Nagy <abesto@apache.org> wrote:
>
> > however if there is something in the zip it should work.
>
> Agree. I pretended to be a user with relatively little knowledge about the
> internals here - with that hat on, I don't mind whether it's the itests or
> whatever else that's failing, all I know is that `./mvnw package` should
> give me something I can deploy.
>
> > I will lightly look into how much logic we need in
> > general to strip itests out completely.
>
> Weak opinion: I like that tests are shipped with the release, so that (if I
> use the source release) there's a last line of defense against badness. Not
> to mention, this way tests are also run in an environment that's closer to
> my production. Still, this is mostly academical - I expect 99% of our users
> to use the binary convenience artifacts, so the point is somewhat moot.
>
> > on a related note, it could be helpful to have Jenkins check our release
> > tags
>
> That should be simple enough to add, since in pipelines we can say stuff
> like "when { tag "release-*" }" where the wildcard is an Ant-style
> wildcard. At the same time: since tags for us are always on master, I
> mostly expect this to add no additional value, since we already run tests
> on master pushes. Since tests on CI passed on the commit you tagged for the
> release, I expect the error to be somehow introduced by the packaging
> process. In that case we'd want to run tests against the RC source
> artifacts - this also shouldn't be too hard to add, but would probably be
> best to set up as a job that's manually triggered against a specific zip
> once it's uploaded (consider: we can automatically trigger on tags, but
> more likely than not, the release at that point hasn't been uploaded to the
> ASF dev repo yet). At that point this is "just" a convenience / extra
> safety net, since voting PMC members will do this check locally anyway.
>
> On Sun, Feb 10, 2019 at 10:38 AM Adrian Cole <adrian.f.cole@gmail.com>
> wrote:
>
> > thanks zoltan. we dont deploy the itests so probably dont generally need to
> > validate them for ASF reasons. however if there is something in the zip it
> > should work. I will look into this to see if it is failing because it
> > should fail or not. also I will lightly look into how much logic we need in
> > general to strip itests out completely.
> >
> > on a related note, it could be helpful to have Jenkins check our release
> > tags (mvnw install not deploy) so that we know the actual code still works
> > (vs a distribution of it)
> >
> > On Sun, Feb 10, 2019, 5:20 PM Zoltán Nagy <abesto@apache.org wrote:
> >
> > > Confirming we're now in a better state:
> > >
> > > * GPG signature and SHA512 of the artifact check out. I expected to also
> > > see a signature for the checksum, but
> > > https://www.apache.org/dev/release-distribution doesn't mention that,
> > so I
> > > think we're fine.
> > > * Confirming base dir is now non-confusing :)
> > > * Code in release matches code at commit 4c28076fd
> > > * `./mvnw compile` succeeds (note: the license checker Maven plugin
> > > complains for about a screenful about failing to find the latest git
> > > commit, but this doesn't fail the build)
> > >
> > > However, I'm still -1:
> > >
> > > * `./mvnw package` fails both on my macOS and Windows Linux Subsystem
> > > environments: io.zipkin.brave.itests.BraveTest fails with
> > > java.lang.ClassNotFoundException for zipkin2.reporter.Sender. Gist of
> > > relevant Maven output:
> > > https://gist.github.com/abesto/632f7e7e515de2adb9b3ba04d7606659
> > >
> > > On Sun, Feb 10, 2019 at 4:10 AM Adrian Cole <adrian.f.cole@gmail.com>
> > > wrote:
> > >
> > > > sorry I forgot to mention that GPG asc files weren't there because I
> > > > used the old "release" profile not the "apache-release" one. I've
> > > > removed the old profile to remove confusion as it is no longer used
> > > > anyway
> > > >
> > > > On Sun, Feb 10, 2019 at 5:08 AM Adrian Cole <adrian.f.cole@gmail.com>
> > > > wrote:
> > > > >
> > > > > OK all should be resolved now. The new git hash is
> > > > > 4c28076fd617f4896cae77e773de7090bcebe6b4
> > > > >
> > > > > All other locations etc should be the same. Here is a summary of
> > > > glitches fixed:
> > > > >
> > > > > * zip wasn't named correctly I formerly manually fixed it. Now that's
> > > > automatic
> > > > > * zip basedir wasn't intuitive. it is now brave-karaf-$version
> > > > > * we accidentally published itests, now we don't
> > > > > * dummy release notes didn't explain this was only a canary release
> > > > >
> > > > > There was no code change only build script stuff.
> > > > >
> > > > > -A
> > > > >
> > > > > On Sat, Feb 9, 2019 at 10:38 PM Jorge Quilcate <
> > > quilcate.jorge@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > On 2/9/19 2:30 PM, Adrian Cole wrote:
> > > > > > > agreed the release notes link is empty. I didn't go through
the
> > > > formality
> > > > > > > of making release notes for 0.1.2
> > > > > > >
> > > > > > > On Sat, Feb 9, 2019, 9:19 PM Brian Devins-Suresh <
> > > badevins@gmail.com
> > > > wrote:
> > > > > > >
> > > > > > >> +1
> > > > > > >>
> > > > > > >> Are release votes not supposed to include some synopsis
of the
> > > > changes? I
> > > > > > >> know this is a first release within the incubator but
it might
> > be
> > > > good to
> > > > > > >> just call that out?
> > > > > > >>
> > > > > > >> On Sat, Feb 9, 2019 at 6:41 AM José Carlos Chávez
<
> > > > jcchavezs@gmail.com>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >>> +1
> > > > > > >>>
> > > > > > >>> Den lør. 9. feb. 2019, 11:36 skrev Adrian Cole
<
> > > > adrian.f.cole@gmail.com:
> > > > > > >>>
> > > > > > >>>>> I can't find the GPG signature for the
artifact and the
> > > > checksum. I'm
> > > > > > >>>>> looking at
> > > > > > >>>>>
> > > > > > >>
> > > >
> > >
> > https://dist.apache.org/repos/dist/dev/incubator/zipkin/brave-karaf/0.1.2/
> > > > > > >>>>> ,
> > > > > > >>>>> and am expecting to see two .asc files,
and am not seeing
> > any.
> > > > Am I
> > > > > > >>>> looking
> > > > > > >>>>> in the wrong place?
> > > > > > >>>>>
> > > > > > >>>> no that is the right place. I must have missed
something. the
> > > > stuff
> > > > > > >> asked
> > > > > > >>>> me for my GPG password so something must have
gotten lost.
> > will
> > > > report
> > > > > > >>>> back.
> > > > > > >>>>
> > > > > > >>>> The folder contained in the source zip is called
> > > > > > >>>>> "brave-karaf-parent-0.1.2". I'd expect
it to be just
> > > > > > >>> "brave-karaf-0.1.2".
> > > > > > >>>>> (Quite possible I'm just missing some Java
ecosystem
> > knowledge
> > > > and
> > > > > > >> this
> > > > > > >>>> is
> > > > > > >>>>> fine).
> > > > > > >>>> I think this is also valid. Let me look into
customizing the
> > > > artifact
> > > > > > >>>> basedir. It is inheriting this from the aggregator
(base
> > > pom.xml)
> > > > which
> > > > > > >>> we
> > > > > > >>>> intentionally name different as often the actual
lib is called
> > > > > > >> something
> > > > > > >>>> like brave-karaf
> > > > > > >>>>
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> > > > > > For additional commands, e-mail: dev-help@zipkin.apache.org
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> > > > For additional commands, e-mail: dev-help@zipkin.apache.org
> > > >
> > > >
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
For additional commands, e-mail: dev-help@zipkin.apache.org


Mime
View raw message