Hi Dave,
indeed, when opening the queue dialog, the mapped branch will be the default. It was an oversight on my side, that the configuration is used for manual builds only.
We use a simple branch model with master as the integration branch, into which feature branches will be merged by a merge-commit. Thus, master is the branch which contains the next version of our product(s) currently under development.
Since we maintain at least one version in production, we create a release-branch for every released version. We therefore setup two configurations: dev and release/m.n. Configuration “dev” builds on master and topic branches. Configuration “release/m.n” builds on the release branch. For example when a service pack needs to be deployed. Any time a commit is pushed to the server, the trigger is used to build that specific commit. Thus, releasing developers of the burden of manual builds and automatically provide builds for our continuous integration pipeline.
The dev and release configurations are very similar. They share the same repository, but use a different version format string and build number. An event is used to create tags on the release branch, which uses a condition of the event handler to act upon the release branch only. As mentioned by you, the requirement is to support an automatic trigger that takes the branch mapping into account. Having another option to the Trigger On drop-down would satisfy this requirement.
I can now see how this would allow to even simplify the configuration further. By adding a “Conditions” tab to the trigger (as used by event handlers), we could create triggers for dev and release within one single configuration and assign the specific version string by the “Variables” tab offered by the trigger configuration.
Hm…, but how to configure the buildnumber, which is different to dev and release branch?