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
[IMP] tests: autoretry and cursor commit #162990
base: master
Are you sure you want to change the base?
Conversation
315a10c
to
ea6019e
Compare
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.
@robodoo override=ci/security
odoo/tests/common.py
Outdated
break | ||
if result.had_failure: | ||
_logger.runbot('Disabling auto-retry after a failed test') | ||
os.environ.pop('ODOO_TEST_FAILURE_RETRIES') |
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.
That's going to raise a KeyError
if the envvar is not present, is that intended?
Also why not just lift this info to a global variable / counter if we're going to access it multiple times? That way this branch can just update the global.
e1344db
to
b9f7307
Compare
@robodoo r+ |
@Xavier-Do you may want to rebuild or fix this PR as it has failed CI. |
@Xavier-Do because this PR has multiple commits, I need to know how to merge it:
|
@robodoo r+ |
I'm sorry, @Xavier-Do: this PR is already reviewed, reviewing it again is useless. |
@robodoo rebase-ff |
Merge method set to rebase and fast-forward. |
Commiting or rollbacking the cursor during test will lead to failure in cascade, because the cursor cannot be rollbacked at the end of the test, and cannot be closed proprely. In some case, it can even provoque failure on following test, maybe because some cleanup are not done proprely. This is also breaking the autoretry mecanism since the cursor cannot be rollbacked, leading to error not related to the first failure. Part-of: #162990
Auto retry is mainly useful to avoid the need to rebuild in case of random failure, but once one test failed, this mecanism is useless, creates noises in logs, increase laod by retrying test for no reason, ... This commit should disable this mecanism after the first error. closes #162990 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Commiting or rollbacking the cursor during test will lead to failure in cascade, because the cursor cannot be rollbacked at the end of the test, and cannot be closed proprely. In some case, it can even provoque failure on following test, maybe because some cleanup are not done proprely. This is also breaking the autoretry mecanism since the cursor cannot be rollbacked, leading to error not related to the first failure. Part-of: #162990
Auto retry is mainly useful to avoid the need to rebuild in case of random failure, but once one test failed, this mecanism is useless, creates noises in logs, increase laod by retrying test for no reason, ... This commit should disable this mecanism after the first error. closes #162990 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Commiting or rollbacking the cursor during test will lead to failure in cascade, because the cursor cannot be rollbacked at the end of the test, and cannot be closed proprely. In some case, it can even provoque failure on following test, maybe because some cleanup are not done proprely. This is also breaking the autoretry mecanism since the cursor cannot be rollbacked, leading to error not related to the first failure. Part-of: #162990
Auto retry is mainly useful to avoid the need to rebuild in case of random failure, but once one test failed, this mecanism is useless, creates noises in logs, increase laod by retrying test for no reason, ... This commit should disable this mecanism after the first error. closes #162990 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Commiting or rollbacking the cursor during test will lead to failure in cascade, because the cursor cannot be rollbacked at the end of the test, and cannot be closed proprely. In some case, it can even provoque failure on following test, maybe because some cleanup are not done proprely. This is also breaking the autoretry mecanism since the cursor cannot be rollbacked, leading to error not related to the first failure. Part-of: #162990
Auto retry is mainly useful to avoid the need to rebuild in case of random failure, but once one test failed, this mecanism is useless, creates noises in logs, increase laod by retrying test for no reason, ... This commit should disable this mecanism after the first error. closes #162990 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Commiting or rollbacking the cursor during test will lead to failure in cascade, because the cursor cannot be rollbacked at the end of the test, and cannot be closed proprely. In some case, it can even provoque failure on following test, maybe because some cleanup are not done proprely. This is also breaking the autoretry mecanism since the cursor cannot be rollbacked, leading to error not related to the first failure. Part-of: #162990
Auto retry is mainly useful to avoid the need to rebuild in case of random failure, but once one test failed, this mecanism is useless, creates noises in logs, increase laod by retrying test for no reason, ... This commit should disable this mecanism after the first error. closes #162990 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
@Xavier-Do staging failed: ci/l10n on f5ee98ba946ca334c0fcbe457bf24bf6760c7e2e (view more at https://runbot.odoo.com/runbot/build/61986871) |
Auto retry is mainly useful to avoid the need to rebuild in case of random failure, but once one test failed, this mecanism is useless, creates noises in logs, increase laod by retrying test for no reason, ... This commit should disable this mecanism after the first error.
Commiting or rollbacking the cursor during test will lead to failure in cascade, because the cursor cannot be rollbacked at the end of the test, and cannot be closed proprely. In some case, it can even provoque failure on following test, maybe because some cleanup are not done proprely. This is also breaking the autoretry mecanism since the cursor cannot be rollbacked, leading to error not related to the first failure.
b9f7307
to
043e999
Compare
This should improve autoretry mecanism overall, and also avoid chain error, even without autoretry, when commiting/rollbacking/closing the cursor opened from a TransactionCase.