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 > > >> > > > > >
