18.0 yac yet another changes#5
Conversation
…ry. (following similar logic with the modele bin.package)
…and vcp.odoo.bin.package
… the list of odoo.module.version that uses those libs (or bins)
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## 18.0-add-vcp #5 +/- ##
===============================================
Coverage ? 84.30%
===============================================
Files ? 48
Lines ? 1198
Branches ? 110
===============================================
Hits ? 1010
Misses ? 149
Partials ? 39 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
legalsylvain
force-pushed
the
18.0-YAC-yet-another-changes
branch
2 times, most recently
from
628a7d4 to
62929c1
Compare
legalsylvain
force-pushed
the
18.0-YAC-yet-another-changes
branch
from
09cb190 to
7d44743
Compare
…l. Add a Color field on labels.
…ield on vcp.request, that is based on 'is_draft', 'is_merged' and 'state' field to display the correct ribbon on form view / badge on list view
legalsylvain
force-pushed
the
18.0-YAC-yet-another-changes
branch
from
7d44743 to
69af62c
Compare
|
@etobella, @sebastienbeau : this one is ready for review. I integrated some improvment regarding badges, description, etc. |
…to scheduled_information_update. Add an helper. Check the field by default, as it is the expected behaviour user want
…l_id of some actions.
…to scheduled_information_update for vcp.repository model.
Add helpers. explicit limit in cron python code.
…heduled_branch_update for vcp.repository model.
Add helpers. explicit limit in cron python code.
…if the target branch doesn't match the pattern
legalsylvain
force-pushed
the
18.0-YAC-yet-another-changes
branch
from
e3a57a2 to
d6aa041
Compare
| <field name="model_id" ref="model_vcp_repository" /> | ||
| <field name="state">code</field> | ||
| <field name="code">model._cron_update_branches()</field> | ||
| <field name="code">model._cron_update_branches(limit=1)</field> |
There was a problem hiding this comment.
If we set a limit by default, we may change the default interval type (like every 10 minutes of 30 minutes or 1 hours?) what do you think ? (same for other cron)
There was a problem hiding this comment.
in that commit, I just "moved" the default. It was "invisible" and in the code, it is now visible and can be changed by UI, changing the "code" of the cron.
See : befb1ed#diff-b554761c27adb312a1ee5d6b213691f187a281132e08f4525ea9b16d7eb7ba1bL43-R43
About the value, I have absolutely no clue, and I think it depends on the context. I used the code to fetch all grap modules. (250, in custom repo). I had no problem, with the value !
There was a problem hiding this comment.
If we want to use queue, we should set it in a glue module, it is not a required dependancy.
sebastienbeau
left a comment
sebastienbeau
left a comment
There was a problem hiding this comment.
Thanks for the UI improvement (adding a computed status is a must!)
An alternative of the limit on the cron may have to use queue_job. So the cron will be just here to create all the job and then the job will be processed one by one (or more depending on the config).
What do you think ? (I can do it)
As said, I didn't introduced limit concept. just move a default value from a hardcoded place to a changeable place. Some vcp_queue_job could do the work. Feel free to implement it, if you think it's required. (as said for my "not so small" repos of 250 modules, no problem, I fetched all the history in some hours. Indeed, maybe for the OCA, we'll need some optimization. |
|
Ok thanks for the feedback, let's merge it @etobella |
3 participants
some screenshots of the changes