mirror of
https://github.com/odoo/runbot.git
synced 2025-04-18 17:21:10 +07:00
e6057afde7
Commits can take some time to propagate through the network (I guess), or human error can lead to the wrong commit being set. Either way, because the entire thing was done using a single fetch in `check=True` the cron job would fail entirely if any of the patch commits was yet unavailable. Update the updater to: - fallback on individual fetches - remove the patch from the set of applicable patch if we (still) can't find its commit I'd have hoped `fetch` could retrieve whatever it found, but apparently the server just crashes out when it doesn't find the commit we ask for, and `fetch` doesn't update anything. No linked issue because I apparently forgot to jot it down (and only remembered about this issue with the #1063 patching issue) but this was reported by mat last week (2025-02-21) when they were wondering why one of their patches was taking a while: - At 0832 patch was created by automated script. - At 0947, an attempt to apply was made, the commit was not found. - At 1126, a second attempt was made but an other patch had been created whose commit was not found, failing both. - At 1255, there was a concurrency error ("cannot lock ref" on the target branch). - Finally at 1427 the patch was applied. All in all it took 6 hours to apply the patch, which is 3-4 staging cycles. |
||
|---|---|---|
| .. | ||
| conftest.py | ||
| README.rst | ||
| test_basic.py | ||
| test_batch_consistency.py | ||
| test_by_branch.py | ||
| test_dfm.py | ||
| test_disabled_branch.py | ||
| test_multirepo.py | ||
| test_nondeterministic_failures.py | ||
| test_oddities.py | ||
| test_patching.py | ||
| test_project_toggles.py | ||
| test_provisioning.py | ||
| test_staging.py | ||
| test_status_overrides.py | ||
| test_statuses_optional.py | ||
Execute this test suite using pytest.
The default mode is to run tests locally using a mock github.com.
See the docstring of remote.py for instructions to run against github "actual"
(including remote-specific options) and the end of this file for a sample.
Shared properties running tests, regardless of the github implementation:
* test should be run from the root of the runbot repository providing the
name of this module aka ``pytest runbot_merge`` or
``python -mpytest runbot_merge``
* a database name to use must be provided using ``--db``, the database should
not exist beforehand
* the addons path must be specified using ``--addons-path``, both "runbot" and
the standard addons (odoo/addons) must be provided explicitly
See pytest's documentation for other options, I would recommend ``-rXs``,
``-v`` and ``--showlocals``.
When running "remote" tests as they take a very long time (hours) ``-x``
(aka ``--maxfail=1``) and ``--ff`` (run previously failed first) is also
recommended unless e.g. you run the tests overnight.
``pytest.ini`` sample
---------------------
.. code:: ini
[github]
owner = test-org
token = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
[role_reviewer]
name = Dick Bong
user = loginb
token = bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
[role_self_reviewer]
name = Fanny Chmelar
user = loginc
token = cccccccccccccccccccccccccccccccccccccccc
[role_other]
name = Harry Baals
user = logind
token = dddddddddddddddddddddddddddddddddddddddd