Add proposed/desired branch to promotion strategy

[BenHesketh21]

Currently, if I understand correctly, you need to hydrate your proposed changes to a branch with the same name as your sync source with "-next" appended. The gitops-promoter should allow users to define their hydrated branch names however they like, I personally prefer to prefix them rather than suffix them as it's easier to tell which are proposed especially if you have long branch names.

What makes sense to me is to add this as an option in the promotion strategy as proposedBranch or desiredBranch as I see there's an issue about changing from one to the other.

[crenshaw-dev]

I'm a big fan of convention over configuration. Helps avoid small mistakes that waste lots of time.

The long-env-name problem makes sense to me. What's the prefix convention you're considering?

[BenHesketh21]

I completely understand that, I will say that I've been scratching my head for a couple of days trying to understand why the example ArgoCD tutorial works but I can't get my own project to work and it was because I wasn't putting -next on my branches😂. But maybe that's more a me problem and it's documented somewhere I didn't see.

I've taken to using a "folder-like" prefix. Something like proposed/env-name or candidate/env-name. Proposed probably makes more sense in this project.

[crenshaw-dev]

But maybe that's more a me problem and it's documented somewhere I didn't see.

I don't think it's documented as well as it should be... I'll try to improve that.

I've taken to using a "folder-like" prefix. Something like proposed/env-name or candidate/env-name. Proposed probably makes more sense in this project.

One downside to prefixing is that alphabetical ordering won't "group" the two branches for a given environment. But maybe that's preferred.

I like the term "candidate." We've also discussed "desired" as an alternative term.

Naming things well is half of API design. :-)

[BenHesketh21]

Yeah that's true about alphabetical ordering, I just know that if my org was to use this, our env names are so long and even though they would be grouped together it would be a 50/50 chance whether you get the one you want😂 I suppose if you know the convention then you know the -next branch should be the second one.

[BenHesketh21]

Another option that could possibly be the middle ground, what if we could set what the prefix or suffix could be when running the gitops-promoter? So by default it's '-next' but you have the option to set it to something else for all promotion strategies?