Repository navigation
Monorepo support #168
Description
As suggested here, it would be useful to have the option to differentiate between multiple projects within the same repository when posting changelogs.
I think the most plausible solution is to pass some text on the command line which is appended before the title of the release, such as --project "Foo". This would create a title of Foo vX.X.X. Alternatively, more customization of the ordering could be given using some sort of format string.
Obviously, if the option is omitted then the behavior would be the same as it is now.
Activity
KingDarBoja commentedon Feb 14, 2020
I forgot to mention, the generated assets on the releases tab contain the entire github repo instead of build artifacts per package. Should be good to provide extra documentation about this in some example.
EDIT Looks like it is the default behaviour of GitHub repos and packages. Would be awesome if there is something like semantic-release-monorepo which seems to be what I am asking for 🤔
Cheers!
danth commentedon Feb 14, 2020
Looking at that link you sent, maybe it'd be better to add more comprehensive support for monorepos instead of just the changelog titles.
[-]Changelogs for multiple projects within one repository[/-][+]Monorepo support[/+]19 remaining items
wyardley commentedon Jan 22, 2025
I would think that the scopes should be specific to each application within the project? And if you had a single commit that applied to scope x in project 1 and scope y in project 2, you’d omit the scope or use separate commits? It would be possible to use merge commits or rebase merge to keep atomic commits within a single PR.
I also don’t think multiple scopes are supported in the conventional commits or angular style.
codejedi365 commentedon Jan 22, 2025
Agreed. From the Conventional Commits Spec:
This does not say anything about multiple scopes. And my recommendation is to keep each change atomic (even if one change causes a runtime-error in the other) just realize that the next commit to fix the function signature in the subsequent commit is required and both commits must be pushed/merged together.
Soon I will have support for parsing squashed commits so it will not matter how you merge them into the release trunk.
codejedi365 commentedon Jan 22, 2025
Although you can get this might work, now you will need to consider what variant did you test and which sha are you releasing. I probably still have this problem with how PSR works but at least it was better than before. If you see the GitHub Actions example, I check out a specific sha (the one that was started with the workflow) and then move the branch to the current head so that the PSR release branch works. The problem I ran into with multiple PRs merged at once is that the first PR would pull master in the release job which was already bumped with the 2nd merged PR but wasn't what was tested with that workflow. Not good, could of been bad.
So a concurrency flag would probably need to be set across the entire workflow, or you can go with the no commit environment (tags only) like described in #1149.
I think instead of 2 workflows you are better off using multiple subsequent jobs like described in #1132. Hopefully i can also add the GitHub action output of the sha value which might also help in certain cases.
github-actions commentedon Mar 23, 2025
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
codejedi365 commentedon Apr 22, 2025
Still under development although the development has stalled for the time being.
github-actions commentedon Jun 23, 2025
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
codejedi365 commentedon Jun 26, 2025
PR #1143 provides a conventional commit parser for monorepos that can currently be used as a custom parser. It has been manually tested and is waiting automation testing for resolution. This should be one of the major steps to completion of monorepo support.
akselerando commentedon Sep 22, 2025
Is there an overview/roadmap for the remaining features for full monorepo support?
I see in the new documentation that PSR configs are required in each package. Are there plans to support configuration only at the root level?
codejedi365 commentedon Sep 22, 2025
There is a Milestone dedicated to monorepo support that connects multiple issues together which is the closest thing to a roadmap.
I anticipated this request would be asked. It's the primary reason why this ticket wasn't closed. And I needed to add support for monorepos in the other 2 commit parser types. It will be a while though for a consolidated workspaces configuration as the current config is undergoing a refactor.
github-actions commentedon Dec 22, 2025
It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?