I don't think I can help much since I don't use sha1 for revision prop.
For my case, I run buildnumber:create-metadata top level only
(<inherited>true</inherited>) to track SCM info per build and user
Jenkins env.BUILD_NUMBER for CD version
-Dan
On Wed, Nov 8, 2017 at 2:30 PM, Eric Benzacar <e...@benzacar.ca> wrote:
> Hi Guys,
>
> Sorry to reopen a 6 month old thread, but I'm trying to add some more
> smarts to my stuff, and am failing trying to figure out how to do this.
>
> I want to use the buildnumber-maven-plugin:create-metadata goal to
> generate the metadata build.properties file, which is a great addition to
> my artifacts. At the same time, I noticed that it contains some useful
> information that I would want to use in my version number - such as the
> sha1.
>
> But the problem is that I can't figure out how to consume the metadata for
> my version. Basically, I need to get maven to know the sha1 from my
> commit. But the metadata file won't be interpolated by maven. And if I
> use the buildnumber:create goal to get the sha1, I can configure it to be
> exported as a ${sha1} property. And from everything I've understood, the
> ONLY properties understood by maven for the <version> tag are ${revision}
> ${changelist} and ${sha1}.
>
> But when I actually run the build all the interpolated version numbers
> ignore the ${sha1} property as generated by the buildnumber-m-p, even
> though I bound the create to the validate phase.
>
> Although I am not extremely surprised by this, I was sincerely hoping there
> was some way to make this work. Is there any way at all to be able to
> leverage what the buildnumber-m-p generates as part of my <version>? Is
> the only option to pass the ${sha1} value on command line?
>
>
> A snippet of my pom:
>
> <project>
> <artifactId>test</artifactId>
> <groupId>org.project</groupId>
> <version>${revision}${sha1}${changelist}</version>
> <properties>
> <sha1></sha1>
> <revision>5.0.0</revision>
> <changelist></changelist>
> </properties>
>
> <!-- OMITTED FOR BREVITY -->
> <build>
> <plugins>
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>buildnumber-maven-plugin</artifactId>
> <version>1.4</version>
> <executions>
> <execution>
> <id>generate-sha1</id>
> <phase>validate</phase>
> <goals>
> <goal>create</goal>
> </goals>
> <configuration>
> <!-- specify the special property name for the commit id -->
> <buildNumberPropertyName>sha1</buildNumberPropertyName>
> <!-- prefix the commitId with a hyphen for the version -->
> <format>-{0}</format>
> <items>
> <item>scmVersion</item>
> </items>
> <shortRevisionLength>8</shortRevisionLength>
> </configuration>
> </execution>
> <execution>
> <id>generate-metadata</id>
> <phase>generate-resources</phase>
> <goals>
> <goal>create-metadata</goal>
> </goals>
> <configuration>
> <version>${revision}${sha1}${changelist}</version>
> <addOutputDirectoryToResources>true</addOutputDirectoryToResources>
> <attach>true</attach>
> <outputName>META-INF/build.properties</outputName>
> </configuration>
> </execution>
> </executions>
> <configuration>
> <revisionOnScmFailure>no.scm.config.in.pom</revisionOnScmFailure>
> <!--make it available for jar/war classpath resource -->
> </configuration>
> </plugin>
> <!-- OMITTED FOR BREVITY -->
> </plugins>
> </build>
> </project>
>
>
> Thanks!
>
> Eric
>
>
> On Thu, Jul 27, 2017 at 1:46 AM, Dan Tran <dant...@gmail.com> wrote:
>
> > Hi Eric
> >
> >
> > i am using the follow at top level parent
> >
> > <version>${revision}</version>
> >
> > <properties>
> > <revision>x.y.x-SNAPSHOT</revision>
> > </properties>
> >
> > In child pom
> >
> > <parent>
> > ...
> > <version>${revision}</version>
> > </parent>
> >
> >
> > At jenskins file
> >
> > I have a param releaseVersion by default it is empty
> >
> > if the releaseVersion is not empty, then pass
> > -Drevision-${params.releaseVersion} into maven build
> >
> >
> > This mean i have 3 modes
> >
> > - Default SNAPSHOT build
> > - User can pass in the release version
> > - Auto incremental release build where I update and commit jenkins
> file
> > to default release version to 'x.y.z-${BUILD_NUMBER}'.
> >
> >
> > I have team that will never use auto incremental release build, and they
> > will manually run the build with a release version of their choice ( mode
> > #2)
> >
> >
> > -Dan
> >
> >
> > On Wed, Jul 26, 2017 at 8:37 PM, Eric Benzacar <e...@benzacar.ca> wrote:
> >
> > > Dan,
> > >
> > > Thanks for the update. I'm at the state where I am trying to
> integrated
> > CD
> > > with a large multi-module maven project and trying to get this process
> > > running smoothly with Jenkins. For the moment, I'm ok to use a
> > > split-Continuous Deployment concept - similar to yours. ie: using
> > > SNAPSHOTs for development phase, and anything in a release branch
> becomes
> > > an release candidate. Meaning that any commits into the release/
> branch
> > > produce a potentially shippable version.
> > >
> > > But that means that I need poms with version numbers as moving targets
> > (ie:
> > > sometimes with SNAPSHOTs, sometimes without). Based on Karl Heinz
> > > Marbaise's suggestions, I am planning on building my poms as follows:
> > >
> > > parent pom:
> > >
> > > <groupId>com.benze</groupId>
> > > <artifactId>parent</artifactId>
> > > <version>${revision}${sha1}${changelist}</version>
> > > <packaging>pom</packaging>
> > >
> > > <properties>
> > > <revision>1.3.1</revision>
> > > <changelist>-SNAPSHOT</changelist>
> > > <sha1/>
> > > </properties>
> > >
> > >
> > > but in my child poms, I'm not sure how to refer to the parent:
> > >
> > > <artifactId>webapp</artifactId>
> > > <packaging>war</packaging>
> > > <parent>
> > > <groupId>com.benze</groupId>
> > > <artifactId>parent</artifactId>
> > > <version> ??????? </version>
> > > <relativePath>../superpom</relativePath>
> > > </parent>
> > >
> > >
> > >
> > > How do you refer to the parent pom with a constantly (non-defined)
> moving
> > > version? In the past, without using properties like this, I could use
> > the
> > > maven-versions-plugin to update the version numbers, but now I don't
> even
> > > see how I can do that. If the revision is defined at the command line
> in
> > > Jenkins (ie: -Drevision=4.5.0), how do I deal with the child poms? If
> > > memory serves, the child cannot use properties for the parent version
> > > number.
> > >
> > > How/where to do you specify your semantic version number? I remember
> you
> > > said you use the buildnumber-m-p for the build number, but that
> > > how/where/when do you specify the sematic version number? Do you have
> to
> > > manually change it in the poms at RC time? Is it only defined during
> the
> > > build process?
> > >
> > > Do you have an example of your pom structure and Jenkinsfile pipeline
> > that
> > > you can share to help me better grasp how to handle this integration?
> > >
> > > Thanks,
> > >
> > > Eric
> > >
> > >
> > >
> > > On Fri, Jun 2, 2017 at 5:34 AM, Dan Tran <dant...@gmail.com> wrote:
> > >
> > > > Just want to share our final outcomes
> > > >
> > > > 1. Use snapshot build during development phase
> > > >
> > > > 2. At release candidate phase, switch jenkinsfile to release mode
> > > >
> > > > * For small projects, use version less Maven continuous deliver
> > > > friendly,
> > > >
> > > > * For large projects, use versions-maven-plugin to change
> version
> > in
> > > > all poms at pre-build
> > > >
> > > > * Automate the process to tag the final RC (we deploy a
> > > > build.properties to maven repo at each build, use its info to tag the
> > > SCM)
> > > >
> > > > Whenever, the startup performance issue for large project is fixed,
> we
> > > will
> > > > switch to full version less build
> > > >
> > > > -Dan
> > > >
> > > > On Sun, May 14, 2017 at 7:23 PM, Dan Tran <dant...@gmail.com> wrote:
> > > >
> > > > > I also noticed it takes about a minute for the build to roll after
> > this
> > > > >
> > > > > [INFO] Error stacktraces are turned on.
> > > > > [INFO] Scanning for projects...
> > > > >
> > > > > This is not a good news for local dev build
> > > > >
> > > > > here are 2 time summaries running 250+ modules with skipTests and 4
> > > > thread
> > > > > smart builder. The first one does not use
> > > <version>${revision}</version>
> > > > >
> > > > > [INFO] ------------------------------
> > > ------------------------------
> > > > > ------------
> > > > > [INFO] Total time: 04:05 min (Wall Clock)
> > > > > [INFO] Finished at: 2017-05-14T19:16:32-07:00
> > > > > [INFO] Final Memory: 680M/2078M
> > > > >
> > > > > [INFO] ------------------------------
> > > ------------------------------
> > > > > ------------
> > > > > [INFO] Total time: 05:56 min (Wall Clock)
> > > > > [INFO] Finished at: 2017-05-14T19:11:00-07:00
> > > > > [INFO] Final Memory: 1726M/3561M
> > > > >
> > > > >
> > > > > -D
> > > > >
> > > >
> > >
> >
>
