Hi,

Maybe someone could construct a case where a VCS triggered task runs, then stops, waits for a manual task and the next runs with another VCS change.

The ability to stop and wait for manual input will be possible in Bmaboo 3.2.

However, the way it will work is that when the build is originally triggeres, Bamboo looks at all the repositories of all the jobs within the plan and records their current revision.

So if the build stops at a manual stage, after it is manually told to continue, the jobs will update to the revision that was recorded for them when the build was originally triggered.

The reason for this is that we found that users really want to ensure that if the build stops and waits for manual input, when it continues it only picks up changes that have already been there when the initial build is triggered.

If you do not agree with this, could you provide a detailed description of a use case as to why after manual input each job should check out the latest copy of its repository?

Cheers,
Anton

Hello

You're right the multiple goals per build plan thing is there.

I'll create a feature request for it.

I don't see a case to trigger a stage or task by VCS neither. In my world continuous builds would detect VCS changes while nightly builds run different goals but on a configured schedule.
Maybe someone could construct a case where a VCS triggered task runs, then stops, waits for a manual task and the next runs with another VCS change. I could imagine if you setup environments during a build (databases, vmware images, ...) or generate code from another repository than VCS it may turn useful to just allow it - whether most people may not use it. The feature is there... so? I think stages / tasks could be seen as parent plans. Dont run two tasks triggered by VCS if they are in the same queue concurrently or ... or ...

Lots of possibilities

thanks!

Hi,

Please note that the feature dscribed in the description of this issue is actually introdcued in Bamboo 3.1 with Tasks:
http://confluence.atlassian.com/display/BAMBOO/Bamboo+3.1+Release+Notes#Bamboo3.1ReleaseNotes-Tasks

In Bmaboo 3.2 we are introducing Manual Stages that allow the build to be paused at a certain stage, and then one can manually get the build to continue. This is also possible with a REST call, so if the calling a REST call is cronned then it is possible to get close to what you are describing.

I understand that it is not ideal, as one still needs to write a script and then cron the script.

Please raise a new fetaure request for having separate triggers for stages.

Also, while I see the use case for having a cron trigger for a stage, I do not see why one would want to trigger a stage based on VCS change detection.

Is that also needed? If so, could you tell us more about the use case of this?

Cheers,
Anton

well stages come close to this.
what is missing with stages is the trigger. all stages are triggered by the same event.

If I want to create a Job with a continuous build and a nightly build putting them into stages wont work as the trigger cannot be configured individually (SVN changes, cron expression).

So I need to split the configuration into plans and repeat all the settings. If Stages would have their own trigger to define when the stages run this would be resolved. Bamboo 3.1 has this trigger on the source repository configuration, which is attached to the plan. All stages inherit it.

Stages could be enabled to re-define the 'build strategy' (polling, cron, ...) I guess?

This is not Continuous Builds or even Integration but rather Continuous Deployment and Delivery.

All the work in Bamboo 2.7, 3.0 is aimed at providing support for more released-focused workflows. But remember that at its core Bamboo remains a Continuous Integration tool.

But at any rate, most of the bits to to express the "gates" in your release cycle are already there with Stages and Jobs.

See:

http://forums.atlassian.com/thread.jspa?threadID=48944&tstart=30

hallo

this feature would still have some use for me

(continuous builds with mvn clean deploy and nightly builds with mvn clean site-deploy / mvn cargo:deploy)
http://forums.atlassian.com/thread.jspa?messageID=257283181

i'll add one vote

regards
werner

Jainthra,

Sorry about this but we've been trying to push towards a 1.0 release of Bamboo and this feature has had to slip out While it's not the best solution, you should be able to easily "Clone" a build plan to give you a configuration of a build for a point in time.

Hopefully this would be an okay workaround for now.

Cheers,

Mark C

"You'd then have a Standard Build that runs for each commit and runs the "package" goal (you'd only have to specify this one property) and another Release Build that you run manually (or as a dependent build on another build) that runs the "deploy" goal."

This would work for us.

Jainthra,

I'm guessing you're running these builds manually?

In a future Bamboo versions (probably 0.6), we're looking at being able to define Project definitions that can be over-ridden by various builds.

So in your case, you'd have a Project with the various CVS, notifications etc setup. You'd then have a Standard Build that runs for each commit and runs the "package" goal (you'd only have to specify this one property) and another Release Build that you run manually (or as a dependent build on another build) that runs the "deploy" goal.

Would that work for you?

It's that if the deploy goal was specified in the same build, there's really no way for the build to differentiate when its triggered by a commit, which goal it should really run?

Cheers,

Mark C