Okay. So that information is definitely coming from the GemFireVersion.properties file, which explains this issue. Either reverting the previous GEODE-5600 changes or resolving merge conflicts from PR 2457 would address this issue.
My concern remains about the .buildinfo file, however. Is the .buildinfo redundant at this point and should be? Should it always contain the necessary information, with the GemFireVersion.properties file acquiring the source information from .buildinfo rather than fetching it again itself? Is .buildinfo a convention in distributions with which I am just myself unfamiliar? The path we take here is fundamentally linked to how we want to approach GEODE-5600, and with PR 2457 currently open, we could choose any of these routes to go. On Wed, Sep 12, 2018 at 4:13 PM, Nabarun Nag <n...@apache.org> wrote: > @patrick > if you build geode release branch 1.7.0 "./gradlew clean build > -Dskip.tests=true -xdocs -xjavadoc" and start gfsh from > geode-assembly/build/install/apache-geode/bin/gfsh > And then type `version --full` you get this > > gfsh>version --full > Build-Date: 2018-09-12 16:07:03 -0700 > Build-Id: nnag 0 > Build-Java-Version: 1.8.0_181 > Build-Platform: Mac OS X 10.13.6 x86_64 > Product-Name: Apache Geode > Product-Version: 1.7.0 > Source-Date: 2018-09-12 16:07:03 -0700 > *Source-Repository: unknown* > *Source-Revision: unknown* > Native version: native code unavailable > Running on: /10.118.19.23, 8 cpu(s), x86_64 Mac OS X 10.13.6 > > As you can notice that Source-Repository and Source-Revision is missing. It > should contain the info from the buildinfo file present in > geode-assemble/.buildinfo file. It contains the following > > # > #Wed Sep 12 16:07:56 PDT 2018 > Source-Date=2018-09-11 15\:56\:48 -0700 > Source-Revision=c637193aa61abdfd236ae36b6d9a228fc1e84bcd > Source-Repository=release/1.7.0 > > Hope this helps > > Regards > Nabarun Nag > > On Wed, Sep 12, 2018 at 3:51 PM Patrick Rhomberg <prhomb...@pivotal.io> > wrote: > > > I'm happy to work on those reverts, although if Anthony could elaborate > on > > where exactly the version information was missing, that assuage some of > my > > own worries as to whether it's the right approach. It's still not clear > to > > me where .buildinfo is intended to be consumed. > > > > On Wed, Sep 12, 2018 at 3:08 PM, Nabarun Nag <n...@apache.org> wrote: > > > > > Yes Alexander, we are still waiting on the build info reverts from > > Patrick, > > > so, I think that this can be put into release/1.7.0. > > > > > > Sure Jinmei, you can go ahead and merge the change into release/1.7.0 > > > branch too when you merge the PR. Please do close the fixed version in > > the > > > JIRA as 1.7.0 > > > > > > Regards > > > Nabarun Nag > > > > > > > > > On Wed, Sep 12, 2018 at 2:50 PM Alexander Murmann <amurm...@pivotal.io > > > > > wrote: > > > > > > > While there is a workaround this looks like a highly visible bug > with a > > > > fairly safe fix. I am in favor of merging, since the branch is still > > > > distressed anyways. > > > > > > > > Other opinions? > > > > > > > > On Wed, Sep 12, 2018 at 2:29 PM, Jinmei Liao <jil...@pivotal.io> > > wrote: > > > > > > > > > Should we include the fix for GEODE-5727 in the 1.7 release as > well? > > > > > > > > > > Without the fix, the command "export cluster-config > > > > --zip-file-name=x.zip" > > > > > would fail with NPE, user has to use "export cluster-config > > > > > --zip-file-name=./x.zip" in order for export to work. > > > > > > > > > > PR for this fix is ready and could be merged soon. > > > > > > > > > > Jinmei > > > > > > > > > > > > > > > On Wed, Sep 12, 2018 at 11:12 AM Patrick Rhomberg < > > > prhomb...@apache.org> > > > > > wrote: > > > > > > > > > > > I'm not sure PR 2457 will help with an ignored .buildinfo, but > I'm > > > not > > > > > sure > > > > > > as to why .buildinfo would be getting ignored by anything, > either. > > > > > > > > > > > > PR 2457 deals with the still-needs-to-be-renamed > > > > > GemFireVersion.properties > > > > > > file and when it is generated. Previously, it was whenever the > git > > > > index > > > > > > changed, which was too frequent. Not it is whenever the source > > > > > parameters > > > > > > are passed on the command-line with the build, which has > presented > > > > issues > > > > > > outside the Concourse pipeline. PR 2457 splits the difference, > > > > > > regenerating the file anytime the SHA changes. > > > > > > > > > > > > The only interaction with .buildinfo that I can see is that if > the > > > > build > > > > > > was run on a machine that was missing git, it would attempt to > read > > > > > values > > > > > > instead from .buildinfo when creating the > GemFireVersion.properties > > > > file. > > > > > > > > > > > > I guess I don't fully understand the problem Anthony has called > > out. > > > > > Where > > > > > > is it exactly that information previously gathered from > .buildinfo > > is > > > > now > > > > > > missing? And are we certain that it was indeed pulling from > > > .buildinfo > > > > > and > > > > > > not the aforementioned GemFireVersion.properties? > > > > > > > > > > > > On Wed, Sep 12, 2018 at 10:11 AM, Alexander Murmann < > > > > amurm...@pivotal.io > > > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > It seems like that PR doesn't address the missing SHA issue > > either > > > > and > > > > > I > > > > > > am > > > > > > > not aware of any proposals to properly fix this. How viable is > it > > > to > > > > > > revert > > > > > > > the relevant Gradle build changes on support/1.7? > > > > > > > We could continue make the new Gradle approach work with our > > > release > > > > > > > process on develop and hopefully release 1.8 with these > changes. > > > > > > > > > > > > > > Are there any other proposals to unblock this? > > > > > > > > > > > > > > On Tue, Sep 11, 2018 at 5:41 PM, Anthony Baker < > > aba...@pivotal.io> > > > > > > wrote: > > > > > > > > > > > > > > > Slight clarification—the issue I mentioned is when a user > > builds > > > > > Geode > > > > > > > > from the source distribution. The source distribution that > the > > > > > release > > > > > > > > manager creates has the correct .buildinfo file, it’s just > > > ignored > > > > by > > > > > > the > > > > > > > > build. In short, the release manager can’t work around the > > > > problem. > > > > > > > > > > > > > > > > Does [1] help with this? > > > > > > > > > > > > > > > > Anthony > > > > > > > > > > > > > > > > [1] https://github.com/apache/geode/pull/2457 < > > > > > > > https://github.com/apache/ > > > > > > > > geode/pull/2457> > > > > > > > > > > > > > > > > > > > > > > > > > On Sep 11, 2018, at 3:16 PM, Alexander Murmann < > > > > > amurm...@pivotal.io> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > What's the consensus on the version info issue Anthony is > > > calling > > > > > > out? > > > > > > > > Does > > > > > > > > > anyone have a proposal for fixing this for this release? > > Should > > > > > > Nabarun > > > > > > > > as > > > > > > > > > the release manager manually correct this for the release > and > > > we > > > > > > find a > > > > > > > > > permanent solution for 1.8? > > > > > > > > > > > > > > > > > > On Mon, Sep 10, 2018 at 12:33 PM, Anthony Baker < > > > > aba...@pivotal.io > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > >> Unfortunately it would require a fix to the build—it’s not > > > about > > > > > > > > producing > > > > > > > > >> the release candidate. It’s when a user builds from the > > source > > > > > > release > > > > > > > > that > > > > > > > > >> the version info is ignored. > > > > > > > > >> > > > > > > > > >> Anthony > > > > > > > > >> > > > > > > > > >>> On Sep 10, 2018, at 10:02 AM, Nabarun Nag < > n...@apache.org > > > > > > > > wrote: > > > > > > > > >>> > > > > > > > > >>> Hello Anthony, > > > > > > > > >>> > > > > > > > > >>> I plan to do that while creating the release candidate. > If > > > > there > > > > > > are > > > > > > > no > > > > > > > > >>> concerns raised on the release branch, I will start with > > the > > > > > > process > > > > > > > > >> soon. > > > > > > > > >>> > > > > > > > > >>> Regards > > > > > > > > >>> Nabarun Nag > > > > > > > > >>> > > > > > > > > >>>> On Mon, Sep 10, 2018 at 8:51 AM Anthony Baker < > > > > > aba...@pivotal.io> > > > > > > > > >> wrote: > > > > > > > > >>>> > > > > > > > > >>>> Looks good Naba! Only thing I see right now is that > > > building > > > > > from > > > > > > > the > > > > > > > > >>>> source distribution does not use the .buildinfo file, > > > leaving > > > > > the > > > > > > > > >> version > > > > > > > > >>>> string empty. > > > > > > > > >>>> > > > > > > > > >>>> Anthony > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>> On Sep 7, 2018, at 9:15 AM, Nabarun Nag < > n...@apache.org > > > > > > > > wrote: > > > > > > > > >>>>> > > > > > > > > >>>>> CORRECTION: if '*no*' concerns are raised, we will > start > > > with > > > > > the > > > > > > > > >> voting > > > > > > > > >>>>> for the release candidate soon. > > > > > > > > >>>>> > > > > > > > > >>>>> Regrads > > > > > > > > >>>>> Nabarun Nag > > > > > > > > >>>>> > > > > > > > > >>>>>> On Fri, Sep 7, 2018 at 9:08 AM Nabarun Nag < > > > n...@pivotal.io > > > > > > > > > > > > wrote: > > > > > > > > >>>>>> > > > > > > > > >>>>>> Hello Geode Dev Community, > > > > > > > > >>>>>> > > > > > > > > >>>>>> We have created a new release branch for Apache Geode > > > 1.7.0 > > > > - > > > > > > > > >>>>>> "release/1.7.0" > > > > > > > > >>>>>> > > > > > > > > >>>>>> Previous branch was deleted and has been replaced > with a > > > > fresh > > > > > > > one. > > > > > > > > >>>>>> > > > > > > > > >>>>>> Please do review and raise any concern with the > release > > > > > branch. > > > > > > > > >>>>>> > > > > > > > > >>>>>> If concerns are raised, we will start with the voting > > for > > > > the > > > > > > > > release > > > > > > > > >>>>>> candidate soon. > > > > > > > > >>>>>> > > > > > > > > >>>>>> Regards > > > > > > > > >>>>>> Nabarun Nag > > > > > > > > >>>>>> > > > > > > > > >>>> > > > > > > > > >>>> -- > > > > > > > > >>> Regards > > > > > > > > >>> Nabarun Nag > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Cheers > > > > > > > > > > Jinmei > > > > > > > > > > > > -- > > > Regards > > > Nabarun Nag > > > > > > -- > Regards > Nabarun Nag >
