Robert,

I think you misunderstood my problem.  It isn't a problem of defining
different distributionManagement repos; like you said that is fairly easily
handled using properties or -D parameters.

It is more the question of what kind of plugin is required to run which
says:
- download all the artifacts that this multi-module project previously built
- deploy all the artifacts that were just downloaded

I cannot think of how to design/configure a project to accomplish something
like that.  I'm guessing I would have to create a profile which explicitly
declares each artifact produced by the multi-module project in order to do
a dependency:copy, and then similarly, use a build-helper:attach all the
artifacts that were just downloaded.  But that seems like a painful
solution.  Am hoping there is something easier?

Thanks,

Eric


On Wed, Feb 14, 2018 at 9:45 PM, Robert Patrick <robert.patr...@oracle.com>
wrote:

> Inline...
>
>
> -----Original Message-----
> From: Eric B [mailto:ebenza...@gmail.com]
> Sent: Wednesday, February 14, 2018 8:27 PM
> To: Maven Users List <users@maven.apache.org>
> Subject: Re: Looking for recommendations how to best use Maven in a
> muti-stage Pipeline build to only deploy at the end
>
> Hi Robert,
>
> Thanks for the suggestions.  To be honest, I never thought of using
> regular repositories as staging repos.  That being said, I do see a hiccup
> with the option that I'm not sure how to address.  In the case where a
> build is rejected during the pipelline stage, how do I delete it?  I
> haven't found a plugin that would allow me to delete a build from a repo.
> And with a multi-module project, there are many artifacts that would need
> to be rolled back.  I guess I could simply configure the repo to allow
> re-deployment of the same artifact to these "stage" repos, but if ever a
> deployment fails part way through, I end up with a repo in an unstable
> manner (ie: there is no way to ensure that all modules are promoted at the
> same time).
>
> [Robert] Typically, I would solve this problem by simply putting
> expiration dates on artifacts in the staging repositories.  I have never
> used Nexus but Artifactory allows you to limit artifacts in the repository
> by size, last time accessed, etc.  No need to keep artifacts in the
> "staging repositories" for more than say, one month, anyway since they were
> either good (and promoted all the way to the release repository) or bad
> (and are not interesting after they fail).
>
> All that being said, the last question would be how to retrieve and
> redeploy these artifacts from one repo to another?  Changing the
> distributionManagement settings is simple enough, but how would I instruct
> maven to download all the modules from a multi-module build and then deploy
> them?  I guess I could hack a profile in the parent pom where the different
> modules are defined with a dependency:copy-dependencies goal, but how do I
> ensure all artifacts that were just downloaded are then deployed to the
> next repo in the stage?  I would think the only way to do this would be
> writing my own custom plugin, unless you can think of some other mechanism
> to accomplish this?
>
> [Robert] Another way to do this is to use properties for the key values
> for the repository URLs in the <repositories> and <distributionManagement>
> sections of the POM.  You simply set a default value for the properties in
> the root POM (e.g., with appropriate values for the repositories used by
> the developers) and then override the property values with Maven
> command-line -Ds (or profiles) in the Jenkins build steps to handle pulling
> and promoting to the right places...
>
> Thanks,
>
> Eric
>
>
>
> On Wed, Feb 14, 2018 at 10:01 AM, Robert Patrick <
> robert.patr...@oracle.com>
> wrote:
>
> > While Nexus may not support "staging repositories", it certainly
> > supports more than one repository so why not just create one or more
> > repositories that serve as staging repositories.  For example,
> >
> > Pipeline Steps:
> > 1.) Trigger a build based on source check-in and push to stage1 repo
> > if build "succeeds"
> > 2.) Pull artifacts from stage1 repo, run stage 2 tests, and push to
> > stage2 repo if tests succeed.
> > 3.) Pull artifacts from stage2 repo, run stage 3 tests, and push to
> > stage3 repo if tests succeed.
> > 4.) Pull artifacts from stage3 repo, run UAT tests, and push to
> > release repo if tests succeed.
> >
> >
> >
> >
> > -----Original Message-----
> > From: Eric B [mailto:ebenza...@gmail.com]
> > Sent: Wednesday, February 14, 2018 8:30 AM
> > To: Maven Users List <users@maven.apache.org>
> > Subject: Looking for recommendations how to best use Maven in a
> > muti-stage Pipeline build to only deploy at the end
> >
> > I'm looking for recommendations for the best way to use Maven in a
> > multi-stage Jenkins pipeline build to deploy only at the end.  At the
> > moment, I'm using Sonatype Nexus 3.x, which means i don't have the
> benefit
> > of staging repos.   Consequently, I have to ensure that the only released
> > versions of my libraries/application are final - they've passed QA.
> > Additionally, the team wants to ensure that the version numbers are
> > always incremental and every version in the repo is a consumable
> > version (ie: I cannot deploy a version 1.2.3 which has not passed
> > QA/Acceptance Tests, and furthermore, I cannot deploy a 1.2.2 followed
> by a 1.2.4).
> >
> > What that requirement translates to is that I have to ensure that the
> > binary built is fully tested before promoting it to Nexus. (and that I
> > shouldn't be appending build numbers to the maven version number).
> >
> > In my mind, I would like to do something the following in a Pipeline
> build:
> >
> > stage('build') { steps { sh 'mvn clean install'} }
> >
> > stage('Confirm deploy to QA'){
> >
> > steps {
> >
> > checkpoint 'test server deployed'
> >
> > script {
> >
> > env.DEPLOY_TO_QA_TEST = input message: 'User input required',
> >
> > submitter: 'authenticated',
> >
> > parameters: [choice(name: 'Deploy to acceptance test server', choices:
> > 'no\nyes', description: 'Choose "yes" if you want to deploy the QA
> > test server')]
> >
> > }
> >
> > }
> >
> > }
> >
> > stage('deployQA') {
> >
> > when {
> >
> > environment name: 'DEPLOY_TO_QA_TEST', value: 'yes'
> >
> > }
> >
> > steps{
> >
> > /* deploy the build to a QA environment */  }
> >
> > }
> >
> >
> > stage('Confirm deploy to UAT'){ // prompt user }
> >
> > stage {'deployUAT') { /* deploy the build to a PreProd/User Acceptance
> > Testing enviornment */}
> >
> >
> > stage('Confirm publish to Nexus'){ // prompt user }
> >
> > stage('publish') {
> >
> >     steps {
> >
> >       // mvn deploy -DskipTests (just deploy - don't rebuild)
> >
> >     }
> >
> > }
> >
> >
> > Basically, I want to design my Jenkins pipeline to be my staging process.
> > The problem I have is I'm not sure how I can only deploy at the end of
> > the pipeline.  When maven runs the deploy lifecycle, it will run
> > through all the other stages and reassemble my binaries, which
> > technically are not longer the same as those that were approved.  So
> > consequently, my binary hashes that were approved earlier in the
> > pipeline are not the same hashes that are deployed in Nexus.
> >
> > I realize that i can probably do some work and use the Reproducible
> > Build plugin (https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__zlika.github.io_reproducible-2Dbuild-2Dmaven-2Dplugin_&d=DwIBaQ&c=
> > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> > nSxyAsyxa1Izff8ULe7vW8u084madbci-hLPsiLpxeU&m=Og2S17jc02JRwm-oHae8UQmi
> > Ig_
> > ygbBRL0EQoB_Wvuw&s=zipmYyPLpmFYv1RsnquZtQMf0-HoYoix12SZj6gD2jM&e=),
> > but that too comes with drawbacks (I want build timestamps in my
> > Manifest files, and zip entries, etc).
> >
> > Am I sunk?  Is my only hope to wait until Sonatype releases Staging
> > repos for Nexus 3.x sometime in Q2?  Or is there some other way I can
> > work around this?
> >
> > How is everyone else handling this situation?
> >
> > Thanks for sharing.
> >
> > Eric
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Reply via email to