feat: add pathFilter option

[bogaertg]

I need to exclude specific path in commit analysis.

Example:

project
│   README.md
│   file001.txt    
│
└───folder1
│   │   file011.txt
│   │   file012.txt
│   
└───folder2
    │   file021.txt
    │   file022.txt

I want to use specific configuration for folder1, another for folder2 and one for my root folder excluding folder1 and folder2.
With pathFilter option, i can run multiple times semantic release with specific configuration to trigger release for folder1, folder2 and root folder.

[bogaertg]

@pvdlg @boennemann 🙏

[bogaertg]

@travi 🙏

[travi]

semantic-release does not support monorepos and adding support is not on our short term roadmap. see #193

[bogaertg]

I understand why you dont want to support monorepository by default.
I a very complicated approach which depending on implemation in developpers team.
However, i thought that adding a regex for filtering commit by file path was a good trade-off because of :

• this is no dependency between semantic-release and monorepository approach
• this is no a breaking change for semantic release
• with the semantic-release monorepository plugin, we have to use lerna and modify folder structure in repository
• there is no support for custom configuration in semantic-release monorepository plugin.
• it allows a flexible utilization of semantic release for mixing differents release in a same repository

for information, here is my usecase :

In a github repository, i have a spring boot app at top level and one folder `terraform' with some terraform code associated to my app (ex: kafka topic, BDD, ...)
Currently, i use the same release pattern for both. When i update terraform code or my spring boot code, i have release like vX.Y.Z.
I wouldlike to have release like vX.Y.Z for my spring boot code and vX.Y.Z-terraform for terraform code.
In my CI, i want to use different semantic-release configuration depending on commit path modifications.

Regards

[travi]

i understand that those sound like good trade-offs from your perspective. however, there are other considerations that we need to keep in mind as maintainers.

• does this enable a workflow that we do not officially support?
• will users open support requests for workflows that have been enabled but we dont intend to consider supported, when we already have a hard time keeping up with support requests for supported workflows?
• does this enable workflows beyond the one you are asking for that will make even more workflows possible that we dont want to consider supported
• if we make changes to this feature in the future that happen to break a subset of these unsupported workflows, will that upset our users because they have become dependent on them, even though they are unsupported?

this is a big part of why we have to be careful about accepting additional functionality or increased flexibility of existing functionality. we see support for monorepos as a very complex problem and an opportunity to add highly increased complexity and lots of additional workflows that are not supported today. if/when we ever add such support, we want to add it in a way that satisfies the specific workflows that are intended to be supported properly and that we can have confidence it them working well. adding only partial support that leaves lots of opportunities for our users to shoot themselves in the foot is not the way we want to approach this type of a problem.

[wojtiku]

For the people looking for a solution to this problem like I was.

I was able to filter out irrelevant commits by using this shareable configuration: https://github.com/folke/semantic-release-commit-filter