ak status - initial commit - proto OK #95
Conversation
There was a problem hiding this comment.
Thanks for adressing this topic.
IMO, we can't trust version numbers from patched repo.
So only stable modules (from major oca branch and freezed) should be reported.
On small project, I want to try another approach: never freeze, keep a record of the frozen.yaml (make the build reproductible).
Be able to keep track a record of what changed between two build (or to frozen) is a real gain. It let us investigate before a deploy the changes or figure out what may have changed in case of regressions.
| ) | ||
|
|
||
| # TODO see if we cannot hide the stdout here: | ||
| local["git"]["fetch", remote, remote_main_branch] & FG |
There was a problem hiding this comment.
to hide from stdout; try:
| local["git"]["fetch", remote, remote_main_branch] & FG | |
| local["git"]["fetch", remote, remote_main_branch]() |
There was a problem hiding this comment.
the optimistic "no freeze" approach can also work for large projects before they are in production.
But note that changes such as the ones I warned about in the account_payment_order module 6 months ago would have easily broken any small project. So may be we could still freeze many projects and simply filter in ak status to report only major changes so the human check is faster.
As for detecting changes between "builds" we might also save the analysis from the click-odoo update command. But as it is md5 based it is much less informative.
As for patched modules: well eventually we could still report any modules version changed in the git log along with changes in the patch branches. it's not really about trusting a version number but t might still be a better than nothing to know some patched module got a major or minor upstream change, or even a patch level change then if we want to be more cautious.
There was a problem hiding this comment.
Also, we can check with partner_modules in our instance if some of our other projects are already in a version. It can reduce the cost of each one of us looking all the pr.
| if line.strip().startswith(f"{module} "): | ||
| new_version = line.split(" ")[-1] | ||
| new_version_major = new_version.split(".")[2] | ||
| version_major = upgrade_version.split(".")[2] |
There was a problem hiding this comment.
use python-semver to clean this code
This is a prototype for
ak status: the idea is to get an upgrade status.Rationale: we often freeze projects to avoid breaking everything and we tend not to upgrade any repo anymore: the more we wait: the more any upgrade is deadly with plenty of changes with unknown danger. This is an explosive situation and this is bad because:
This
ak statuscommand will show for each installed module if the list of MAJOR and minor upgrade between the current version and the upstream version. It also shows the PRs of these MAJOR or minor changes for further details.Important: you should first do
ak buildto converge your work tree to the frozen version.To upgrade the frozen.yaml file we could typically post this
ak statuslog in the PR and ensure developers in charge of all parts review the MAJOR changes at the very least. We can assume "patch" level changes issues would be easy to fix in production if they produce any regression. Minor changes might deserve some attention too.The goal is not to replace unit and integration tests, it's just to make things safer, specially if the test coverage is not ideal yet...
The code quality is not very good today an tests are missing. But it kind of work already.
Example on the DualSun project after 6 months without upgrade:
cc @hparfr @PierrickBrun @sebastienbeau @renatonlima @mbcosta @bealdav @clementmbr