[#BAM-386] Automate deploying for all Maven II Projects once build is successful

Bamboo

Automate deploying for all Maven II Projects once build is successful

Created: 01/Nov/06 04:31 PM Updated: 13/Mar/07 05:28 PM

Component/s:

Build Process

Affects Version/s:

None

Fix Version/s:

0.7.1

Time Tracking:

Original Estimate:

1 day

Remaining Estimate:

1 day

Time Spent:

Not Specified

Participants:	Cameron Fieber, Mark Chaimungkalanont [Atlassian] and Tony Truong
Since last comment:	1 year, 43 weeks, 1 day ago
Number of comments:	3
Internal Priority:	1. Highest
Labels:

Description

« Hide

A post on Nabble Maven Users (http://www.nabble.com/core-api-container-outdated-on-snapshot-repository-tf2550173.html#a7110351) has given a brilliant idea for Bamboo.

For those who run on maven projects, It would be a great feature for successful nightly builds to automatically deploy to the remote repository. The build process would be something like this:

External:
(1) SVN/CVS commit new changes

Bamboo:
(2) Builds triggered, builds
(3) IF (successful build) && (maven II project) THEN run 'mvn deploy'

Some prerequisites for doing this are:
1. pom.xml must have distribution managment setup
2. bamboo server must have settings.xml setup with authentication settings.

I'm sure the guys at cargo codehaus would love you for this

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Mark Chaimungkalanont [Atlassian] added a comment - 01/Nov/06 05:40 PM

Maybe I'm missing the point, but doesn't specifying the target to be

clean deploy

do this exact same thing? We've got this setup for the atlassian-spring project at the moment (so that it deploys to the repo everytime it builds)

[ Permlink | « Hide ]

Tony Truong added a comment - 20/Nov/06 05:54 PM

Ahh, i see. It does work, thanks!

[ Permlink | « Hide ]

Cameron Fieber added a comment - 13/Mar/07 05:28 PM

the only issue I have with running clean deploy is that it doesn't really make sense in a multiproject environment because maven will upload stuff as soon as each piece finishes

for example say you have

project/

--common-api/

--impl1/

--impl2/

impl1 and impl2 both depend on and implement common-api

if you make a change to the common-api and it builds but breaks impl1 or impl2 then the automated build would end up pushing up the new version of common-api then failing.

I currently work around this by running a shell script build to do a two phase build – first build the entire project, then do the deploy

I don't want any artifacts to end up in the repository unless the build is successful