@kibidev hey 👋 just wanted to ask a question about this - how do you anticipate it will affect the changelog generation and tagging? If you run from multiple subdirectories, won't you get multiple releases/tags, and the versions for each subproject jumping outside of what the commit semantics imply?
E.g. in this structure:

repo
|---- projA  # at v1.2.0
|---- projB   # at v1.1.0

If you configured version_source = "tag". When you release a feat in projA won't you get projA at a tag v1.3.0, and if you then do a fix in projB and rerun, with this setup you'll get a v1.3.1 instead of v1.1.1?
Even if you format the project names into the tags, projB would jump from projB-v1.1.0 to projB-v1.3.1 since PSR will identify a fix within projB's directory, but get_latest_release_version will return v1.3.0 since it considers the entire repo history?

I think it would help to have some tests to demonstrate the behaviour a bit, and some more documentation about how this would impact tagging overall 🙂

@bernardcooke53 Hi!

how do you anticipate it will affect the changelog generation and tagging? If you run from multiple subdirectories, won't you get multiple releases/tags, and the versions for each subproject jumping outside of what the commit semantics imply?

I have followed a setup as in
https://python-semantic-release.readthedocs.io/en/latest/automatic-releases/github-actions.html#multiple-projects
In order not to get problems with the tagging, each sub-project needs a unique tag_format configured. This will fix releases as well, but the "lastest release" featured will only be one of the project, whichever was generated last.

I have not tested with version_source = "tag", but this PR does not change any default behavior. I'm not sure if filtering out commits for the sub directory is relevant for version_source = "tag" or not.

Regarding documentation, I would suggest updates the the documentation for mult projects. Any other suggestions?

Regarding tests, I probably will not have time to add this very soon, but I will try when I have time to spare.

@kibidev

I have followed a setup as in
https://python-semantic-release.readthedocs.io/en/latest/automatic-releases/github-actions.html#multiple-projects
In order not to get problems with the tagging, each sub-project needs a unique tag_format configured. This will fix releases as well, but the "lastest release" featured will only be one of the project, whichever was generated last.

That helps understand the use-case - thanks! I think the scenario I outlined above is applicable in that case, so as you say adding some documentation explaining the limitations might help. Something like the note for commit_author explaining that use_only_cwd_commits doesn't provide full monorepo support with the explanation you just gave above 🙂.

I do think that there's a danger when used with version_source = "tag" that this introduces some unexpected behaviour with respect to version increments for individual projects - while you are able to filter the commits down to just those that have objects in the tree from within a subpath, the chain of function calls when using version_source = "tag" (get_last_version and get_current_(release)_version_by_tag are the most relevant) don't filter down by tags only on such commits. For that reason, I think it would be much safer behaviour to change this line from

    if config.get("use_only_cwd_commits"):

to

    if config.get("use_only_cwd_commits") and config.get("version_source") == "commit":

That would also deserve a note in the docs that use_only_cwd_commits will be ignored unless version_source = "commit" too.

Ideally we'd implement a full solution for #168 but that's a lot more effort - before that happens, I think this is an ok halfway house.

@bernardcooke53 thanks for the suggestions, I have updated the code and added a bit more documentation now.

I have (finally) revisited this PR and evaluated the possibility to add tests.
It seems to me that the relevant function (get_commit_log from vcs_helpers.py) is currently tested only on this repository.
To test the functionality from this PR in this way is not possible, as this is not a mono repo (or have suitable sub folders to get predictable commit logs from).
In most other relevant tests, get_commit_log itself is mocked, and so it would not make sense to test this PR in a similar way.

The remaining approach would be to write new tests that would mock git.Repo or similar to test get_commit_log. In my opinion the value from this would also be minimal, as it would mostly just test the mock.

I will probably not add any testing to this PR, for the way forward I can suggest one of:

• Close this PR and do not add the functionality (I'll use a fork for the functions I need)
• Merge without adding more tests
• Someone suggest a concrete way to tests the functionality, and I'll write the tests

@bernardcooke53

Thanks for coming back to this @kibidev - I agree with your assessment, it's a pain to test this thoroughly with the current tests.
Given it's a relatively simple change I think it's ok to merge - but I'm not going to include this in v8, at least initially, I really want monorepo support to be done "properly"