Looking for some advice on the broker - we current...
# pact-broker
a
Looking for some advice on the broker - we currently store all of our webooks in a git repo so that we can GitOps them (i.e. they're the source of truth). However, way back when I originally made this the only way to make this work was by writing a script that first deleted every single webhook and then recreated them all. The webhooks get non-determinstic random IDs, so there's no way to check if a hook already exists. It works really nicely though, because if you create a new API then you just add an entry into the hooks repo and the CI creates all the hooks for it automatically. The only bit that's not nice is it takes a while to run because there's so many API calls deleting and recreating hooks, and once you delete a hook you lose all the history for it. Does anyone know of a better way to manage webhooks?
The meat of the script is this - one function to delete all the existing webooks and one to auto-generate all the hooks, but like I say it's slow and wasteful to delete and then recreate them all, if anyone knows a better way:
Copy code
function delete_existing_hooks() {
    echo "Deleting all existing webhooks"

    curl --silent "$pact_broker_base_url/webhooks" | jq -c -r '._links."pb:webhooks"[].href' | while read url; do
        url=$(trim_control_chars "$url")

        echo -n -e "    Deleting webhook ${cyan}${url}${reset}... "
        curl --silent -f -X DELETE "$url" \
            && echo -e "${green}Success${reset}" \
            || echo -e "${red}Failed${reset}"
    done
}

function create_new_hooks() {
    pushd webhooks/ > /dev/null

    for webhook_file in $(ls *.json); do
        echo -e "Processing webhook ${cyan}${webhook_file}${reset}"

        provider="$(jq -r .provider.name $webhook_file)"
        escaped_provider=$(escape "$provider")

        consumers_url="$pact_broker_base_url/pacts/provider/$escaped_provider/latest"

        curl --silent "$consumers_url" | jq -c -r '._links."pb:pacts"[].name' | while read consumer; do
            consumer=$(trim_control_chars "$consumer")
            echo -n -e "    Creating hook for provider ${cyan}${provider}${reset} from consumer ${cyan}${consumer}${reset}... "

            hook_body=$(jq --arg name "$consumer" '{consumer:{name:$name}} + .' "$webhook_file")

            curl -f --silent -X POST -H "Content-Type: application/json" -d "$hook_body" -o /dev/null "$pact_broker_base_url/webhooks" \
                && echo -e "${green}Success${reset}" \
                || echo -e "${red}Failed${reset}"
        done
    done
}
m
There is a create-or-update-webook command on the pact-broker CLI which supports a user defined uuid as the id. That's probably what you want so you don't lose the history
That being said, I would tend to have the webhook live with the code that needed it. I.e. the provider (in most cases) and not centrally
a
Ah a create or update endpoint? I hadn't found that on the HAL browser, so I'll check that out. Perhaps it didn't exist when I did this ages ago
👍 1
m
I think the API accepts a PUT tho, I'd need to check
a
Yeah if you can specify an ID of your own that'd be good 👍 I'd just hash the consumer and provider name or something
👍 1
b
@Adam Rodger (pact-net) the create or update where you supply your own ID was written specifically for this usecase.
❤️ 1
a
Many thanks for this by the way. I've just rewritten our hook installation script and it's now much better! We have stable IDs (using a v5 uuid with sha1 hashing) and we don't have to delete all hooks when installing either. Whilst I was there I noticed the new feature where the consumer name is optional, so I've also changed it to just create provider-level hooks, which massively reduces the need to run the webhooks setup script anyway given it's now only needed when there's a new provider
b
@Adam Rodger (pact-net) exactly!
a
Yeah, embarrassingly we were on a broker version that didn't support either of those options until about 3 weeks ago 😂 We were waaaaay behind, and I'd not rechecked my bash since then
b
lolz. that's been a while. I reckon I may have added the new endpoint before I had my 6 year old kids 😆
a
Ha, ok yeah not quite that long 😂 I think our version was 3 years old