DeployableId Discrepency in Deployment Plan

I believe there is a bug that causes an action group to lose its DeployableId or have it reset to zero.

I have not been able to pin down the precise circumstances, but the symptom which I have encountered is that I have one Action Group that, for example, gets labeled source and sets Assembly versions attributes. I then have another action group which builds the source. I sometimes find that the first action group has its work and source directory set differently to the second.

In the case I had to today was it was _SVCTMP_A14_S0 and _SVCTMP_A14_S16. When I exported the Deployment plan I could see that there was no DeployableId="16" for the action group in question. Adding this and reimporting the plan solved the problem.

I not sure how the DeployableId got lost/reset - possibly because I copied the action group from another deployment plan, perhaps because I already had one of the same name in the deployment plan?

Product: BuildMaster
Version: 4.1.3

This can sometimes happen if you import a plan from an application that only has a single deployable. It is possible that a deployment plan could be created without being assigned to a deployable, and since applications with a single deployable are designed to hide deployables from the UI, it's difficult to determine what would have caused this.

From the UI, the easiest way to ensure that the correct deployables are assigned to an action group is to add a 2nd "dummy" deployable that will re-enable the ability to see assigned deployables from the UI perspective. This will then display the deployable name on the action group as it did before v4.0.