Thanks, Werner. I really appreciate your time on this.

It really helps us understand what improvements people are looking for.

Cheers,
Anton

Thanks a lot for the explanation. I'll add some votes.

I agree with:

I certainly understand what you are trying to achieve, but the desired way to improve this is to allow for easier configuration sharing of plans, rather than to start slowly, feature by feature, turning stages into plans.

Currently projects contain 'nothing' related to settings (compared to Jira its more of a category for projects). If permissions or repositories would be configured there the build plan would be what i tried to map to stages. So I'll wait what will be there in the future.

Thanks!
regards

werner

Hi Werner,

Thanks for the update. It made it very clear as to why you would like to use stages rather than several build plans, i.e.:

Currently we do several build plans to achieve this, which comes with some overhead.

We are looking to keep stages as a very light weight concept and are not planning to add any extra configuration to them. Originally we were planning to have no stages at all. We wanted to allow builds to have several jobs that could be run in parallel. But we needed a way to represent "forks" and "joins" of jobs. That is, allow certain jobs to wait until other jobs, that run in parallel, to be successful, before the build continues.

This is where we introduced stages, to help manage these "forks" and "joins" of jobs that are allowed to run in parallel.

I certainly understand what you are trying to achieve, but the desired way to improve this is to allow for easier configuration sharing of plans, rather than to start slowly, feature by feature, turning stages into plans.

The source repository is the same

The improvement request for this is BAM-3018.

If we change permission settings we do that 6 times.

The improvement request for this is BAM-2070.

Please vote for these issues and add yourself as a watcher to them. For more information on the way Atlassian schedules new feature and improvement requests, please see:
http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+Policy

For the reasons I have described above, I will resolve this issue as "Won't Fix".

Thank you for your detailed description of your usecase. These things go a long way in helping us understand how Bamboo is used.

Cheers,
Anton

Hallo

What I meant by remove the 'build strategy' from the source repository was only the option into its own tab. Not that I need to have build projects without a VCS. It would be more consistent when also the stages have that.

I am sorry to ask for more of your time, but could you explain why you need triggers for a stage?

I'll give it a try.
The thing is related to how we do releases and inspired of options I've seen in Hudson (specifically the hudson release plugin for maven).

We do continuous builds (we use mostly maven):
mvn clean install

Bamboo does the 'same' thing: mvn clean deploy
Some projects also do integration tests on this continuous build, currently we do just another task with either a profile or plugin, it is also a maven goal.

Once a day we do a nightly build. It does a clean integration, build, tests+integration tests, deployment to tomcat, collecting statistics for sonar, creating a site.

After a sprint or iteration we do a release. (Currently this requires some tweaking, the husdon release plugin worked within minutes)

These steps can be done on a local machine as well. So we would like to build a plan in bamboo that behaves the same way:

One build plan (per branch)

• 1st stage for the continuous build (triggered by VCS changes). "mvn clean deploy"
• 2nd stage the nightly build (triggered with a schedule), this stage contains severals tasks, mainly caused by the splitted test+integration tests and the sonar integration "mvn clean deploy site-deploy cargo:.. sonar:..."
• 3rd stage is only required if the nightly build cannot be used for the release. In hudson this could be the ci build that will just contain a link 'release'. "mvn release:prepare release:perform"

the stages have different reasons to run, so the trigger should also differ (VCS changes, scheduled, manual)

Currently we do several build plans to achieve this, which comes with some overhead. The source repository is the same, the permissions, the build settings and so on. We can clone plans, but if there are 2 branches we have 6 build plans. If we change permission settings we do that 6 times.

Hopefully this explanation is a bit better.

thanks!
werner

Hi Werner,

Thanks for the udpate, again. I appreciate you taking the time to explain things to us.

A bit of an FYI:

It might be an option to move that away from the source repository anyway?

It is already possible. That is, in Bamboo 3.1 it is possible to configure a plan and a task to have no VCS repository at all, and therefore you can have a plan that does not checkout any code.

Now back to the main topic we were discussing here:

Unfortunately, I still do not have a good understanding of your overall goal If we do not exactly understand what it is that you are after, unfortunately we will not be able to build a good solution.

From what I can understand you would like to have triggers for a stage, not just a plan.

I agree that we should never do this on a task level and therefore I have removed reference to tasks from this issues summary.

I am sorry to ask for more of your time, but could you explain why you need triggers for a stage?

What I am looking for is a description of:

1. How you would setup a plan
2. What stages would it have
3. What jobs would each stage have
4. What triggers would you configure on a plan level
5. What triggers would you configure on a stage level

And a description of why you would like to do this.

Without this description, it is difficult for us to understand why adding this feature is important and useful.

Cheers,
Anton

see comment on: https://jira.atlassian.com/browse/BAM-9310?focusedCommentId=259067&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-259067
I think its better to continue here? not sure

Hallo

Well I might got the wording wrong. I have to admit the concepts behind Plan, Stage, Task are a bit hard to implement reasonably. I played around with it but I'm never sure what is the better choice. So:

Currently:
Build Plan
--> Stage(s)
----> Task(s)

currently the execution is configured on the plan. (on the source repository tab the 'build strategy'). It might be an option to move that away from the source repository anyway?

If I could overwrite (or configure) that trigger for a stage that would be perfect I guess. I don't think one need it on the task too. But here comes the issue with not knowing if task or stage is the better idea. From starring at my build plans I would now say: stage is the better option.

BAM-8031 is about multiple trigger for the same thing. I would need one thing for several created stages in a build plan. So it is related but in my optionion not the same thing.

thanks!
werner

Hi,

Thank you for creating this issue.

From what you have been saying on BAM-247, I believed that you were after having different triggers for different stages in the build.

However, from the description here:

So one could create one plan for continuous builds (triggered by VCS changes), a nightly build (fixed timely trigger) and a release build (manual)

It appears that you are after being able to specify multiple triggers for a single plan?

Which one is it?

If it's multiple triggers for a single plan, then the feature request for this is BAM-8031, and I suggest you vote for that issue and add yourself as a watcher to it. We can then resolve this issue as a duplicate of BAM-8031.

Cheers,
Anton