Closed linkdd closed 4 years ago
Thanks for your PR @linkdd!
I'm thinking of what would be the right pattern to use here. We already have an exclude option which implicitly suggests that excluding is enabled. Shouldn't we do the same with whitelisting, and then rename it to included
? Similar to the syntax that is used in Azure DevOps (and other CI systems) for defining what branches should trigger CI. https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml
The modification is done, thank you for the quick reply :)
Have you thought about the behavior if a branch is both included and excluded? Are they mutually exclusive and should it be handled as an exception or what do you think?
Also, could you update the specs and documentation? Let me know if you need help! Thanks again.
exclude
excludes deletion based on the source branch of the PR.
What I wanted with the whitelist (include
) was to enable deletion based on the target branch of the PR.
It might be interesting to expose the workflow at my current workplace:
(fix|feature)/*
is merged in dev
master
dev
branch is reset from the master
branchWe would like to automatically delete the (fix|feature)/*
branch only when it is merged in master
.
I will gladly update the specs and documentation once we agree on the code :)
We could do the following:
patterns:
- target: master
delete_on_close: yes
- source: *
delete_on_close: no
Where the first matching pattern is applied.
If the PR's target branch is not listed in the whitelist, the source branch will not be deleted.