zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommy Ludwig <tommy.ludwig.c...@gmail.com>
Subject Re: [VOTE] Release Apache Zipkin Brave Karaf (incubating) version 0.1.2
Date Sun, 10 Feb 2019 12:33:34 GMT
I think it is fine if the documented instructions contained in the source
release to build simply use a command that skips integration tests (e.g. if
failsafe is running them `-DskipITs` [0]). Running integration tests may
have some environment prereqs and it should be enough if we can run them as
part of CI.

[0]
https://maven.apache.org/surefire/maven-failsafe-plugin/examples/skipping-tests.html


On Sun, Feb 10, 2019 at 9:13 PM Adrian Cole <adrian.f.cole@gmail.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message