How to deal with Pact Broker's branch feature and Git's annotated tags?

[michaelholtermann]

I'd like to ask for some advice or support on some possibly weird topic.

As you may know, Git supports two kinds of tags: Lightweight Tags and Annotated Tags, see https://git-scm.com/book/en/v2/Git-Basics-Tagging:

• Lightweight Tags are a pointer to an existing commit, which is related on a branch, usually.
• Annotated Tags are full objects with a message that can be signed, but they are not associated with a branch.

For our Pacts, we are using the --branch flag when verifying pacts as well as when publishing new pacts.

Now, if someone creates an Annotated Tag, there is no branch information available. Github Desktop creates Annotated Tags by default, without an option to disable them.

How do you deal with that situation?

[bethesque]

What do you need to use the annotated tag for in regards to Pact?

[michaelholtermann]

Hi @bethesque,

if I understand the concept of tags and branches in Pact Broker right, pacts should be published to the Pact Broker

• with the version of the consumer
• and the branch of the consumer.

The branch is used to differentiate between released pacts (associated with final version of the consumer) and pending/work-in-progress pacts during the verify step.

AFAICS, this is impossible when annotated tags are in use.

Maybe I miss a configuration or trick or something else, but if not we should not use annotated tags at all when pact broker is used. This may break release workflows that rely on annotated tags.

Alternatively, I could omit the --branch parameter for the publish step, but then I don't know how to differentiate between pending and final pacts?

[bethesque]

I want to clarify this point, as I'm confused by it.

The branch is used to differentiate between released pacts (associated with final version of the consumer) and pending/work-in-progress pacts during the verify step.

What do you mean by a released pact? Do you mean the pact that belongs to the version of the consumer that is deployed or released to production? Because that one should be marked using the record-deployment or record-release command documented here

I'm not very familiar with the use of annotated tags in a release process, so can you let me know if this is how it works?

• create branch
• publish pact with git sha and branch
• merge branch
• publish pact with new git sha and branch from main branch
• approve release
• create annotated tag
• publish pact with git sha (but no branch
  ??)
• at this point I would expect to run record deployment/release for the git version that has the annotation, but given you haven't mentioned it, it sounds like you're not?

If you do this, and configure your consumer version selectors to verify the deployedOrReleased: true, then you'll have a working set up.

[michaelholtermann]

Hi @bethesque,

I'm sorry for the late reply.

You are right, record-deployment and record-release are not in use, yet. So thanks a lot for that hint, I think this will solve my question finally.

With "released pact" I referred to a consumer that creates a release build in CI (e.g. v1.0.0), which typically happens on main branch.

But you are right, this does not necessarily mean that this release is deployed; the deployment is a separate step, handled by the record-deployment command.

To summarize:

• for annotated tags there is no branch available, at least not in Github Webhooks that tiggers my CI
• this has nothing to do with pact-broker, because
  • it is possible to publish pacts without the branch information,
  • it's up to me if I would either omit the branch in publish in these cases, or forbid annotated tags
  • I may need to figure out how verify works when branch is not set, but that's not a problem
• publishing and verification runs on "test-time" so to say, but the can-i-deploy decision relies on record-deployment.

[bethesque]

I think record deployment or release will be your best bet (depending on what you're doing with your artifact you will want one or the other, or maybe even both).

I take it that the annotated tag is not for a commit that has previously had a pact published for it (because otherwise you wouldn't have a problem).

If you don't set a branch or record deployment/release, then, as you say, your pacts will be orphaned, and there will be no way of verifying them.

While I recommend using that deployment/release approach, note that pact broker tags are still supported. You could published with a tag like "annotated" and then verify all/latest pacts with the annotated tag, depending on your use case. But that's a fall back case. I can't see anything stopping you from using deployed/released.

[michaelholtermann]

Yes, I think I got, thanks a lot for your support.

Best regards,
Michael