We have a project dependency chain such that building a project triggers a series of other builds and ultimately tests.
I set it up and it was looking like it was working, but noticed today that the tests are always running against the trunk not the branch that was committed. It seems the build completed trigger doesn’t use the build that actually completed but always the trunk, and there’s no way to specify it.
Is there a way to do this? I’m currently thinking of a repository trigger with a 20 minute delay as a workaround, but that doesn’t work if the build fails.
Hi Tony,
Currently the only information we send to a build completed triggers is whether the triggering configuration was successful or failed. We don’t send any details of which repository branches were built on the triggering configuration (note that the trigger could be based on another configuration associated with different repositories).
The trigger will build the branches mapped for the trigger (set in the branch mappings tab). If this is not set, it will build the branches mapped for the current configuration (set on the configuration branch mapping dialog). If this is not set, it will build the default branch for each repository (set in the repository dialogs).
We are planning to pass much more information (such as branches, changeset revisions, variables, triggering users) to the build completed trigger to enable your type of scenario. We hope to include this in the next minor version release.
Meanwhile, the only way to achieve this would be to use separate configuration per repository branch. We realise this is not ideal.