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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 <[email protected] 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 <[email protected] > > > > > > 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 < > [email protected]> > > > > > 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 < > > > > [email protected]> > > > > > 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 < > > > > [email protected] > > > > > 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 < > > > > > [email protected]> > > > > > > > >> wrote: > > > > > > > >> > > > > > > > >>> +1 > > > > > > > >>> > > > > > > > >>> Den lør. 9. feb. 2019, 11:36 skrev Adrian Cole < > > > > > [email protected]: > > > > > > > >>> > > > > > > > >>>>> 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: [email protected] > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
