Support Falling Back to Configured Main Branch

[adamrodger]

trafficstars

The consumer version selectors currently support a fallbackBranch option, which is useful because you can first check to see if the consumer has a matching branch name, and if not fall back to the default branch:

https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors

However, this fallback branch must currently be hard-coded in the provider tests, and either may not be known or may change in future (e.g. if someone decides to rename an older repo with the default master branch to main.

In the Pact Broker, it now knows for each pacticipant what the main branch is, and so instead of the provider supplying the fallback branch, it would be better if it could just ask the Pact Broker to take care of that. This means instead of doing this:

{ "branch": "feature/foo", "fallbackBranch": "main", "latest": true }

you could do something like:

{ "branch": "feature/foo", "fallbackToMainBranch": true, "latest": true }

and then the Pact Broker would use its existing configuration to return the correct fallback.

[bethesque]

I don't recommend using the fallback option at all. I wish I'd never implemented it actually. I recommend use two separate selectors, one for the main branch, and one for the feature branch. If there's nothing that matches the feature branch, it just won't include anything.

The reason for my advice is, if you use the fallback approach, you can make a pact pass that passes the feature branch, but breaks master (which is not usually what you want). If you always have master, and optionally have a feature branch then you're always guaranteed to be compatible with master.

[adamrodger]

What you're saying makes sense if your workflow is a trunk based development one, where you only have a main branch and feature branches, and only have one version at the end (like running a website).

However, people have lots of different workflows where this feature would be very useful - imagine a product where you need to keep branches for supported old versions so you can release patches for them.

You wouldn't want your release/1.x branch verifying against your main branch because it's never going to be merged back. Main is perfectly free to make breaking changes and that's fine.

However, if we don't support fallback branches then this makes creating one of those support branches really annoying - as you take the branch you have to swap the branch it's verifying against from main to release/foo.

However, with fallback branches you can set it to grab from an environment variable like GIT_BRANCH and fall back to main, then you never need to do that admin. All the release/foo branches will verify against each other, all the main branches will verify against each other, and you don't need to make any code changes when you release.

This feature request is just a natural augmentation to that each provider doesn't need to know the main branch of each consumer, or be updated if a consumer changes the main branch name.

On Fri, 15 Oct 2021, 04:25 Beth Skurrie, @.***> wrote:

I don't recommend using the fallback option at all. I wish I'd never implemented it actually. I recommend use two separate selectors, one for the main branch, and one for the feature branch. If there's nothing that matches the feature branch, it just won't include anything.

The reason for my advice is, if you use the fallback approach, you can make a pact pass that passes the feature branch, but breaks master (which is not usually what you want). If you always have master, and optionally have a feature branch then you're always guaranteed to be compatible with master.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pact-foundation/pact_broker/issues/516#issuecomment-943955921, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD4FKQB7ATCZIJ4ITYPLW3UG6NK7ANCNFSM5GAMUJ3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[bethesque]

Thanks for that explanation. You've convinced me!

Btw, you can skip the "latest": true when using the branch. It would never make sense to verify every pact for a branch, so latest defaults to true if you set the branch name.