-
Notifications
You must be signed in to change notification settings - Fork 258
feat(parser-conventional-monorepo): add new conventional-commits standard parser for monorep 8000 os #1143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
feat(parser-conventional-monorepo): add new conventional-commits standard parser for monorepos #1143
Conversation
a662a1a
to
16e9e8f
Compare
Added docs. Realizing slowly I need this feature ✊🏼 |
de596f2
to
5f0292f
Compare
8463c9b
to
1335617
Compare
be01c3c
8000
to
d7dd9b8
Compare
This PR is stale because it has not been confirmed or considered ready for merge by the maintainers but has been open 60 days with no recent activity. It will be closed in 10 days, if no further activity occurs. Please make sure to add the proper testing, docs, and descriptions of changes before your PR can be merged. Thank you for your contributions. |
Would love to this this being merge as we are facing the issue of versioning being calculated even on commits not related to the sub project. Any chance on having this merged "soonishly"? Thx! |
@spastorclovr, thanks for the priority request comment, I've been working on other things as the complexity of validation is not trivial. Will try to get it merged over the next month. Meanwhile, you can add it as a custom parser into your repository with your config pointing to your repository file. It is manually tested and validated by myself and @marc-at-brightnight for his repo so it should work for your environment today. |
Thank you for taking the time to respond! I Will try as suggested. Thx for this project! (currently using it with dagger.io which needs a ready-to-use function which I will do ASAP) |
e9a1908
to
d3856b5
Compare
Dear developers, |
@markdoerr, please see comments above. Not ready yet to add it to the baseline but it is available as a custom parser today. |
I am eagerly anticipating the release of this feature. In the meantime, how do I use the monorepo-parser as a custom parser? |
Review the documentation on how to set a custom parser value. And you can use this demo repo as well mirrored off of another contributors described monorepo structure. It supports file path matching as the primary mechanism for differentiation of projects then as a secondary filter, the use of scope prefixes. |
d3856b5
to
8ea6dec
Compare
4b462ca
to
a212f55
Compare
@codejedi365 thank you for the recent activity on this. I have found this recently went from a nice to have for me, to a need to have. I will start by adding this as a custom parser but I'd like to offer that my team could assist with testing or similar if you'd like. I will report back if I encounter significant issues. |
15f0c67
to
fa9b2c6
Compare
@JonZeolla, thanks for the pep talk, lol! I have to duplicate and refactor the entire e2e testing suite to support monorepos. This is a beast. Likewise, I also have a project using a monorepo which gives me the reason to make this standard. Please indicate if you do have any issues. It has been tested before in the repo: https://github.com/codejedi365/psr-monorepo-poweralpha, which was a demo for another user but I do keep modifying this to make it work within PSR. You may find that you want to just combine the Options class with the Parser class into the same file to allow you to just specify the parser via a file path. I plan to write automated tests for: one trunk-only repo with one release channel, 2 GitHub Flow repos (with 1 and 2 release channels respectively) initially. The changelogs will be internal to the packages but use a common templates directory. Given that human git strategies rarely maintain the strict standard as my automated tests do, it will be helpful if you identify flaws with the current implementation. |
Will do. So far my e2e tests with the custom parser are working like a charm. I'll be testing it more this week and will report issues. No news is good news :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was using the custom parser from https://github.com/codejedi365/psr-monorepo-poweralpha but I started hitting failures using the as of the 10.3 release; looking into it further but it seemed to make sense to first refactor to use the logic from here. In doing so, I hit an issue with the "Commit" object since it's only imported if TYPE_CHECKING
.

return ConventionalCommitParserOptions() | ||
|
||
def log_parse_error(self, commit: Commit, error: str) -> ParseError: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that all of the instances of this need to be replaced with the following, otherwise it will fail at runtime (since this is just a type hint import):
def log_parse_error(self, commit: Commit, error: str) -> ParseError: | |
def log_parse_error(self, commit: "Commit", error: str) -> ParseError: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to happen in numerous places
That's unusual. I'm curious what were the errors you got with the change to 10.3? 10.3 was supposed to be simple GitHub Actions updates (idk, I wrote it last weekend and brain dumped it for monorepos) I've been working on the PR all weekend and there were some bugs with this parser refactor but a type error was not one of them. Although ruff may have fixed it automatically. I have not pushed the updated code yet. Instead of using parentheses just insert this line at the top: from __future__ import annotations This tells Python to evaluate types last (effectively ignore all type syntax unless required) at runtime. |
Just for posterity (you already saw) the 10.3 issue I hit was unrelated to this. #1307 Ah yes that's likely the discrepancy. I don't have |
…s from parser class file
…dard parser for monorepos Resolves: python-semantic-release#614
NOTICE: This release introduces a new built-in parser type that can be utilized for monorepo projects. The type value is `conventional-monorepo` and when specified it will apply the conventional commit parser to a monorepo environment. This parser has specialized options to help handle monorepo projects as well. For more information, please refer to the [Monorepo Docs](https://python-semantic-release.readthedocs.io/en/stable/monorepos.html).
fa9b2c6
to
37664fd
Compare
Purpose
Rationale
How did you test?
How to Verify