How do you retrieve git metadata when building from a source distribution (not a repo)? That is why .buildinfo exists *in the source distribution*.
Anthony > On Sep 12, 2018, at 4:30 PM, Patrick Rhomberg <prhomb...@pivotal.io> wrote: > > 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 >>
