maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: Is there any on-going work to implement standard build promotion/staging mechanism?
Date Sat, 12 Jan 2013 05:45:13 GMT
sorry for the delay, time is missing lately

introducing new status, with pseudo-pom property and so on seems irrealistic, 
at least to me: the concept is interesting, but I doubt it can fit into the 
actual code
Perhaps with Maven 3.2 (precise version and feature definition hypothetical), 
since decoupling dependency resolution in a work in progress because really 
needed:  started in Maven 3.0 with a first extration into Aether, will continue 
in 3.1 with some experience in evolutions. An evolution like yours could be 
imagined only after, IMHO

But looking at your actual pipeline, perhaps we can imagine something with 
actual Maven features

Le dimanche 6 janvier 2013 10:18:18 Gábor Guta a écrit :
> Hi Hervé,
> 
> > can you explain the ant/ivy build pipeline implementing promotion you did
> > with the help of my team mates?
> 
> Context: we have several modules which are built on top of each other.
> The build pipeline:
> - developer commits his/her changes to the SVN
ok, standard SNAPSHOT source
> - the Jenkins server checks out from SVN, compiles and runs the unit
> tests; finally, the jar artifacts are created and published with
> "integration" status
ok, publishing the SNAPSHOT binary to an integration repository
> - a Jenkins job retrieves this artifact from an Ivy repository and
> checks out secondary tests from the SVN; runs the secondary tests; if
> all tests pass, the description of the artifact is re-published with
> "milestone" status
this one can be done by copying the SNAPSHOT artifact from integration 
repository to a milestone repository

> - other jobs grab only the artifact if it has least "milestone" status
other jobs, which refer to the SNAPSHOT with its "-SNAPSHOT" in the version 
only use the milestone repository, not the integration one: fine

> - on the end of the pipeline "milestone" artifacts can be promoted
> manually to "release" if the manual tests are successful
that's the tricky part: you're changing a SNAPSHOT artifact to a release
do you expect build reproducibility of the release? (even if your objective is 
to promote the pre-built binary, not to deploy a rebuild)

what about copying the binary into the same repo, ony changing its version 
coordinates: of course, its content (META-INF/maven/$gid/$aid/pom.xml) won't 
be consistent

> - other loosely coupled projects reference only to artifacts with
> "release" status
ok, they reference release versions in the release repo

> 
> Promotion is handled completely by the apache-ivy. It allows you not
> only to reference snapshot as maven do, but you can specify
> "latest.integration" or "latest.release" as version.
without any version? and not "latest.milestone"?
with Maven and previous repo, you can write an unbounded range: [minimal,)
activating integration consists in adding the integration repo
Notice: you might require separate integration or milestone repos to 
distinguish which dependency can include milestone


would that make sense?

Regards,

Hervé

> We use standard
> Ivy statuses, but custom statuses can be defined too.
> 
> Regards, Gabor
> 
> > (notice I won't be here for 1 week, so won't be able to continue the
> > discussion for the moment, but the topic is worth more discussion)
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le jeudi 20 décembre 2012 12:12:22 Gábor Guta a écrit :
> >> Yes, I want to start the build of other projects if new version of the
> >> promoted artifact is available.
> >> 
> >> Imagine a larger project in which 15-50 modules exists. Top level
> >> module build is triggered by the available new modules with a specific
> >> status i.e. performance tests run when new version of the dependencies
> >> with integration status available, but installer generation needs new
> >> artifact with milestone quality. Developers also prefer to work with
> >> milestone artifacts as they need something which is more stable than
> >> snapshot, but newer than the latest release. I hope this helped to
> >> clarify the role of module statuses.
> >> 
> >> Regards, Gabor
> >> 
> >> On Thu, Dec 20, 2012 at 8:35 AM, Hervé BOUTEMY <herve.boutemy@free.fr>
> > 
> > wrote:
> >> > ok, I see the workflow for single artifact promotion
> >> > 
> >> > Once this artifact is promoted, you want to update another project's
> >> > dependency to rebuild using this (now promoted) artifact?
> >> > Or your wish is about not rebuilding the other project but promoting
> >> > its
> >> > built result and modifying dependency to let think it was built with
> >> > the
> >> > promoted artifact?
> >> > 
> >> > 
> >> > (notice I'm going to my day work: I won't be able to continue this
> >> > discussion before the end of the day...)
> >> > 
> >> > Regards,
> >> > 
> >> > Hervé
> >> > 
> >> > Le jeudi 20 décembre 2012 07:51:08 Gábor Guta a écrit :
> >> >> We make the promotion of the already built artifact and we update the
> >> >> metadata. e.g.: if the corresponding integration tests are fine, the
> >> >> status of the artifact change to milestone.
> >> >> 
> >> >> Regards, Gabor.
> >> >> 
> >> >> On Thu, Dec 20, 2012 at 7:17 AM, Hervé BOUTEMY <herve.boutemy@free.fr>
> >> > 
> >> > wrote:
> >> >> > in your ideas, do you intend to rebuild the artifact at each
> >> >> > promotion,
> >> >> > or
> >> >> > make promotion of the already built artifact (then without
> >> >> > rebuilding
> >> >> > it),
> >> >> > only changing its status metatada?
> >> >> > 
> >> >> > Regards,
> >> >> > 
> >> >> > Hervé
> >> >> > 
> >> >> > Le mercredi 19 décembre 2012 15:37:18 Gábor Guta a écrit :
> >> >> >> Can you give me feedback feedback / recommendation about how
can I
> >> >> >> write extensions for Maven to support a build pipeline and
artifact
> >> >> >> promotion in a "standard" way. As far as understand these
issues
> >> >> >> are
> >> >> >> common problems, because I have found many blogs describing
hacks
> >> >> >> and
> >> >> >> workarounds. I also have to mention that nexus and artifactory
> >> >> >> provide
> >> >> >> custom fixes for these problems, but I would prefer not to
be
> >> >> >> locked
> >> >> >> to a specific vendor. I built an ant/ivy build pipeline
> >> >> >> implementing
> >> >> >> promotion with the help of my team mates. My primary motivation
is
> >> >> >> to
> >> >> >> enable the mixing of artifacts from ant and maven builds 
 through
> >> >> >> a
> >> >> >> central maven repository.
> >> >> >> 
> >> >> >> I have two main issues with the current Maven model:
> >> >> >> - no standard way to handle traceable snapshot i.e. snapshots
are
> >> >> >> temporary and I can't push them through on the testing pipeline
by
> >> >> >> referencing to them by a unique id (build number);
> >> >> >> - no standard way to reference to staged/promoted artifact
in the
> >> >> >> dynamic version number i.e. I can't specify in a standard
way that
> >> >> >> I
> >> >> >> want the latest artifact which passed the integration test
and has
> >> >> >> version from a specific branch.
> >> >> >> 
> >> >> >> Proposal for promotion model:
> >> >> >> - store status information in a POM property (introducing
standard
> >> >> >> meta data in the POM would be much nicer) e.g. integration,
> >> >> >> milestone
> >> >> >> - write an extension which can interpret and resolve "3.3.?
> >> >> >> latest.milestone" like notation in the version number
> >> >> >> 
> >> >> >> Proposal for staging model:
> >> >> >> - status information is identified by the repository location,
so I
> >> >> >> have to be able to add multiple repositories with meta data
about
> >> >> >> the
> >> >> >> status of the stored artifacts
> >> >> >> - write an extension which can interpret and resolve "3.3.?,
> >> >> >> latest.milestone" like notation in the version number
> >> >> >> 
> >> >> >> 
> >> >> >> Gabor
> >> >> >> 
> >> >> >> -------------------------------------------------------------------
> >> >> >> --
> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> > 
> >> >> > --------------------------------------------------------------------
> >> >> > -
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >> 
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> > 
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> 
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message