TFS build task: publishing features with multiple branches

[augurk]

TFS build task: publishing features with multiple branches

[marktaling]

I'm not sure I correctly understand the issue. The buildtask does not require you to specify specific feature files but rather requires you to provide a path from where it recursively should search for .feature files.
Following this logic, there should be no issue when a file only exists on a single branch.

[timvandelockand]

Indeed, when the file matches an existing pattern there's no problem. When a new branch needs a .feature file in a new group in Augurk though, a build step with a new pattern would have to be added. In that case the path will not be found in other branches that already existed.

[marktaling]

So, the problem is mostly that in your case the build step references a folder which is not necessarily present on al branches?

[timvandelockand]

Exactly. Now I could enable 'Continue on error' on those specific build steps, but the build will then only partially succeed (which could indicate that there's something wrong, while it is expected behaviour in that case)

[marktaling]

I think this particular build step is fine as-is. As you do not always have an hierarchical folder structure you want to mimic in Augurk.
I suggest we add a second task which has the described functionality. This new task would not allow you to specify a GroupName but instead use the parentfolders of each file as a GroupName. This would allow you to do grouping on a branch-level while still supporting the use of a single builddefinition.

[jmezach]

I don't think having a second task with similar functionality is a good idea. First of all, it makes it confusing for our users because they need to decide which Augurk task to use. Second of all its not very easy to share functionality between these two tasks, so for us it becomes a maintenance nightmare.

Perhaps we should just add a checkbox indicating which behaviour to use and then make the GroupName field disappear based on that.

[marktaling]

That would work fine as well. The main thing is, I don't want to lose our current functionality.

[jmezach]

Interestingly if I look at how things are set up now (ie. our problem domain ;)) we not only have to look at the direct parent, but also parent folders above that. So I have two questions:

• How far do we go with this? Keep going until we hit the folder we started searching from? At the moment that would be the folder the build is run in, which might not always be what you want. Perhaps add a base folder option for the search as well?
• What do we with each sub level in terms of naming the group? Ie. what does the group name become if the sub folder structure is something like \Specifications\Client\Business policy\PauseProfile?

[marktaling]

I would assume we only support the highest level. So we would always take the direct parent folder?
It's easiest to implement and clear in the way it functions.

[jmezach]

@timvandelockand Is this still an issue?

[timvandelockand]

@jmezach Not anymore; the 'use folder structure' checkbox works like a charm.

[jmezach]

This has been fixed already. We have also recently moved the VSTS/TFS extension to its own repo (https://github.com/augurk/vsts-extension)