pact_broker-client icon indicating copy to clipboard operation
pact_broker-client copied to clipboard

feat: can-i-merge

Open bethesque opened this issue 2 years ago • 3 comments

Added support for can-i-merge, which is the can-i-deploy query where the "target" is "the main branch of each pacticipant with which the specified pacticipant version integrates".

I'm a bit dubious about this feature, tbh, because I feel that it is better to use the normal can-i-deploy query from a feature branch ("can this version be immediately deployed") because if it can be merged, but not deployed, you've then put changes into the main branch that can't be deployed, and will block any other feature from being deployed.

bethesque avatar Oct 03 '22 22:10 bethesque

See https://pact-foundation.slack.com/archives/C9VPNUJR2/p1660064342499599

The one good reason I can think of to use can-i-merge is that the users haven't got deployment recording happening yet, and so they want to use can-i-merge as the intermediate step.

bethesque avatar Oct 04 '22 03:10 bethesque

Hmmm, dubious as well

Our pipeline defined such a away that every PR branches will be merged into master branch then we deploy the master to dev environment. I think I can validate a new contract can-i-deploy with --branch PR BRANCH before it gets merged with master

Why/how is that different from the regular flow of checking if the feature branch is compatible with the mainBranch and the deployedOrReleased versions?

The OP even mentioned

I already have can-i-deploy checks for dev environments and prod but I didn't have a check (can-i-deploy) for feature branch to master for consumers.

so by checking can-i-deploy to an env on the feature branch, it would guarantee that you leave the main branch in a place where it can be deployed

if it can be merged, but not deployed, you've then put changes into the main branch that can't be deployed, and will block any other feature from being deployed.

yeah that doesn't seem ideal.

The one good reason I can think of to use can-i-merge is that the users haven't got deployment recording happening yet, and so they want to use can-i-merge as the intermediate step.

Could they use?

 pact-broker can-i-deploy --branch

which would be the equivalent to

 pact-broker can-i-deploy --tag latest

YOU54F avatar Oct 04 '22 18:10 YOU54F

Could they use? pact-broker can-i-deploy --branch

The can-i-deploy command currently doesn't support the "target" selector of { mainBranch: true } which is the way you specify "can I deploy version x with the main branch of each integrated apps" (our current "target" options are "to environment X" (--to-environment), "with the latest version of each app" (--latest), "with the latest version tagged x" (--latest X) and "with all versions tagged x" (--all X).

We could add can-i-deploy --pacticipant X --version Y --with-main-branches or similar, but I think that's less clear for the user.

bethesque avatar Oct 05 '22 04:10 bethesque

Hey @bethesque is this good to go?

What do you need from me if anything to make it go go

YOU54F avatar May 03 '23 19:05 YOU54F

because if it can be merged, but not deployed, you've then put changes into the main branch that can't be deployed, and will block any other feature from being deployed.

I can see the argument, however, that's what can-i-deploy is for. This also assumes teams are following those CD practices, where the mainline of code is always deployable. But that's not always the case. For teams doing more complicated workflows (e.g. Gitflow) with release branches, etc. this would be a helpful addition. The main branch isn't where deploys come from, but knowing it's compatible is helpful.

It's also useful for BDCT which doesn't have the consumer selectors to check against main branches and deployment environments.

They could always use the can-i-merge in conjunction with can-i-deploy if needed.

mefellows avatar Aug 03 '23 23:08 mefellows