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