Hi there. Does pactflow have the ability to clean up old versions? I see the self hosted pact broker has this ability docs.pact.io/pact_broker/administration/maintenance

👋 We do clean up old versions - it’s part of the managed service, it’s not something we make configurable. Are you seeing problems or anything or just wanting to know a bit more on the topic?

@Matt (pactflow.io / pact-js / pact-go) Hi matt, sorry for the late reply ha. I completely forgot about this and went on holiday… I was just noticing that I have a lot of old versions sitting on the dashboard. How much history do you keep?

Hello! No worries, I just got back from leave myself (hope you had a great break!) We don’t publish the specific cleaning schedule and configuration as it can be dynamic, but basically we try to keep the platform query time optimised. Typically we keep things for up to 180 days, but can be as low as 90 days depending on volumes etc. I’d be interested to know - what would be the minimum amount of data that would be useful to you? Would it be helpful to expose some control over what you want to retain? (e.g. number of versions rather than time-based)? Does keeping data for longer make it harder to see what’s happening?

Ah understood! We work off of deployments; we only ever have one thing deployed to prod/staging at a time for each of the applications. I think maybe being able to control the time the versions are retained would be nice, just to reduce clutter. Not all that important though!

So branches is a good one. As of tomorrow (I believe) we’ll also start removing branches. We needed a way to measure how old they were, based on last updates within the branch. Given we didn’t have that information, we needed to ” This was added in github.com/pact-foundation/pact_broker/pull/912 (and extended in PactFlow). We needed to run this for a few months before we could enable it, otherwise we may delete branches that < the proposed branch cleanup cutoff date (90 days). So as of tomorrow, branches will start to be cleaned up automatically

Yeah, I’ve a step that deletes the branches after the pact has been marked as deployed, it’s been helping a lot, except for chore branches - because the deployment pipeline doesn’t run for chores, so chore branches linger. I have to go through and delete these via the CLI, but if they’re getting cleaned up automatically from now, I won’t bother

In your case, do you think it would useful to be able to specify a duration in which data can be cleaned (e.g. after 30 days, delete branches that haven’t had updates, and remove intermediate contract versions that aren’t linked to active branches/deployments/etc.)? Or would a better way just be “keep the last X versions” for contract data, and have duration for branches? Or do you think the automated clean is better? As to your other point, would it be easier/better to have your VCS system trigger an API call to delete the related branch from PactFlow as soon as the branch is merged/deleted?

In your case, do you think it would useful to be able to specify a duration in which data can be cleaned (e.g. after 30 days, delete branches that haven’t had updates, and remove intermediate contract versions that aren’t linked to active branches/deployments/etc.)?

This would be cool.

As to your other point, would it be easier/better to have your VCS system trigger an API call to delete the related branch from PactFlow as soon as the branch is merged/deleted?

I already do this for the branches that trigger a version bump, in our deployment workflow in GH actions, i.e: In my

pr.yml

PR with feature change

feat/new-stuff

-> publish pact with git sha • merge, branch gets deleted in GitHub This triggers

deploy.yml

• in PF, mark as deployed to staging • Delete branch

feat/new-stuff

using the appropriate git sha from the PR I’ve actually had another look and my past self seems to have gone the route of not publishing pacts for chore commits because they’re not linked to any deployments, so I don’t have the issue of chore branches lingering. I think what I have works somewhat thinking

ah, that makes sense. A lot of our branches are transient renovate branches, so we do feel the pain ourselves. Thanks for sharing, we’ll take it into consideration if/when we look to expose user-level controls.