Conversation
bc85ee4 to
5c7b4e5
Compare
5c7b4e5 to
93cc406
Compare
|
@sbidoul Why not use Milestone for the branch series tagging? |
We could and probably should. But I always have been thinking that this is a misuse of Milestones which are meant to manage the next release of a project. On small repos like MIS Builder I have sometimes used the milestone to that end. |
|
Hi @sbidoul I deployed this PR on GRAP bot. It doesn't seems to work. Is it working in Acsone context ? as you can see, in the logs :
But when the a new PR is opened, the following task are executed : Did I missed something ? (I didnt' touched the environment file). Original PR : grap/grap-odoo-business#229 |
|
@legalsylvain I think you need to enable it explicitly with BOT_TASKS in the config? |
Hum, I don't think so. By default, BOT_TASKS = all Here is my current configuration. Other task like Ref : https://github.com/OCA/oca-github-bot/blob/master/environment.sample#L37-L46 Is this PR in production in any bot deployment ? (OCA / acsone / other ?) thanks ! |
|
I have not deployed this in production myself anywhere. @legalsylvain I think I spotted a missing import, which I just added, can you try again? |
|
the trigger is catched ! Thanks for your patch, @sbidoul ! then, first error. First error
worker_1 | [2026-04-01 09:01:55,996: ERROR/ForkPoolWorker-1] Task oca_github_bot.tasks.label_modified_addons.label_modified_addons[4edc8d92-4f3b-4540-8818-a4e9d545d10b] raised unexpected: TypeError("label_modified_addons() missing 1 required positional argument: 'dry_run'")
worker_1 | Traceback (most recent call last):
worker_1 | File "/app/lib/python3.12/site-packages/celery/app/trace.py", line 453, in trace_task
worker_1 | R = retval = fun(*args, **kwargs)
worker_1 | ^^^^^^^^^^^^^^^^^^^^
worker_1 | File "/app/lib/python3.12/site-packages/celery/app/trace.py", line 736, in __protected_call__
worker_1 | return self.run(*args, **kwargs)
worker_1 | ^^^^^^^^^^^^^^^^^^^^^^^^^
worker_1 | File "/app/src/oca-github-bot/src/oca_github_bot/config.py", line 27, in func_wrapper
worker_1 | return func(*args, **kwargs)
worker_1 | ^^^^^^^^^^^^^^^^^^^^^
worker_1 | TypeError: label_modified_addons() missing 1 required positional argument: 'dry_run'
Fixed by acsone#4 Then, it works ! See the result of grap/grap-odoo-business#229
However, this is a error in the log, but I didn't understood. do you have any idea ? Second error
|
[FIX] label_modified_addons: dry_run is allway optional arg
|
Hm, that's annoying indeed. I guess that pretty much kills the idea... |
I developped a work around here acsone#5
We populate labels with the full create method, so we can set a description. (there is no limitation description field) You can take a look on the result.
WDYT ?
addons:web_widget_product_label_section_and_note_full_label |
|
Interesting approach. My initial use case was to search by label though so that would be a bit more complicated as we'd need a helper to compute the label with hash from the addon name. But feasible I guess. |
-> go to https://github.com/grap/grap-odoo-business/pulls
As a result :
WDYT ? |
I think good things :) Sounds cool. Thanks for picking up this topic! |
if label name is too long, it is cut, and ended by an hash of the module name. the module name is present in the description of the label - factor out function that computes the shortened label - use 'mod:' instead of 'addon:' - add MODULE_LABEL_COLOR as new configuration Co-authored-by: Stéphane Bidoul <stephane.bidoul@acsone.eu>
Fix handle max size limitation
|
Ready to be merged for me. See #265 |
|
If no one has objections, I'll deploy this in OCA in the coming days. |
|
LGTM Non-blocking suggestion: gh_repo.labels() is called inside the loop, so the repository labels are checked once per modified addon. It could be slightly more efficient to fetch the existing label names once before the loop and reuse them. One question: on synchronize, only adds missing labels, but it does not remove module labels that may have become obsolete if the set of modified addons changed after a push or force-push. Is that the intended behavior? |
|
Good catches. At least the first item would be good to fix because the bot is always close to reaching GitHub API limits. |
|
hi @manuel-florido and @sbidoul. I implemented your suggestions and deploy in my ocabot instance. Test PRResult
could you review acsone#6 thanks ! |
|
This MR resolves my previous comments. LGTM, thanks! |





closes #265
This adds a
addon:{addon_name}and aseries:{branch_name}labels. Note: distinguishing by modification type can be added later.With this it should become much easier to write tools to be notified about modifications to addons of interest.