Add Spec for Cloning Branch Configurations

[nilofer]

Initial proposal for cloning branch configurations in response to #22. Updates for design and API experience to come. Also related to #106.

[RWOverdijk]

I like the clear writing used, it's easy to follow.

My approach would perhaps be slightly different.

Build configurations

I'd extract it from branches altogether and make it its own feature.

• I'd have a new tab in the main menu called "Build configurations". Perhaps as a child route of Build.
• This page shows a list of configurations that have been created and labelled by the user (first visit would show a default).
• These configurations will hold the same values as what's currently a branch configuration (env vars, auto increment build nr, signing, etc).

The nice thing about this approach, is that you can update 1 config which then applies to all branches.

But the real reason this is cooler is that you can set a default build configuration, so you don't have to configure anything after the first time. This is useful for feature branches and requires no cloning.

Additional

If it would be possible to then add a "matcher" for builds, it would be near perfect. For example, a new build config option could be:

Use this config for: and then a dropdown select with two options:

• Branches (opens a new picker that allows you to pick branches)
• Pattern (opens a text input that allows you to supply a pattern. E.g. feat/*)

Conclusion

There's no way I'm going to say your proposal is bad. I'd love to have this feature.

However, I do think this would end up actually copying configurations to other branches, making it harder to change in the future due to duplicate data and no way to tell which configs are the same. So while this approach might be a bit more involved, I also think it might work better.

Either way, you get my 👍

[RWOverdijk]

Call it a challenge and stay positive 😄

[patniko]

😂Appreciate the kind words.

[ferdicus]

Wholeheartedly agree with @RWOverdijk.

Real-life example to hit the point home:
depfu branches that are automatically created on your repo to update dependencies.

Oh you want to test if the build still compiles on appcenter?

currently solution:

copy all the build config options by hand.... 😒

initially proposed solution of this PR

copy build config ... every time ... a new depfu PR is created... 😐

@RWOverdijk solution

oh depfu branch?
let's take the default build config and apply the additions of your depfu branch build config 😄
👏 👏 👏

[SandroMachado]

It could be helpful also override a specific configuration. I believe that this will be available by default.

[patniko]

This is a fair point. 👍 With Azure DevOps backing our build service this might be a bit tricky for us when it comes to the way we manage secrets. Cloning a configuration is an API call, but overwriting a config with new secrets without losing build logs is a more difficult challenge. @nrajpurkar and @dennispan will take a look and circle back.

[phoney]

While this is an obvious improvement over the current implementation I don't understand the limitation of one configuration per branch. Why isn't the branch a property of the configuration rather than the other way around? I would expect there to be an unlimited number of configurations with the ability to duplicate and delete any of them. I would choose the branch to be associated with each configuration just like I choose the version of Xcode, the scheme, etc. The way that configurations disappear in a cloud of smoke when I delete a release branch now is odd. I would like to have a release configuration that I use on any release branch as well as others. Some would run tests others wouldn't. The current design doesn't make much sense to me.

[nilofer]

@phoney this is definitely valid feedback and looks a little bit different than what is proposed here. That aligns more with #65 and also something we are taking a look into as a future improvement.

[SandroMachado]

Not sure about this. Usually we only distribute the master builds to app store etc. We should be able to select which configurations we want to clone.

[chrisheninger]

@SandroMachado from what I understand, everything will be copied, saved, and then you will have the ability to edit/remove any of the settings that you didn't want applied.

So in your situation, if you don't want the distribution settings to be copied, you would clone the configuration, save, then navigate to distribution settings on your cloned branch and turn them off.

[patniko]

That's our thought here. You can always follow up an API call with another to adjust distribution settings and/or modify them through the portal UI directly.

[patniko]

Totally agree it'd be great to have templates @RWOverdijk. We are looking at making multiple improvements to build over the course of the year with this one being part of the discussion. Realistically it'd be easier to enable multiple configs per branch, allow you to set one as the default and automatically apply that policy to new branches with things like branch name filters. Something like that would be more straight forward to look at in the future. How does that solution sound?

[RWOverdijk]

@patniko That sounds like what I suggested so I do think that sounds good!

[wzph-10e]

[EDIT Missed your comment to @RWOverdijk from 21 hours ago, which covers my question]

@patniko Thanks for the open process around this feature (and others).

Has there been any discussion around a default build config for the repo, which all new branches would inherit? It's a pretty common use case to regularly generate lots of topic branches. It would be great if we could set App Center to treat them all the same way by default. Then if we need to, we can tweak them on an individual basis.

[patniko]

@wzph-10e it's definitely come up before. Cloning and templating aren't very dissimilar at the end of the day, but there are other options for templates like yml configs. We'll more than likely follow a path mentioned in my previous comment because of the general demand for multiple branch configs. If the best experience ends up being templates we will definitely take a look at going down that path.