Feature request: Azure DevOps tasks for Pact Broker interaction

[basdijkstra]

I just discovered the incredibly useful PactFlow GitHub Actions repo.

As so many (potential) customer will likely be using Azure DevOps, not GitHub Actions, are there any plans to build something similar for Azure?

Azure DevOps does support this, by the way.

[JP-Ellis]

I think that's a great idea! In fact, I wonder if there might even be a 'meta-action' we can use to then provide support to most major platforms, such as GitLab CI, CircleCI, BitBucket Pipelines, etc.

[mefellows]

Definitely worth looking into Bas. In fact, after your post I had somebody reach out asking if they could contribute (I've directed them here in case they're both willing and able).

@JP-Ellis - could you elaborate a bit further on what you mean by "meta-action" in this context?

There is also https://circleci.com/developer/orbs/orb/trustedshops-public/pact which would be a decent base to build from.

[JP-Ellis]

Building for and supporting multiple CI paradigms is not a unique problem; and I'm pretty sure I've come across a tool that purports to allow building a single pipeline that can be used across most/all of these. Think of it a bit like the way Terraform can target multiple cloud environments and is a more general form of AWS CloudFormation, Azure Bicep (and whatever Google Cloud uses).

I have not used such a tool, and I cannot remember the name right now; but I'm fairly sure it does exist.

[basdijkstra]

That’s great, I really think you would make a lot of Azure shops happy. One of my current clients is definitely one of them.

Right now they have to manually install the Pact CLI every build, and set the PATH manually before they can invoke the CLI tools.

Plus it’s harder to explain to people who are less comfortable with pipeline wrestling :)

I don’t think I can contribute much in terms of development but I’d be more than happy to test and promote if such a task should see the light.

[YOU54F]

Regarding meta actions, the pact cli installer supports automagically adding to your path, if one is running on github actions, or cirrus ci, this could be extended for other CI systems.

https://github.com/pact-foundation/pact-ruby-standalone/blob/22b3939b74b1a816192f3935c230e909f8d82c8b/install.sh#L110-L115

The github actions, action.yml automatically adds it to the path for windows systems here

https://github.com/pactflow/actions/blob/af355f07a2e9af31a1818870d3e566f4952d0763/action.yml#L10

A meta-ci action for me, would just be that, exposing the full cli set to users and then can use to their hearts desires, rather than requiring bespoke actions which need creating, and maintaining for parity.

However I appreciate that users of each CI system, normally want to use the convenience methods available, for re-usable actions, see Actions Marketplace, rather than doing scripting simple things themselves.

It reduces a maintenance aspect, by offsetting it to someone else (in the hope they maintain it), but introduces a security vector, as there is potential to run unvetted code.

Additional, the pact broker client supports retrieving env variables from many different CI systems, https://github.com/pact-foundation/pact_broker-client/blob/4cefb18ac650b52ee5a1ca4640b456106406ab82/lib/pact_broker/client/git.rb#L4-L17, as part of its auto-detect-version-properties

All that aside, our current guidelines for Azure could be improved, and for other CI systems, as part of our recommended workflow.

We have a few examples which are incomplete, or do not follow Pact Nirvana latest best practises

• Azure provider workflow
  • Based on tags, and only considers provider changes https://github.com/pactflow/example-provider-dotnet/blob/master/azure-pipelines.yml
• Azure webhooks
  • Only for superceded event pact_changed https://docs.pact.io/pact_broker/webhooks/template_library#azure-devops---trigger-build
• Azure guidance for running a pact broker adding azure files for app service deployment docs.pact.io#349

I've been having a go at looking at some of these

• azure consumer workflow
• azure provider workflow
• Triggering webhooks

[YOU54F]

Right got a set of Azure Reusable templates, that mirror the GitHub actions commands, and introduce the rust based tools

https://github.com/YOU54F/azure-pipelines-templates

There are some caveats to usability, compared to GitHub actions

• You need to explicitly setup an azure service connection to github, to process templates
• Templates are processed, and do not include any associated files/scripts from the template repo, so the user must explicitly checkout the template, in their workflow. This has a knock-on effect, of requiring the user to explicitly checkout their own code too.
• variables can be used, to avoid duplication across steps. These are propogated as environment variables, but are automatically converted to uppercase, so this needed to be catered for in the scripts
• pact broker convenience commands all use the docker cli.
• I haven't tested these on macos/windows based client workflows. I don't think macos images on azure include docker.

There may be a few rough edges, and there is no current test suite in the template repo, but there are e2e demonstrations of CDCT/BDCT and webhooks.

https://github.com/YOU54F/azure-pipelines-templates?tab=readme-ov-file#examples-of-real-world-use

[basdijkstra]

That’s awesome work, Yousaf. Can’t wait to give these a try soon.

Is this still work in progress or is this what it’s going to look like? Just curious :)

[YOU54F]

Is this still work in progress or is this what it’s going to look like? Just curious :)

Should be usable as is, and is being tendered for feedback.

It may be that the caveats wont fly for azure users, as we may need to explore custom task extensions as per the link you provided in the OP (I am unsure however if they solve some of caveats mentioned above)

[JP-Ellis]

Thank to Matt, I finally remember what the meta-CI language was: Dagger

Though it seems to have evolved a bit since I last looked at it (now featuring... AI/LLMs 😆)