Does BuildMaster support Fan-In project dependancy?

I have 3 different projects (database, desktop client, middleware) that are built independantly, I want to bring the resulting artifacts together and deploy as a whole. I assume that will mean creating a seperate "application" that aggregates the results from the other 3.

Requirements:

Could be 1, 2 or all 3 components available for a release
As each application is built and notifies the "aggregate application", the build step would need to include artifacts from other projects if they have previously triggered a build, eg:

PrjA builds and triggers PrjAggregate - it now has 1 artifact to deploy

PrjC builds and triggers PrjAggregate - it now has 2 artifacts to deploy as it has imported the previous builds artifacts into the new build

PrjB never builds - PrjAggregate has 2 artifacts to deploy

Product: BuildMaster
Version: 4.5.6

I'm actually building these artifacts in Jenkins, copying the artifact to a file share and importing the artifacts using the Create Build Artifact action in the Build Step.

I've investigated both the "Build Importer: Import builds from file system" and the "Create Build Artifact action", both come up a bit short.

Build Importer: Import builds from file system

Is a lot more flexible in what it will import. The Artifact selection option "Multiple" was very nice but I didn't see how I could reference those artifacts in build steps and when triggering the build from buildmaster didn't import anything.

Create Build Artifact action

My thought was to run this action for each artifact that I might want to import, checking that the artifact exits and has the correct release number. Unfortunately this is a very basic action and doesn't support filtering of files, and there is no predicate that would check for the existence of a file. Also when deploying artifacts I'm not sure that there is any way to skip artifacts if they don't exit.

Solution

Use deployables rather than artifacts. In define deployable screen set "Add to all active releases" to false. Note: BuildMaster has a bug as this option is not available when editing an already created deployable and I want to ensure this is false.
Enable the deployable for the release from the Jenkins plugin that I have created. Assumes there is an api call that will do this!
In Build Step have one group per deployable with predicate that deployable is enabled and use Create Build Artifact to import artifact - above mentioned limitations with this action should not be an issue.
A deployment step would again require at least one Group per deployable with a predicate that the deployable is enabled.
Downside: the artifacts that produced in Jenkins will have to sit around in the transfer folder waiting to be imported into BuildMaster for as long as the release is active.
I'm not quite sure what to do if multiple active releases are enabled. Might have to ensure the path for the import folder contains the release number.

What do you think of this solution?

Are you likely to fix the bug with in the edit deployable screen where unable to update the "Add to all active releases" setting?

Your projects sound like they're all part of an overall business application; i.e. to the business, and how it's consider for requirement changes and the like. In that case, the best way to handle this scenario is through deployables; that's basically what they were built for.

This allows for "partial" releases (i.e. having 1, 2, or 3 components) easily, and allows for some more advanced dependencies (such as, say, you wanted to import one of those deployables to another application).

However, in Jenkins, these would be represented as three (or more) different jobs. So, what I might try is to use a Build Plan (i.e. not a build importer, just a regular plan you can add actions to)... and then use three different action groups (each associated w/ a different deployable) that contains "Get Jenkins Artifact (to working directory)", "Delete Files (from working directory, with whatever masking you need), then "Create Build Artifact (from working directory)".

It's a little inefficient I suppose, because of the zipping/unzipping, but hopefully that is trivial. As for the bug, actually first I heard of it --- mind submitting a ticket so we can get it fixed?