cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: Adding git commit ids to our packaging...
Date Fri, 12 Jul 2013 17:28:51 GMT
I think it should be in both.  In fact, I am hoping to push them further down.

Before our switch to git, the build number, which with svn included the revision as the last
octet, was pushed to every script, javascript, jar, and war.  I like to see that back again.
 It's very useful when trying to figure out exactly what was deployed.  I will work toward
that if there's no objections.  

I pushed in the changes to war file for now so QAs at least have some way to find the revision
number to communicate in Jira.

--Alex

> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Friday, July 12, 2013 6:53 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Adding git commit ids to our packaging...
> 
> On Fri, Jul 12, 2013 at 09:48:12AM -0400, David Nalley wrote:
> > On Thu, Jul 11, 2013 at 11:05 PM, Alex Huang <Alex.Huang@citrix.com>
> wrote:
> > > Will work on making it nicer but do we want to put this information into
> release?  Is there any harm to have this in the release build?  I can't think of
> any off-hand.  If we don't want them, we can change build_asf.sh to  set
> those two variables to something nicer.  If we want them, I might be able to
> get it to read this information from a file instead.
> > >
> > > --Alex
> > >
> >
> > Thanks for putting the work in to get this done.
> > I agree - no harm in having this in the release build, and could be
> > very useful to boot.
> > I personally would like to see this information, present - setting it
> > at tarball creation makes sense to me.
> >
> > --David
> >
> 
> +1
> 
> The only reason it was removed previously was that it was breaking the build
> process when someone tried to build from the release tarball.  If we want to
> drop the details into the release archive before tar'ing, great!
> 
> The only other minor concern would be the release verification process will
> have to be updated to account for the fact that we'll have one file (or some
> lines) that are different between the actual tagged commit in the repo and
> what's in the tarball.  As far as I know, that's just a process change for us.
> Easy...
> 
> -chip

Mime
View raw message