Default Branch mapping not working as expected

#1

Hi,

i use a configuration that assigns an explicit branch mapping as the default branch for the configuration. However, an assigned trigger does not function as expected.

To be clear:
Edit/Repository/Branches/Default Branch => master
Mappings/Default Branch => release/x.y

The trigger is configured to “Trigger on Default Branch”.

I push a git commit on release/x.y. The trigger does not fire, but it should.
I push a git commit on master. The trigger starts a build :frowning:

Note, this issue is related to my post here:

#2

Hi Thomas,

When a Repositories Trigger is set to trigger on the default branch, this means that it will trigger on the default branch set in the repository settings.

The Default Branch mapping is only used when manually starting a build.

image

It is also used for to define the branch to build for other non-triggering repositories in the same configuration, so I can see how you might expect this to work differently.

This will need some clarification in the UI. We wouldn’t want to change the behaviour now as this may break builds for other users, but we will look into adding another option to the Trigger On drop-down which takes the branch mappings into account.

#3

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?

#4

While you can’t change the $Build.BuildNumber$ during the build, you can use other “number” variables as “branch build number” counters and use the Persist Build Variable event handler to increment and save the relevant variable at the start of the build. You can then use these variables in the Set Build Version actions with some If … Else logic to choose the variable and format to use based on the current branch. Note that this can have unexpected results if builds run at the same time, so I would link the Persist Build Variable event handler to a short initial stage with a shared resource lock added to it to prevent it from running concurrently.

Alternatively, you could add more than one triggering build configuration (one for each of the dev and release branches) which contain nothing but repository triggers, then use a Build Completed Trigger to trigger and pass on the build number and version string your main build configuration.

#5

What would you put in the Conditions tab that is not covered in the other tabs?

#6

Hi Dave,

thanks a lot for your explanation on the subject. It is an interesting approach. It does extend my ability to work with Continua, as my understanding using configurations and triggers is set to a new level :slight_smile:

My experience by using a Buildsystem such as ContinuaCI is, that build configurations change over time. Either because of new requirements, new insights on Continua or changes in the tool chain. Therefore when releasing a new product version we rename ‘dev’ configuration to ‘release x.y’ and create a new ‘dev’ clone configuration. Doing so gives us ‘versioning’ of configurations. This concept allows for simple configurations and is efficient also.

The procedure requires some changes to the configurations, such as:

  • setting up the version string
  • configure the branch mapping
  • configure the trigger

The trouble is to have all team mates keep up to date on the procedure. Thus my goal is to reduce the steps necessary to release a version.

For example, the configuration includes an event handler to create tags on the release-branch. The event handler is enabled for the configuration, but fires only for the release-branch. This is achieved by a condition doing a string compare on the branch-name.

#7

As described the mechanism used for event handlers in my previous answer, I’d use a string comparison on the branch-name. This would allow the trigger to exist on a project scope, but triggering only, on specific configurations.

#8

Hi Thomas,

Other than having a trigger which executes on the default branch mapped for the configuration, which we will implement, I’m not quite clear what additional features you are asking for.

Triggers already have the ability to be conditional on the repository branch name. If you select “Pattern matched branches”, then you can enter a pattern or a variable containing a pattern to match against the branch name.

e.g.

image
image.png644×604 15.7 KB

I can’t see what we could put in a trigger Conditions tab, which would not be a duplication of the existing functionality.

I’m also not sure what you a looking to do with the build number (and version string). I previously thought that you were trying to have different build numbers for different branches on the same configuration, but it now appears that you are using a new configuration for each branch.

If the aim is to reduce the number of steps after cloning a configuration, then perhaps it would be better to use variables to define the things that change so they can be edited in one place.

Can you provide some examples of the changes that you would like to see to support your scenario?

#9

Hi Dave,

my intention is to disable a trigger by setting a “Condition”.

Consider the following configuration:
trigger #1 triggers on the default (repository) branch
trigger #2 triggers on the default mapping branch (planned for one of the next Continua versions).

If both point to “master”, which is the default, unless configured otherwise, will they both trigger a build?

#10

Yes, but only if a changeset is detected on branch “master”.

What is the condition?

#11

Hi Dave,

thanks for your support. Let’s try a different approach and restart.

Requirements

  • have one configuration for development on branch “master”
  • support multiple configurations on release branches, e.g “release/1.0”, “release 1.1”, etc.
  • trigger dev configuration for any branches, that are not a release branch
  • trigger the appropriate release configuration for the matching release branch
  • manually queuing a build must point to the appropriate branch
  • only minimum changes required when releasing a version

Comments

  • a release means renaming dev to release/x.y (to keep build history) and clone that back to “dev”
  • i tried to achieve this by using the repo default branch and configuration mapping branch respectively
#12

Hi Thomas,

Which of these requirements are you currently unable to meet?

#13

NONE.

I can achieve all requirements. I already do. The trouble is, that i don’t change configurations from dev to release x times a day. Nor do my teammates. I/we do it once in a while. Though there are only a few changes necessary, it’s not easy to remember all (details) of them.

#14

Hi Dave,

i think about using a slightly different approach. I already use a pattern matched branch for the dev configuration to trigger on all branches except “release/”. I should be able to use a pattern matched branch for release too, by simply writing the name of the branch. Maybe my previous approach is more complex than necessary. Probably this is a result of Continua’s configuration options, which somewhat led me in a wrong direction.

The repository and the repository-mapping dialog allows to select a branch. It does not allow to configure the branch name as a user defined string value though. On the other hand, the trigger dialog uses a string value (or a default branch) for the branch name (pattern).

If both dialogs would support the same semantics it might be easier to understand and use the options. For example, if both would provide a field that supports expressions, i could even define a variable. Thus changing the configuration would be as easy as editing a simple variable.

Selecting a branch name as a value for the string value can be achieved by using a combo box that copies the branch name as a text value.

Thomas

PS: Do expressions allow to use a regex too?

#15

Variable “ConfigurationType” with values release|development

Example Condition “%ConfigurationType% = release”

#16

Hi Thomas,

Sorry for the delay answering this, there’s been a few holidays.

Expanded expression variables in the Branch Pattern field will be treated as regular expressions. So if the variable %TriggerBranchPattern% is used in this field, then you can set %TriggerBranchPattern% = “^release” to trigger on release branches or %TriggerBranchPattern% = “^(?!release)” to trigger on non-release branches.

I’ve add an item to our to-do list to investigate changing the Default Branch drop-down in the Branch Mapping dialog to accept expressions. We may also consider adding conditions to repository triggers in the future.