Build Agent group functionality

attach the first part of the solution. build agent group function.

attach patch for review (build agent group+selection of agents). added new field "build agent group" to the profile table.

added patch again.

• fixed selection of agents algorithm.
• added an overall task-queue-executor for distributed build queue to delegate the task.
• implemented a 1 queue 1 executor approach for every build agent
• for the scenario where the current task in the distributed build queue doesn't have a matching build agent (e.g. build agent of that particular group is disabled ), i'll just add back the task at the end of the queue so as not to block the other tasks in line. in this way, when the matching build agent is found in the future, the task will be processed.
• rule of selecting the build agent in the group : it will return the first non-busy agent from the group , else it will return the first agent in the group.

• refactors:
  move DistributedBuildTaskExecutor, DistributedBuildTaskQueueExecutor to continuum-api.

updates:

• use version 1.1.4+ for modello version
• added Distributed Build Queue view in Build Queue page.

Fixed in revision 748163! Thanks Jan great work

Modified some lines on the patch:

• format
• fix build queue not showing in queues page
• fix blank page when adding build agent group with no build agents available

I've just tried this out and have some questions...

It seems that an agent can be added to more than one group. Is that intended?

What does it mean for a build agent to be in no group(s) at all?

I'm having trouble with the workflow involved in getting my first distributed build to happen. Now that we have these agent groups, it seems like you can't rely on the default build environment (none selected, just whatever Continuum is running as.) That means that logically, the default build definition, which does not have a build environment selected, will not actually do anything.

(Except that it does... I see activity in agent-1's logs, but I'll hold off speculating until I hear how it's intended to work.)

The agent grouping is not working on trunk (1.3.2-SNAPSHOT Build Number: 754707). Agents don't seem to stay in the group after the first page display.

To reproduce:
1. Add a build agent
2. Add a build agent group
2a. While adding the group, move the agent over to the 'used' column
3. save. Note that the agent appears in the list for the group
4. edit the group
Expected: the agent appears in the list indicating that it's in the group
Actual: the system displays "No build agents" (and does not show the multi-selection component)

I'm also having trouble deleting the first group that I added, which was named "Default Group". I can delete other groups that I added later.

I'm not seeing any log messages while adding/deleting agents and groups. Should there be?

Fixed in revision 754790

• show agents when editing agent group
• fixed showing of action errors in jsp page

I was able to delete the first group that I added. Maybe your agent group was attached to a build environment that's why you weren't able to delete it and the action errors is not showing in the jsp page?

> As long as it is enabled, build agent with no group can be delegated a build task only from project whose
> associated "build-environment.build-agent-group" OR "build-environment" is empty.

So that means groups are optional. You can add a bunch of agents, not put them in any group, and it should work out of the box with the default build definition [no build env, therefore no agent group]. This would explain why I was seeing activity on my build agent, which wasn't in a group.

Thanks for the explanation!

Re-closing now that adding/deleting groups and agents within groups is working on the web page.

(Successfully tested distributed builds with mvn jetty:run in both webapps, however my original tests were with the Jetty bundle, so I'll keep investigating.)

Looking through the docs, it doesn't look like they've been updated for this new feature.

Rather than re-opening this one again, (and possibly complicating the 1.3.2 release notes,) I opened CONTINUUM-2137 and linked it.

It's not "done" until it's documented.