filter commits by scope

[W1M0R]

When svu considers commits that will contribute to the next version, it would be nice to be able to tell svu to only look at a certain set of commit scopes, e.g.

.svu.yaml:

scopes:
- bla1
- bla2

git history:

fix: example 1
fix(ex): example 2
fix(bla1): example 3
fix(bla2): example 4

Given the history above, only example 3 and example 4 will contribute to the version bump calculation.

Related issues:

1. Add support for optinal scope in commit message #177

[djgilcrease]

Can you explain a concrete example of why you would not want a version bump on scope-a vs scope-b, and you could not use chore(scope-a): ... to achieve the same thing?

[W1M0R]

Can you explain a concrete example of why you would not want a version bump on scope-a vs scope-b, and you could not use chore(scope-a): ... to achieve the same thing?

Imagine a monorepo with two projects: my-go-cli and my-node-cli. They are independent cli utilities, with different tags in the monorepo, e.g. my-go-cli@v1.1.0 and my-node-cli@v5.2.1.

The commit history of the project could look like this:

1. chore(my-go-cli): minor edits
2. chore(my-node-cli): minor edits
3. fix(my-go-cli): a fix
4. fix(my-node-cli): a fix

Commit 1 and 2 will have no effect on the version bumping of either tags. Commit 3 will bump my-go-cli and commit 4 will bump my-node-cli.

I'm not sure how using chore(scope-a) can be used to achieve project-specific version bumping based on scope.

@djgilcrease Does that answer your question?

[W1M0R]

Here is an example of an issue I'm currently facing:

svu next --tag.pattern "my-go-cli@[0-9]*" --tag.prefix "my-go-cli@"
found minor change: 0df41a9982ebe880691030758a65785a12719a32 feat(my-node-cli): new ui experience
my-go-cli@1.7.0

In this case, svu detected a minor bump, but I know that that commit shouldn't contribute to the bump, because I can see in the scope of the commit, that it is not relevant to the my-go-cli utility.

It is possible that the log.directory of svu might not be specific enough in this case. But the sentiment remains: the intention of the commit author is that that commit should contribute to the version bumping of the my-node-cli tag and not the my-go-cli tag, even if some files belonging to my-go-cli were touched in that commit, those changes should at most be interpreted as chores, and definitely not as a feature bump on my-go-cli.

[djgilcrease]

Would the pattern in #224 (comment) work?

[W1M0R]

@djgilcrease That is more or less how I am doing it already, and I can confirm that doesn't solve the issue for me, I still get commits contributing that shouldn't be contributing. Being able to filter by scope will make it easier to target specific commits.

This is my .svu.yaml file:

verbose: true
tag.pattern: "my-go-cli@[0-9]*"
tag.prefix: "my-go-cli@"
log.directory:
  - "."

For now I'm dropping svu, in favour of a simple python script to filter the commits by scope, determining the bump type and bumping the version.

[djgilcrease]

I am not sure how your mono repo is structured, but if my-go-cli and my-node-cli are in separate directories you could do this once #228 is merged

my-cli/
    go-cli/
      .svu.yml
       ...
    node-cli/
     .svu.yml
      ...

my-cli/go-cli/.svu.yml

verbose: true
tag.pattern: "my-go-cli@[0-9]*"
tag.prefix: "my-go-cli@"
log.directory:
  - "."

my-cli/node-cli/.svu.yml

verbose: true
tag.pattern: "my-node-cli@[0-9]*"
tag.prefix: "my-node-cli@"
log.directory:
  - "."

MODULES="go-cli node-cli"
for module in $MODULES; do
	MCV=$(svu c --config ${module}/.svu.yml 2>/dev/null || echo "${module}/v1.0.0")
	echo "${module} current version: ${MCV}"
	MNV=$(svu n --config ${module}/.svu.yml 2>/dev/null || echo "${module}/v1.0.0")
	if [ "$MNV" != "$MCV" ]; then
	    git tag $MNV
	fi
done

Having separate configs in the directory that owns the versioning ensures that only changes to that directory are considered for version bumping.

[W1M0R]

Thanks for the detailed example.

Imagine the problem where a commit changes the README.doc files across various project folders, while implementing a fix for a specific project. This is not uncommon, and a natural way to improve documentation while working on a fix for a specific project. That would trigger a bump for all the projects involved, since svu can't disambiguate using the scope "fix(my-go-cli)".

If #228 allows filtering commits by filetype, e.g. .go, .js etc., then that would help to ignore "irrelevant" commits.

So although your fix will help in the general sense, I think this scope-based approach is still a useful feature for monorepos. Scopes can already be used by pipelines to decide whether a job should run, or by tools for changelog generation, so using that same principle for version bumping in monorepos makes a lot of sense.

[djgilcrease]

will have to think on this and if see about adding a log.directory.ignore, but I am fairly sure you can already do

log:
  directory:
    - "./*.go"
    - "./**/*.go"