NextERP/runbot
5
0
Fork 0
mirror of https://github.com/odoo/runbot.git synced 2025-03-17 00:15:47 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
18.0-fix-timeout-xdo
runbot/runbot_merge/tests/test_basic.py

3975 lines
160 KiB
Python
Raw Permalink Normal View History

[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
import datetime
[FIX] runbot_merge: forcefully rollback ref after a failed rebase() rebase() can fail after merge(), during set_ref(), having already updated the target. Under the pre-rebase model, stage() assumed on a staging failure on a given repo it only had to rollback stagings having succeeded. This assumption fails in a post-rebase model as even a failed staging can have modified the target, leading to the next staging (if multiple batches are ready) containing the failed one. Things can get really strange if the set_ref failure was (as it probably is) some sort of transient failure, as the following staging will likely succeed (under the assumption that most PRs/batches pass staging) as PR1's content gets merged as part of PR2, and PR2 is merged empty of content later on.
2018-10-17 19:18:49 +07:00
import itertools
[IMP] runbot_merge: link to failed runbot builds a0063f9df091ef901cfb055b002e9cf4107688bc slightly improved the error message on non-PR ci failure (e.g. a community PR makes enterprise break) by adding the failed commit, but that's still not exactly clear, even for technical users (plus it requires having access to all the repos which is not the case for everyone). This commit further improves the situation by storing the target_url and description fields of the commit statuses, and printing out the target_url on failure if it's present. That way the PR comment denoting build failure should now have a link to the relevant failed build on runbot, as that's the target_url it provides. The change is nontrivial as it tries to be compatible with both old and new statuses storage format, such that there is no migration to perform.
2018-09-17 16:04:31 +07:00
import json
[IMP] runbot_merge: split out content after separator when creating commit Currently when creating *merges* the commit message is the concatenation of the PR title and the PR body. However it can be convenient to include description test which would not be included in the commit message e.g. PR template stuff. "Thematic breaks" seem like a good way to do this: the commit message will only include the content preceding the first thematic break, everything else is ignored (except headings which are not ignored, double negations FTW). Might be that that's a bit excessive and we should only ignore what follows the *last* thematic break. Or that there needs to be a more specific marker. We'll see. Fixes #443.
2021-01-12 18:24:34 +07:00
import textwrap
[FIX] runbot_merge: updating of commit date on rebase On #509, the rebasing process was changed to forcefully update the commit date of the commits, in order to force trigger builds. However when squashing was re-enabled for #539 for some fool reason it implemented its own bespoke rebasing (despite that not actually saving any API call that I can see), meaning it did *not* update the commit date. As such, an old commit being squashed would not get picked up by the runbot, which is what happened to odoo/documentation#1226 (which ultimately had to be hand-rebased after some confusion as to why it did not work). Update `_stage_squash` to go through `rebase` the normal way, also update `rebase` to pop the commit date entirely instead of setting it manually, and update the squashing test to check that the commit date gets properly updated. Fixes #579, closes #582
2022-02-07 18:00:31 +07:00
import time
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
from typing import Callable
[FIX] runbot_merge: forcefully rollback ref after a failed rebase() rebase() can fail after merge(), during set_ref(), having already updated the target. Under the pre-rebase model, stage() assumed on a staging failure on a given repo it only had to rollback stagings having succeeded. This assumption fails in a post-rebase model as even a failed staging can have modified the target, leading to the next staging (if multiple batches are ready) containing the failed one. Things can get really strange if the set_ref failure was (as it probably is) some sort of transient failure, as the following staging will likely succeed (under the assumption that most PRs/batches pass staging) as PR1's content gets merged as part of PR2, and PR2 is merged empty of content later on.
2018-10-17 19:18:49 +07:00
from unittest import mock
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
import pytest
[FIX] runbot_merge: multi-commit squashing If commits have different authors (/ committers), the mergebot would ask github to create a commit with an author (/ committer) of `None` / `null`. Apparently github really does not like that, and complains that > nil is not an object So remove the key entirely. Also fix the collision between `author` and the `Co-Authored-By` list, which could lead to trying to set an `author` of `[name, email]` instead of an object, which is also not accepted by github.
2022-12-07 19:25:08 +07:00
import requests
[IMP] runbot_merge, forwardport: minor cleanups Remove unused imports, unnecessary f-strings, dead code, fix less-than-ideal operators.
2023-08-10 18:21:21 +07:00
from lxml import html
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
import odoo
[IMP] runbot_merge: move read_tracking_value to utils And use it in test_trivial_flow instead of the kinda half-assed manual version.
2024-10-07 13:06:03 +07:00
from utils import _simple_init, seen, matches, get_partner, Commit, pr_page, to_pr, part_of, ensure_one, read_tracking_value
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
[ADD] *: per-repository webhook secret Currently webhook secrets are configured per *project* which is an issue both because different repositories may have different administrators and thus creates safety concerns, and because multiple repositories can feed into different projects (e.g. on mergebot, odoo-dev/odoo is both an ancillary repository to the main RD project, and the main repository to the minor / legacy master-wowl project). This means it can be necessary to have multiple projects share the same secret as well, this then mandates the secret for more repositories per (1). This is a pain in the ass, so just detach secrets from projects and link them *only* to repositories, it's cleaner and easier to manage and set up progressively. This requires a lot of changes to the tests, as they all need to correctly configure the signaling. For `runbot_merge` there was *some* setup sharing already via the module-level `repo` fixtures`, those were merged into a conftest-level fixture which could handle the signaling setup. A few tests which unnecessarily set up repositories ad-hoc were also moved to the fixture. But for most of the ad-hoc setup in `runbot_merge`, as well as `forwardport` where it's all ad-hoc, events sources setup was just appended as is. This should probably be cleaned up at one point, with the various requirements collected and organised into a small set of fixtures doing the job more uniformly. Fixes #887
2024-06-06 16:07:57 +07:00
@pytest.fixture(autouse=True)
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
def _configure_statuses(request, project, repo):
if 'defaultstatuses' not in request.keywords:
project.repo_ids.required_statuses = 'legal/cla,ci/runbot'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
@pytest.fixture(autouse=True, params=["statuses", "rpc"])
def stagings(request, env, project, repo):
"""Hook in support for validating stagings via RPC calls instead of CI
webhooks. Transparent for the tests as long as they send statuses to
symbolic refs (branch names) rather than commits, although commits *would*
probably be doable (look up the head for the commit, then what staging it's
part of)
"""
if request.param == "statuses":
yield
else:
env['res.users'].browse([env._uid]).write({
"groups_id": [(4, env.ref("runbot_merge.status").id, {})]
})
project.write({
"staging_rpc": True,
"staging_statuses": False,
})
RepoType = type(repo)
# apparently side_effect + wraps on unbound method don't work correctly,
# the wrapped method does get called when returning DEFAULT but *the
# instance (subject) is not sent along for the ride* so the call fails.
post_status = RepoType.post_status
def _post_status(repo, ref, status, context='default', **kw):
if not ref.startswith(('staging.', 'heads/staging.')):
return post_status(repo, ref, status, context, **kw)
c = repo.commit(ref)
branchname = ref.removeprefix('staging.').removeprefix('heads/staging.')
env['runbot_merge.stagings'].search([('target.name', '=', branchname)])\
.post_status(c.id, context, status, **kw)
with mock.patch.object(RepoType, "post_status", _post_status):
yield
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_trivial_flow(env, repo, page, users, config):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
# create base branch
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] runbot_merge: automation around branch deactivation Currently deactivating a branch kinda leaves users in the dark, with little way to know what has happened aside from inferring it from the branch having disappeared from the main dashboard. - surface the state of the branch in the PR dashboard (also surface the target branch at all so users can see if their PR is targeted as they expect as far as the mergebot is concerned) - close & notify every PR to a branch being deactivated - cancel any current staging to the branch (as a consequence of the above) Closes #632
2022-07-29 17:37:23 +07:00
[m] = repo.make_commits(None, Commit("initial", tree={'a': 'some content'}), ref='heads/master')
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
# create PR with 2 commits
[IMP] runbot_merge: automation around branch deactivation Currently deactivating a branch kinda leaves users in the dark, with little way to know what has happened aside from inferring it from the branch having disappeared from the main dashboard. - surface the state of the branch in the PR dashboard (also surface the target branch at all so users can see if their PR is targeted as they expect as far as the mergebot is concerned) - close & notify every PR to a branch being deactivated - cancel any current staging to the branch (as a consequence of the above) Closes #632
2022-07-29 17:37:23 +07:00
_, c1 = repo.make_commits(
m,
Commit('replace file contents', tree={'a': 'some other content'}),
Commit('add file', tree={'b': 'a second file'}),
ref='heads/other'
)
pr = repo.make_pr(title="gibberish", body="blahblah", target='master', head='other')
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[FIX] runbot_merge: tracking message author on PullRequest events d4fa1fd35315d330566e37f515a937f722859ef7 added tracking to changes from *comments* (as well as a few hacks around authorship transfer), however it missed two things: First, it set the `change-author` during comments handling only, so changes from the `PullRequest` hook e.g. open, synchronise, close, edit, don't get attributed to their actual source, and instead just fall back to uid(1). This is easy enough to fix as the `sender` is always provided, that can be resolved to a partner which is then set as the author of whatever changes happen. Second, I actually missed one of the message hooks: there's both `_message_log` and `_message_log_batch` and they don't call one another, so both have to be overridden in order for tracking to be consistent. In this case, specifically, the *creation* of a tracked object goes through `_message_log_batch` (since that's a very generic message and so works on every tracked object created during the transaction... even though batch has a message per record anyway...) while *updates* go through `_message_log`. Fixes #895
2024-06-21 21:33:44 +07:00
[c2] = repo.make_commits(
'other',
Commit('forgot a bit', tree={'whee': 'kjfdsh'}),
ref='heads/other',
make=False,
)
[IMP] runbot_merge: show linked PRs during staging and after merging Previously, a PR's status page would only show the linked / related PRs when `open`. Since the relations between PRs remains useful, also make this information available during staging and after merging. Fixes #463
2021-07-23 20:45:23 +07:00
pr_id = to_pr(env, pr)
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
assert pr_id.state == 'opened'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
assert pr.comments == [seen(env, pr, users)]
[IMP] runbot_merge: automation around branch deactivation Currently deactivating a branch kinda leaves users in the dark, with little way to know what has happened aside from inferring it from the branch having disappeared from the main dashboard. - surface the state of the branch in the PR dashboard (also surface the target branch at all so users can see if their PR is targeted as they expect as far as the mergebot is concerned) - close & notify every PR to a branch being deactivated - cancel any current staging to the branch (as a consequence of the above) Closes #632
2022-07-29 17:37:23 +07:00
pr_dashboard = pr_page(page, pr)
s = pr_dashboard.cssselect('.alert-info > ul > li')
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
assert [it.get('class') for it in s] == ['fail', 'fail', ''],\
"merge method unset, review missing, no CI"
[IMP] runbot_merge: automation around branch deactivation Currently deactivating a branch kinda leaves users in the dark, with little way to know what has happened aside from inferring it from the branch having disappeared from the main dashboard. - surface the state of the branch in the PR dashboard (also surface the target branch at all so users can see if their PR is targeted as they expect as far as the mergebot is concerned) - close & notify every PR to a branch being deactivated - cancel any current staging to the branch (as a consequence of the above) Closes #632
2022-07-29 17:37:23 +07:00
assert dict(zip(
[e.text_content() for e in pr_dashboard.cssselect('dl.runbot-merge-fields dt')],
[e.text_content() for e in pr_dashboard.cssselect('dl.runbot-merge-fields dd')],
)) == {
'label': f"{config['github']['owner']}:other",
[FIX] runbot_merge: tracking message author on PullRequest events d4fa1fd35315d330566e37f515a937f722859ef7 added tracking to changes from *comments* (as well as a few hacks around authorship transfer), however it missed two things: First, it set the `change-author` during comments handling only, so changes from the `PullRequest` hook e.g. open, synchronise, close, edit, don't get attributed to their actual source, and instead just fall back to uid(1). This is easy enough to fix as the `sender` is always provided, that can be resolved to a partner which is then set as the author of whatever changes happen. Second, I actually missed one of the message hooks: there's both `_message_log` and `_message_log_batch` and they don't call one another, so both have to be overridden in order for tracking to be consistent. In this case, specifically, the *creation* of a tracked object goes through `_message_log_batch` (since that's a very generic message and so works on every tracked object created during the transaction... even though batch has a message per record anyway...) while *updates* go through `_message_log`. Fixes #895
2024-06-21 21:33:44 +07:00
'head': c2,
[IMP] runbot_merge: automation around branch deactivation Currently deactivating a branch kinda leaves users in the dark, with little way to know what has happened aside from inferring it from the branch having disappeared from the main dashboard. - surface the state of the branch in the PR dashboard (also surface the target branch at all so users can see if their PR is targeted as they expect as far as the mergebot is concerned) - close & notify every PR to a branch being deactivated - cancel any current staging to the branch (as a consequence of the above) Closes #632
2022-07-29 17:37:23 +07:00
}
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[FIX] runbot_merge: tracking message author on PullRequest events d4fa1fd35315d330566e37f515a937f722859ef7 added tracking to changes from *comments* (as well as a few hacks around authorship transfer), however it missed two things: First, it set the `change-author` during comments handling only, so changes from the `PullRequest` hook e.g. open, synchronise, close, edit, don't get attributed to their actual source, and instead just fall back to uid(1). This is easy enough to fix as the `sender` is always provided, that can be resolved to a partner which is then set as the author of whatever changes happen. Second, I actually missed one of the message hooks: there's both `_message_log` and `_message_log_batch` and they don't call one another, so both have to be overridden in order for tracking to be consistent. In this case, specifically, the *creation* of a tracked object goes through `_message_log_batch` (since that's a very generic message and so works on every tracked object created during the transaction... even though batch has a message per record anyway...) while *updates* go through `_message_log`. Fixes #895
2024-06-21 21:33:44 +07:00
repo.post_status(c2, 'success', 'legal/cla')
repo.post_status(c2, 'success', 'ci/runbot')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
assert pr_id.state == 'validated'
s = pr_page(page, pr).cssselect('.alert-info > ul > li')
assert [it.get('class') for it in s] == ['fail', 'fail', 'ok'],\
"merge method unset, review missing, CI"
statuses = [
(l.find('a').text.split(':')[0], l.get('class').strip())
for l in s[2].cssselect('ul li')
]
assert statuses == [('legal/cla', 'ok'), ('ci/runbot', 'ok')]
[IMP] runbot_merge: extract commit validation to cron Before this, impacting a commit's statuses on the relevant PR or staging would be performed immediatly / inline with its consumption. This, however, is problematic if we want to implement additional processing like #87 (and possibly though probably not #52): webhook handlers should be kept short and fast, feeding back into github would not be acceptable. - flag commits as needing processing instead of processing them immediately, this uses a partial index as it looks like the recommended / proper way to index a boolean column in which one of the values is searched much more than the other (todo: eventually check if that actually does anythnig) - add a new cron for commits processing - alter tests so they use this new cron (mostly by migrating them to `run_crons` though not solely as some still need more detailed management to properly check intermediate steps) Fix an issue with closing a staged PR while at it (the "merging" tag would potentially never be removed).
2019-03-05 14:01:38 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
pr.post_comment('hansen r+ rebase-merge', config['role_reviewer']['token'])
assert pr_id.state == 'ready'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[ADD] runbot_merge: tag PR to signify state changes
2018-03-28 21:43:48 +07:00
# can't check labels here as running the cron will stage it
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
assert pr_id.staging_id
assert pr_page(page, pr).cssselect('.alert-primary')
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
repo.post_status('staging.master', 'success', 'ci/runbot', target_url='http://foo.com/pog')
repo.post_status('staging.master', 'success', 'legal/cla')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
# the should not block the merge because it's not part of the requirements
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
repo.post_status('staging.master', 'failure', 'ci/lint', target_url='http://ignored.com/whocares')
[IMP] runbot_merge: extract commit validation to cron Before this, impacting a commit's statuses on the relevant PR or staging would be performed immediatly / inline with its consumption. This, however, is problematic if we want to implement additional processing like #87 (and possibly though probably not #52): webhook handlers should be kept short and fast, feeding back into github would not be acceptable. - flag commits as needing processing instead of processing them immediately, this uses a partial index as it looks like the recommended / proper way to index a boolean column in which one of the values is searched much more than the other (todo: eventually check if that actually does anythnig) - add a new cron for commits processing - alter tests so they use this new cron (mostly by migrating them to `run_crons` though not solely as some still need more detailed management to properly check intermediate steps) Fix an issue with closing a staged PR while at it (the "merging" tag would potentially never be removed).
2019-03-05 14:01:38 +07:00
# need to store this because after the crons have run the staging will
# have succeeded and been disabled
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
st = pr_id.staging_id
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] runbot_merge: adds direct links to CI details to the dashboard Currently, if a staging is ongoing or failed one has to hunt for the staging branches on the runbot dashboard in order to find out what happens. This adds a dropdown to the staging box/block providing direct status and access to all the CI information whether the CI is ongoing or done, successful or not.
2018-10-19 22:24:01 +07:00
[IMP] runbot_merge: show linked PRs during staging and after merging Previously, a PR's status page would only show the linked / related PRs when `open`. Since the relations between PRs remains useful, also make this information available during staging and after merging. Fixes #463
2021-07-23 20:45:23 +07:00
assert {tuple(t) for t in st.statuses} == {
[IMP] runbot_merge: adds direct links to CI details to the dashboard Currently, if a staging is ongoing or failed one has to hunt for the staging branches on the runbot dashboard in order to find out what happens. This adds a dropdown to the staging box/block providing direct status and access to all the CI information whether the CI is ongoing or done, successful or not.
2018-10-19 22:24:01 +07:00
(repo.name, 'legal/cla', 'success', ''),
(repo.name, 'ci/runbot', 'success', 'http://foo.com/pog'),
(repo.name, 'ci/lint', 'failure', 'http://ignored.com/whocares'),
}
[IMP] runbot_merge: extract commit validation to cron Before this, impacting a commit's statuses on the relevant PR or staging would be performed immediatly / inline with its consumption. This, however, is problematic if we want to implement additional processing like #87 (and possibly though probably not #52): webhook handlers should be kept short and fast, feeding back into github would not be acceptable. - flag commits as needing processing instead of processing them immediately, this uses a partial index as it looks like the recommended / proper way to index a boolean column in which one of the values is searched much more than the other (todo: eventually check if that actually does anythnig) - add a new cron for commits processing - alter tests so they use this new cron (mostly by migrating them to `run_crons` though not solely as some still need more detailed management to properly check intermediate steps) Fix an issue with closing a staged PR while at it (the "merging" tag would potentially never be removed).
2019-03-05 14:01:38 +07:00
[IMP] runbot_merge: adds direct links to CI details to the dashboard Currently, if a staging is ongoing or failed one has to hunt for the staging branches on the runbot dashboard in order to find out what happens. This adds a dropdown to the staging box/block providing direct status and access to all the CI information whether the CI is ongoing or done, successful or not.
2018-10-19 22:24:01 +07:00
p = html.fromstring(page('/runbot_merge'))
[FIX] runbot_merge: more frontend templates af016f42392428442395bc380d9b2802b254c0ca did a half-assed job and didn't fix the one test which actually checks the dashboard. TBF I was in a bit of a hurry trying to make the mergebot work and be presentable again, but still...
2022-11-30 18:44:25 +07:00
s = p.cssselect('.staging div.dropdown a')
assert len(s) == 2, "not logged so only *required* statuses"
for e, status in zip(s, ['legal/cla', 'ci/runbot']):
assert set(e.classes) == {'dropdown-item', 'bg-success'}
assert e.text_content().strip() == f'{repo.name}: {status}'
[IMP] runbot_merge: adds direct links to CI details to the dashboard Currently, if a staging is ongoing or failed one has to hunt for the staging branches on the runbot dashboard in order to find out what happens. This adds a dropdown to the staging box/block providing direct status and access to all the CI information whether the CI is ongoing or done, successful or not.
2018-10-19 22:24:01 +07:00
[IMP] runbot_merge: extract commit validation to cron Before this, impacting a commit's statuses on the relevant PR or staging would be performed immediatly / inline with its consumption. This, however, is problematic if we want to implement additional processing like #87 (and possibly though probably not #52): webhook handlers should be kept short and fast, feeding back into github would not be acceptable. - flag commits as needing processing instead of processing them immediately, this uses a partial index as it looks like the recommended / proper way to index a boolean column in which one of the values is searched much more than the other (todo: eventually check if that actually does anythnig) - add a new cron for commits processing - alter tests so they use this new cron (mostly by migrating them to `run_crons` though not solely as some still need more detailed management to properly check intermediate steps) Fix an issue with closing a staged PR while at it (the "merging" tag would potentially never be removed).
2019-03-05 14:01:38 +07:00
assert st.state == 'success'
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
assert pr_id.state == 'merged'
assert pr_page(page, pr).cssselect('.alert-success')
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
master = repo.commit('heads/master')
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
# with default-rebase, only one parent is "known"
assert master.parents[0] == m
[IMP] runbot_merge: pluginify github mock This is the preparation of an attempt to make these tests work with both a local github mock (in-memory) and a remote actual github. Move a bunch of fixtures relying on the specific github implementation (and odoo-as-library access) to the "local" plugin, including splitting the "repo" fixture. The specific fixtures will likely have to be adjusted as the remote endpoint is fleshed out.
2018-06-05 15:10:32 +07:00
assert repo.read_tree(master) == {
[ADD] forwardbot * Cherrypicking is handrolled because there seems to be no easy way to programmatically edit commit messages during the cherrypicking sequence: `-n` basically squashes all commits and `-e` invokes a subprocess. `-e` with `VISUAL=false` kinda sorta works (in that it interrupts the process before each commit), however there doesn't seem to be clean status codes so it's difficult to know if the cherrypick failed or if it's just waiting for a commit of this step. Instead, cherrypick commits individually then edit / rewrite their commit messages: * add a reference to the original commit * convert signed-off-by to something else as the original commit was signed off but not necessarily this one * Can't assign users when creating PRs: only repository collaborators or people who commented on the issue / PR (which we're in the process of creating) can be assigned. PR authors are as likely to be collaborators as not, and we can have non-collaborator reviewers. So pinging via a regular comment seems less fraught as a way to notify users.
2019-08-23 21:16:30 +07:00
'a': 'some other content',
'b': 'a second file',
[FIX] runbot_merge: tracking message author on PullRequest events d4fa1fd35315d330566e37f515a937f722859ef7 added tracking to changes from *comments* (as well as a few hacks around authorship transfer), however it missed two things: First, it set the `change-author` during comments handling only, so changes from the `PullRequest` hook e.g. open, synchronise, close, edit, don't get attributed to their actual source, and instead just fall back to uid(1). This is easy enough to fix as the `sender` is always provided, that can be resolved to a partner which is then set as the author of whatever changes happen. Second, I actually missed one of the message hooks: there's both `_message_log` and `_message_log_batch` and they don't call one another, so both have to be overridden in order for tracking to be consistent. In this case, specifically, the *creation* of a tracked object goes through `_message_log_batch` (since that's a very generic message and so works on every tracked object created during the transaction... even though batch has a message per record anyway...) while *updates* go through `_message_log`. Fixes #895
2024-06-21 21:33:44 +07:00
'whee': 'kjfdsh',
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
}
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
assert master.message == "gibberish\n\nblahblah\n\ncloses {repo.name}#1"\
"\n\nSigned-off-by: {reviewer.formatted_email}"\
.format(repo=repo, reviewer=get_partner(env, users['reviewer']))
[FIX] runbot_merge: avoid double closes message If the message already contains the pr number, no need to add it again
2018-09-13 15:30:47 +07:00
[MERGE] bot from 15.0 to 16.0 Breakages: - the entire http.py API was updated requiring fixing the uses of `request.jsonrequest` and the patches to `WebRequest` to hook in sentry - `fontawesome` was moved - `*[@groups]` are now completely removed from the view if not matching, so any field inside of them which needs to be used outside (e.g. attrs) has to be added as invisible outside the element - discuss removed the mail tracking value helpers from RPC in odoo/odoo#88547, so reimplement locally (and better)
2024-08-07 19:14:27 +07:00
def get_tracking_values(record):
[MERGE] bot from 16.0 to 17.0 Broken (can't run odoo at all): - In Odoo 17.0, the `pre_init_hook` takes an env, not a cursor, update `_check_citext`. - Odoo 17.0 rejects `@attrs` and doesn't say where they are or how to update them, fun, hunt down `attrs={'invisible': ...` and try to fix them. - Odoo 17.0 warns on non-multi creates, update them, most were very reasonable, one very wasn't. Test failures: - Odoo 17.0 deprecates `name_get` and doesn't use it as a *source* anymore, replace overrides by overrides to `_compute_display_name`. - Multiple tracking changes: - `_track_set_author` takes a `Partner` not an id. - `_message_compute_author` still requires overriding in order to handle record creation, which in standard doesn't support author overriding. - `mail.tracking.value.field_type` has been removed, the field type now needs to be retrieved from the `field_id`. - Some tracking ordering have changed and require adjusting a few tests. Also added a few flushes before SQL queries which are not (obviously at least) at the start of a cron or controller, no test failure observed but better safe than sorry (probably).
2024-08-12 18:13:03 +07:00
field_type = record.field_id.ttype
if not isinstance(field_type, str):
raise TypeError(f"{field_type!r} can't be a field type")
if field_type in ('integer', 'float', 'char', 'text', 'monetary', 'datetime'):
return record[f'old_value_{field_type}'], record[f'new_value_{field_type}']
elif field_type == 'date':
[MERGE] bot from 15.0 to 16.0 Breakages: - the entire http.py API was updated requiring fixing the uses of `request.jsonrequest` and the patches to `WebRequest` to hook in sentry - `fontawesome` was moved - `*[@groups]` are now completely removed from the view if not matching, so any field inside of them which needs to be used outside (e.g. attrs) has to be added as invisible outside the element - discuss removed the mail tracking value helpers from RPC in odoo/odoo#88547, so reimplement locally (and better)
2024-08-07 19:14:27 +07:00
v1, v2 = record.old_value_datetime, record.new_value_datetime
return v1 and v1[:10], v2 and v2[:10]
[MERGE] bot from 16.0 to 17.0 Broken (can't run odoo at all): - In Odoo 17.0, the `pre_init_hook` takes an env, not a cursor, update `_check_citext`. - Odoo 17.0 rejects `@attrs` and doesn't say where they are or how to update them, fun, hunt down `attrs={'invisible': ...` and try to fix them. - Odoo 17.0 warns on non-multi creates, update them, most were very reasonable, one very wasn't. Test failures: - Odoo 17.0 deprecates `name_get` and doesn't use it as a *source* anymore, replace overrides by overrides to `_compute_display_name`. - Multiple tracking changes: - `_track_set_author` takes a `Partner` not an id. - `_message_compute_author` still requires overriding in order to handle record creation, which in standard doesn't support author overriding. - `mail.tracking.value.field_type` has been removed, the field type now needs to be retrieved from the `field_id`. - Some tracking ordering have changed and require adjusting a few tests. Also added a few flushes before SQL queries which are not (obviously at least) at the start of a cron or controller, no test failure observed but better safe than sorry (probably).
2024-08-12 18:13:03 +07:00
elif field_type == 'boolean':
[MERGE] bot from 15.0 to 16.0 Breakages: - the entire http.py API was updated requiring fixing the uses of `request.jsonrequest` and the patches to `WebRequest` to hook in sentry - `fontawesome` was moved - `*[@groups]` are now completely removed from the view if not matching, so any field inside of them which needs to be used outside (e.g. attrs) has to be added as invisible outside the element - discuss removed the mail tracking value helpers from RPC in odoo/odoo#88547, so reimplement locally (and better)
2024-08-07 19:14:27 +07:00
return bool(record.old_value_integer), bool(record.new_value_integer)
else:
return record.old_value_char, record.new_value_char
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
# reverse because the messages are in newest-to-oldest by default
# (as that's how you want to read them)
[IMP] runbot_merge: move read_tracking_value to utils And use it in test_trivial_flow instead of the kinda half-assed manual version.
2024-10-07 13:06:03 +07:00
messages = pr_id.message_ids[::-1].mapped(lambda m: (
m.author_id.display_name,
m.body,
list(map(read_tracking_value, m.tracking_value_ids)),
))
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
assert list(messages) == [
[FIX] runbot_merge: tracking message author on PullRequest events d4fa1fd35315d330566e37f515a937f722859ef7 added tracking to changes from *comments* (as well as a few hacks around authorship transfer), however it missed two things: First, it set the `change-author` during comments handling only, so changes from the `PullRequest` hook e.g. open, synchronise, close, edit, don't get attributed to their actual source, and instead just fall back to uid(1). This is easy enough to fix as the `sender` is always provided, that can be resolved to a partner which is then set as the author of whatever changes happen. Second, I actually missed one of the message hooks: there's both `_message_log` and `_message_log_batch` and they don't call one another, so both have to be overridden in order for tracking to be consistent. In this case, specifically, the *creation* of a tracked object goes through `_message_log_batch` (since that's a very generic message and so works on every tracked object created during the transaction... even though batch has a message per record anyway...) while *updates* go through `_message_log`. Fixes #895
2024-06-21 21:33:44 +07:00
(users['user'], '<p>Pull Request created</p>', []),
[IMP] runbot_merge: move read_tracking_value to utils And use it in test_trivial_flow instead of the kinda half-assed manual version.
2024-10-07 13:06:03 +07:00
(users['user'], '', [('head', c1, c2)]),
('OdooBot', f'<p>statuses changed on {c2}</p>', [('state', 'Opened', 'Validated')]),
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
# reviewer approved changing the state and setting reviewer as reviewer
# plus set merge method
('Reviewer', '', [
[IMP] runbot_merge: move read_tracking_value to utils And use it in test_trivial_flow instead of the kinda half-assed manual version.
2024-10-07 13:06:03 +07:00
('merge_method', '', 'rebase and merge, using the PR as merge commit message'),
('reviewed_by', '', 'Reviewer'),
[FIX] runbot_merge: tracked value ordering Apparently in odoo 17.0 tracking values are always ordered by field name.
2024-11-20 18:40:15 +07:00
('state', 'Validated', 'Ready'),
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
]),
# staging succeeded
[REF] forwardport: update re_matches to not use a regex Using a regex as the pattern is quite frustrating due to all the escaping necessary, which in this refactoring I found out I'd missed, multiple times. Convert the pattern to something bespoke but not too complicated, we may want to add anchoring support and a bit more finesse and the future but for now straightforward "holes" seem to work well. I've added support for capturing and even named groups even if this as yet unnecessary and unused. Fixes #861 [^1]: https://docs.pytest.org/en/stable/reference.html#pytest.hookspec.pytest_assertrepr_compare
2024-06-04 17:15:29 +07:00
(matches('$$'), f'<p>staging {st.id} succeeded</p>', [
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
# set merge date
[IMP] runbot_merge: move read_tracking_value to utils And use it in test_trivial_flow instead of the kinda half-assed manual version.
2024-10-07 13:06:03 +07:00
('merge_date', False, pr_id.merge_date),
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
# updated state
[IMP] runbot_merge: move read_tracking_value to utils And use it in test_trivial_flow instead of the kinda half-assed manual version.
2024-10-07 13:06:03 +07:00
('state', 'Ready', 'Merged'),
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
]),
]
[FIX] runbot_merge: avoid double closes message If the message already contains the pr number, no need to add it again
2018-09-13 15:30:47 +07:00
class TestCommitMessage:
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_commit_simple(self, env, repo, users, config):
[FIX] runbot_merge: avoid double closes message If the message already contains the pr number, no need to add it again
2018-09-13 15:30:47 +07:00
""" verify 'closes ...' is correctly added in the commit message
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
c1 = repo.make_commit(None, 'first!', None, tree={'f': 'm1'})
repo.make_ref('heads/master', c1)
c2 = repo.make_commit(c1, 'simple commit message', None, tree={'f': 'm2'})
prx = repo.make_pr(title='title', body='body', target='master', head=c2)
repo.post_status(prx.head, 'success', 'ci/runbot')
repo.post_status(prx.head, 'success', 'legal/cla')
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
with repo:
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
env.run_crons()
[FIX] runbot_merge: avoid double closes message If the message already contains the pr number, no need to add it again
2018-09-13 15:30:47 +07:00
master = repo.commit('heads/master')
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
assert master.message == "simple commit message\n\ncloses {repo.name}#1"\
"\n\nSigned-off-by: {reviewer.formatted_email}"\
.format(repo=repo, reviewer=get_partner(env, users['reviewer']))
[FIX] runbot_merge: avoid double closes message If the message already contains the pr number, no need to add it again
2018-09-13 15:30:47 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_commit_existing(self, env, repo, users, config):
[FIX] runbot_merge: avoid double closes message If the message already contains the pr number, no need to add it again
2018-09-13 15:30:47 +07:00
""" verify do not duplicate 'closes' instruction
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
c1 = repo.make_commit(None, 'first!', None, tree={'f': 'm1'})
repo.make_ref('heads/master', c1)
c2 = repo.make_commit(c1, 'simple commit message that closes #1', None, tree={'f': 'm2'})
prx = repo.make_pr(title='title', body='body', target='master', head=c2)
repo.post_status(prx.head, 'success', 'ci/runbot')
repo.post_status(prx.head, 'success', 'legal/cla')
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
with repo:
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
env.run_crons()
[FIX] runbot_merge: avoid double closes message If the message already contains the pr number, no need to add it again
2018-09-13 15:30:47 +07:00
master = repo.commit('heads/master')
# closes #1 is already present, should not modify message
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
assert master.message == "simple commit message that closes #1"\
"\n\nSigned-off-by: {reviewer.formatted_email}"\
.format(reviewer=get_partner(env, users['reviewer']))
[FIX] runbot_merge: avoid double closes message If the message already contains the pr number, no need to add it again
2018-09-13 15:30:47 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_commit_other(self, env, repo, users, config):
[FIX] runbot_merge: avoid double closes message If the message already contains the pr number, no need to add it again
2018-09-13 15:30:47 +07:00
""" verify do not duplicate 'closes' instruction
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
c1 = repo.make_commit(None, 'first!', None, tree={'f': 'm1'})
repo.make_ref('heads/master', c1)
c2 = repo.make_commit(c1, 'simple commit message that closes odoo/enterprise#1', None, tree={'f': 'm2'})
prx = repo.make_pr(title='title', body='body', target='master', head=c2)
repo.post_status(prx.head, 'success', 'ci/runbot')
repo.post_status(prx.head, 'success', 'legal/cla')
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
with repo:
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
env.run_crons()
[FIX] runbot_merge: avoid double closes message If the message already contains the pr number, no need to add it again
2018-09-13 15:30:47 +07:00
master = repo.commit('heads/master')
# closes on another repositoy, should modify the commit message
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
assert master.message == "simple commit message that closes odoo/enterprise#1\n\ncloses {repo.name}#1"\
"\n\nSigned-off-by: {reviewer.formatted_email}"\
.format(repo=repo, reviewer=get_partner(env, users['reviewer']))
[FIX] runbot_merge: avoid double closes message If the message already contains the pr number, no need to add it again
2018-09-13 15:30:47 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_commit_wrong_number(self, env, repo, users, config):
[FIX] runbot_merge: avoid double closes message If the message already contains the pr number, no need to add it again
2018-09-13 15:30:47 +07:00
""" verify do not match on a wrong number
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
c1 = repo.make_commit(None, 'first!', None, tree={'f': 'm1'})
repo.make_ref('heads/master', c1)
c2 = repo.make_commit(c1, 'simple commit message that closes #11', None, tree={'f': 'm2'})
prx = repo.make_pr(title='title', body='body', target='master', head=c2)
repo.post_status(prx.head, 'success', 'ci/runbot')
repo.post_status(prx.head, 'success', 'legal/cla')
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
with repo:
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
env.run_crons()
[FIX] runbot_merge: avoid double closes message If the message already contains the pr number, no need to add it again
2018-09-13 15:30:47 +07:00
master = repo.commit('heads/master')
# closes on another repositoy, should modify the commit message
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
assert master.message == "simple commit message that closes #11\n\ncloses {repo.name}#1"\
"\n\nSigned-off-by: {reviewer.formatted_email}"\
.format(repo=repo, reviewer=get_partner(env, users['reviewer']))
[FIX] runbot_merge: avoid double closes message If the message already contains the pr number, no need to add it again
2018-09-13 15:30:47 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_commit_delegate(self, env, repo, users, config):
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
""" verify 'signed-off-by ...' is correctly added in the commit message for delegated review
"""
[IMP] runbot_merge: reject review without email If a reviewer doesn't have an email set, the Signed-Off-By is an `@users.noreply.github.com` address which just looks weird in the final result. Initially the thinking was that emails would be required for users to *be* reviewers or self-reviewers, but since those are now o2ms / m2ms it's a bit of a pain in the ass. Instead, provide an action to easily try and fetch the public email of a user from github. Fixes #531
2021-10-06 18:06:53 +07:00
env['res.partner'].create({
'name': users['other'],
'github_login': users['other'],
'email': users['other'] + '@example.org'
})
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
c1 = repo.make_commit(None, 'first!', None, tree={'f': 'm1'})
repo.make_ref('heads/master', c1)
c2 = repo.make_commit(c1, 'simple commit message', None, tree={'f': 'm2'})
prx = repo.make_pr(title='title', body='body', target='master', head=c2)
repo.post_status(prx.head, 'success', 'ci/runbot')
repo.post_status(prx.head, 'success', 'legal/cla')
prx.post_comment('hansen delegate=%s' % users['other'], config["role_reviewer"]["token"])
prx.post_comment('hansen r+', config['role_other']['token'])
env.run_crons()
with repo:
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
env.run_crons()
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
master = repo.commit('heads/master')
assert master.message == "simple commit message\n\ncloses {repo.name}#1"\
"\n\nSigned-off-by: {reviewer.formatted_email}"\
.format(repo=repo, reviewer=get_partner(env, users['other']))
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_commit_coauthored(self, env, repo, users, config):
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
""" verify 'closes ...' and 'Signed-off-by' are added before co-authored-by tags.
[FIX] runbot_merge: ensure co-authored-by are at the bottom Sometimes people add co-authored-by lines in the middle of their message, where github ignores them. Since we previously added properly handling existing (correct) C-A-B lines in the case where we're adding fixes and signed-off-by, we might as well fix-up existing but mispalced co-authored-by lines. Fixes #107
2019-05-07 18:22:13 +07:00
Also checks that all co-authored-by are moved at the end of the
message
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
c1 = repo.make_commit(None, 'first!', None, tree={'f': 'm1'})
repo.make_ref('heads/master', c1)
c2 = repo.make_commit(c1, '''simple commit message
[IMP] runbot_merge: commit message edition abstraction Prepares for more complex edition operations on the forwardbot side * split out the pseudo-headers from the message body * don't separate the co-authored-by headers from the others, seems unnecessary, we just need to ensure they're at the end so github doesn't miss them (/it)
2019-08-23 21:16:30 +07:00
Co-authored-by: Bob <bob@example.com>
Fixes a thing''', None, tree={'f': 'm2'})
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx = repo.make_pr(title='title', body='body', target='master', head=c2)
repo.post_status(prx.head, 'success', 'ci/runbot')
repo.post_status(prx.head, 'success', 'legal/cla')
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
env.run_crons()
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
master = repo.commit('heads/master')
[IMP] runbot_merge: commit message edition abstraction Prepares for more complex edition operations on the forwardbot side * split out the pseudo-headers from the message body * don't separate the co-authored-by headers from the others, seems unnecessary, we just need to ensure they're at the end so github doesn't miss them (/it)
2019-08-23 21:16:30 +07:00
assert master.message == """simple commit message
Fixes a thing
closes {repo.name}#1
Signed-off-by: {reviewer.formatted_email}
Co-authored-by: Bob <bob@example.com>""".format(
repo=repo,
reviewer=get_partner(env, users['reviewer'])
)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[ADD] runbot_merge: webhook signature support
2018-06-13 17:35:22 +07:00
class TestWebhookSecurity:
[ADD] *: per-repository webhook secret Currently webhook secrets are configured per *project* which is an issue both because different repositories may have different administrators and thus creates safety concerns, and because multiple repositories can feed into different projects (e.g. on mergebot, odoo-dev/odoo is both an ancillary repository to the main RD project, and the main repository to the minor / legacy master-wowl project). This means it can be necessary to have multiple projects share the same secret as well, this then mandates the secret for more repositories per (1). This is a pain in the ass, so just detach secrets from projects and link them *only* to repositories, it's cleaner and easier to manage and set up progressively. This requires a lot of changes to the tests, as they all need to correctly configure the signaling. For `runbot_merge` there was *some* setup sharing already via the module-level `repo` fixtures`, those were merged into a conftest-level fixture which could handle the signaling setup. A few tests which unnecessarily set up repositories ad-hoc were also moved to the fixture. But for most of the ad-hoc setup in `runbot_merge`, as well as `forwardport` where it's all ad-hoc, events sources setup was just appended as is. This should probably be cleaned up at one point, with the various requirements collected and organised into a small set of fixtures doing the job more uniformly. Fixes #887
2024-06-06 16:07:57 +07:00
@pytest.fixture(autouse=True)
def add_secret_to_source(self, env, repo):
env['runbot_merge.events_sources'].search([
('repository', '=', repo.name),
]).secret = "a secret"
[ADD] runbot_merge: webhook signature support
2018-06-13 17:35:22 +07:00
def test_no_secret(self, env, project, repo):
""" Test 1: didn't add a secret to the repo, should be ignored
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, "initial", None, tree={'a': 'some content'})
repo.make_ref('heads/master', m)
[ADD] runbot_merge: webhook signature support
2018-06-13 17:35:22 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c0 = repo.make_commit(m, 'replace file contents', None, tree={'a': 'some other content'})
pr0 = repo.make_pr(title="gibberish", body="blahblah", target='master', head=c0)
[ADD] runbot_merge: webhook signature support
2018-06-13 17:35:22 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
with pytest.raises(TimeoutError):
to_pr(env, pr0)
[ADD] runbot_merge: webhook signature support
2018-06-13 17:35:22 +07:00
def test_wrong_secret(self, env, project, repo):
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.set_secret("wrong secret")
[ADD] runbot_merge: webhook signature support
2018-06-13 17:35:22 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
m = repo.make_commit(None, "initial", None, tree={'a': 'some content'})
repo.make_ref('heads/master', m)
[ADD] runbot_merge: webhook signature support
2018-06-13 17:35:22 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c0 = repo.make_commit(m, 'replace file contents', None, tree={'a': 'some other content'})
pr0 = repo.make_pr(title="gibberish", body="blahblah", target='master', head=c0)
[ADD] runbot_merge: webhook signature support
2018-06-13 17:35:22 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
with pytest.raises(TimeoutError):
to_pr(env, pr0)
[ADD] runbot_merge: webhook signature support
2018-06-13 17:35:22 +07:00
def test_correct_secret(self, env, project, repo):
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.set_secret("a secret")
[ADD] runbot_merge: webhook signature support
2018-06-13 17:35:22 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
m = repo.make_commit(None, "initial", None, tree={'a': 'some content'})
repo.make_ref('heads/master', m)
[ADD] runbot_merge: webhook signature support
2018-06-13 17:35:22 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c0 = repo.make_commit(m, 'replace file contents', None, tree={'a': 'some other content'})
pr0 = repo.make_pr(title="gibberish", body="blahblah", target='master', head=c0)
[ADD] runbot_merge: webhook signature support
2018-06-13 17:35:22 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
assert to_pr(env, pr0)
[ADD] runbot_merge: webhook signature support
2018-06-13 17:35:22 +07:00
[IMP] runbot_merge: be more optimistic about PR mergeability If we can't stage a PR, rather than immediately put them in error wait until they were the first we tried staging, otherwise they might have been conflicting with the previous batch which ultimately won't be merged for other reason and they would have worked as part of the next batch. Note: this commit will lead to false negatives because it's batch-based rather than repo-based, so if the first batch only affects repo A and the second batch only affects repo B, if the second batch triggers a merge error it should be rejected immediately (as it's applied on a "pristine" repo B) but this change will just bump it to the next staging. fixes #209
2020-10-02 20:24:54 +07:00
def test_staging_ongoing(env, repo, config):
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
# create base branch
m = repo.make_commit(None, 'initial', None, tree={'a': 'some content'})
repo.make_ref('heads/master', m)
# create PR
c0 = repo.make_commit(m, 'replace file contents', None, tree={'a': 'some other content'})
c1 = repo.make_commit(c0, 'add file', None, tree={'a': 'some other content', 'b': 'a second file'})
pr1 = repo.make_pr(title="gibberish", body="blahblah", target='master', head=c1)
repo.post_status(c1, 'success', 'legal/cla')
repo.post_status(c1, 'success', 'ci/runbot')
pr1.post_comment("hansen r+ rebase-merge", config['role_reviewer']['token'])
env.run_crons()
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr1 = to_pr(env, pr1)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr1.staging_id
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
# create second PR and make ready for staging
c2 = repo.make_commit(m, 'other', None, tree={'a': 'some content', 'c': 'ccc'})
c3 = repo.make_commit(c2, 'other', None, tree={'a': 'some content', 'c': 'ccc', 'd': 'ddd'})
pr2 = repo.make_pr(title='gibberish', body='blahblah', target='master', head=c3)
repo.post_status(c3, 'success', 'legal/cla')
repo.post_status(c3, 'success', 'ci/runbot')
pr2.post_comment('hansen r+ rebase-merge', config['role_reviewer']['token'])
env.run_crons()
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
p_2 = to_pr(env, pr2)
[ADD] runbot_merge: tag PR to signify state changes
2018-03-28 21:43:48 +07:00
assert p_2.state == 'ready', "PR2 should not have been staged since there is a pending staging for master"
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
repo.post_status('staging.master', 'success', 'ci/runbot')
repo.post_status('staging.master', 'success', 'legal/cla')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr1.state == 'merged'
[ADD] runbot_merge: tag PR to signify state changes
2018-03-28 21:43:48 +07:00
assert p_2.staging_id
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
repo.post_status('staging.master', 'success', 'ci/runbot')
repo.post_status('staging.master', 'success', 'legal/cla')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: tag PR to signify state changes
2018-03-28 21:43:48 +07:00
assert p_2.state == 'merged'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_staging_concurrent(env, repo, config):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
""" test staging to different targets, should be picked up together """
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/1.0', m)
repo.make_ref('heads/2.0', m)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
env['runbot_merge.project'].search([]).write({
'branch_ids': [(0, 0, {'name': '1.0'}), (0, 0, {'name': '2.0'})],
})
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
c10 = repo.make_commit(m, 'AAA', None, tree={'m': 'm', 'a': 'a'})
c11 = repo.make_commit(c10, 'BBB', None, tree={'m': 'm', 'a': 'a', 'b': 'b'})
pr1 = repo.make_pr(title='t1', body='b1', target='1.0', head=c11)
repo.post_status(pr1.head, 'success', 'ci/runbot')
repo.post_status(pr1.head, 'success', 'legal/cla')
pr1.post_comment('hansen r+ rebase-merge', config['role_reviewer']['token'])
c20 = repo.make_commit(m, 'CCC', None, tree={'m': 'm', 'c': 'c'})
c21 = repo.make_commit(c20, 'DDD', None, tree={'m': 'm', 'c': 'c', 'd': 'd'})
pr2 = repo.make_pr(title='t2', body='b2', target='2.0', head=c21)
repo.post_status(pr2.head, 'success', 'ci/runbot')
repo.post_status(pr2.head, 'success', 'legal/cla')
pr2.post_comment('hansen r+ rebase-merge', config['role_reviewer']['token'])
env.run_crons()
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr1 = to_pr(env, pr1)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr1.staging_id
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr2 = to_pr(env, pr2)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr2.staging_id
[IMP] *: require explicitly specifying whether exceptions in logs are valid Seems like a good idea to better keep track of the log of an Odoo used to testing, and avoid silently ignoring logged errors. - intercept odoo's stderr via a pipe, that way we can still write it back out and pytest is able to read & buffer it, pytest's capfd would not work correctly: it breaks output capturing (and printing on failure); and because of the way it hooks in it's unable to capture from subprocesses inheriting the standard stream, cf pytest-dev/pytest#4428 - update the env fixture to check that the odoo log doesn't have any exception on failure - make that check conditional on the `expect_log_errors` marker, this way we can mark tests for which we expect errors to be logged, and assert that that does happen
2024-06-11 20:41:03 +07:00
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
def test_staging_conflict_first(env, repo, users, config, page):
[IMP] runbot_merge: be more optimistic about PR mergeability If we can't stage a PR, rather than immediately put them in error wait until they were the first we tried staging, otherwise they might have been conflicting with the previous batch which ultimately won't be merged for other reason and they would have worked as part of the next batch. Note: this commit will lead to false negatives because it's batch-based rather than repo-based, so if the first batch only affects repo A and the second batch only affects repo B, if the second batch triggers a merge error it should be rejected immediately (as it's applied on a "pristine" repo B) but this change will just bump it to the next staging. fixes #209
2020-10-02 20:24:54 +07:00
""" If the first batch of a staging triggers a conflict, the PR should be
marked as in error
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m1 = repo.make_commit(None, 'initial', None, tree={'f': 'm1'})
m2 = repo.make_commit(m1, 'second', None, tree={'f': 'm2'})
repo.make_ref('heads/master', m2)
c1 = repo.make_commit(m1, 'other second', None, tree={'f': 'c1'})
c2 = repo.make_commit(c1, 'third', None, tree={'f': 'c2'})
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
pr = repo.make_pr(title='title', body='body', target='master', head=c2)
repo.post_status(pr.head, 'success', 'ci/runbot')
repo.post_status(pr.head, 'success', 'legal/cla')
pr.post_comment('hansen r+ rebase-merge', config['role_reviewer']['token'])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
pr_id = to_pr(env, pr)
assert pr_id.state == 'error'
assert pr.comments == [
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
(users['reviewer'], 'hansen r+ rebase-merge'),
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
seen(env, pr, users),
[IMP] *: review mergebot & forwardbot messages for pinging Old messages were quite inconsistent in their pinging of the PR author and reviewer. Reviewed messages (probably missed some but...) and try to more consistently ping when the feedback requires some sort of action in order to proceed. Fixes #592
2022-06-23 19:25:07 +07:00
(users['user'], 'Merge method set to rebase and merge, using the PR as merge commit message.'),
(users['user'], '@%(user)s @%(reviewer)s unable to stage: merge conflict' % users),
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
]
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
dangerbox = pr_page(page, pr).cssselect('.alert-danger span')
assert dangerbox
assert dangerbox[0].text.strip() == 'Unable to stage PR'
[IMP] *: require explicitly specifying whether exceptions in logs are valid Seems like a good idea to better keep track of the log of an Odoo used to testing, and avoid silently ignoring logged errors. - intercept odoo's stderr via a pipe, that way we can still write it back out and pytest is able to read & buffer it, pytest's capfd would not work correctly: it breaks output capturing (and printing on failure); and because of the way it hooks in it's unable to capture from subprocesses inheriting the standard stream, cf pytest-dev/pytest#4428 - update the env fixture to check that the odoo log doesn't have any exception on failure - make that check conditional on the `expect_log_errors` marker, this way we can mark tests for which we expect errors to be logged, and assert that that does happen
2024-06-11 20:41:03 +07:00
[IMP] runbot_merge: be more optimistic about PR mergeability If we can't stage a PR, rather than immediately put them in error wait until they were the first we tried staging, otherwise they might have been conflicting with the previous batch which ultimately won't be merged for other reason and they would have worked as part of the next batch. Note: this commit will lead to false negatives because it's batch-based rather than repo-based, so if the first batch only affects repo A and the second batch only affects repo B, if the second batch triggers a merge error it should be rejected immediately (as it's applied on a "pristine" repo B) but this change will just bump it to the next staging. fixes #209
2020-10-02 20:24:54 +07:00
def test_staging_conflict_second(env, repo, users, config):
""" If the non-first batch of a staging triggers a conflict, the PR should
just be skipped: it might be a conflict with an other PR which could fail
the staging
"""
with repo:
[m] = repo.make_commits(None, Commit('initial', tree={'a': '1'}), ref='heads/master')
with repo:
repo.make_commits(m, Commit('first pr', tree={'a': '2'}), ref='heads/pr0')
pr0 = repo.make_pr(target='master', head='pr0')
repo.post_status(pr0.head, 'success', 'ci/runbot')
repo.post_status(pr0.head, 'success', 'legal/cla')
pr0.post_comment('hansen r+', config['role_reviewer']['token'])
with repo:
repo.make_commits(m, Commit('second pr', tree={'a': '3'}), ref='heads/pr1')
pr1 = repo.make_pr(target='master', head='pr1')
repo.post_status(pr1.head, 'success', 'ci/runbot')
repo.post_status(pr1.head, 'success', 'legal/cla')
pr1.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
pr0_id = to_pr(env, pr0)
pr1_id = to_pr(env, pr1)
[IMP] runbot_merge: be more optimistic about PR mergeability If we can't stage a PR, rather than immediately put them in error wait until they were the first we tried staging, otherwise they might have been conflicting with the previous batch which ultimately won't be merged for other reason and they would have worked as part of the next batch. Note: this commit will lead to false negatives because it's batch-based rather than repo-based, so if the first batch only affects repo A and the second batch only affects repo B, if the second batch triggers a merge error it should be rejected immediately (as it's applied on a "pristine" repo B) but this change will just bump it to the next staging. fixes #209
2020-10-02 20:24:54 +07:00
assert pr0_id.staging_id, "pr0 should have been staged"
assert not pr1_id.staging_id, "pr1 should not have been staged (due to conflict)"
assert pr1_id.state == 'ready', "pr1 should not be in error yet"
# merge the staging, this should try to stage pr1, fail, and put it in error
# as it now conflicts with the master proper
with repo:
repo.post_status('staging.master', 'success', 'ci/runbot')
repo.post_status('staging.master', 'success', 'legal/cla')
env.run_crons()
assert pr1_id.state == 'error', "now pr1 should be in error"
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
@pytest.mark.defaultstatuses
@pytest.mark.parametrize('update_op', [
pytest.param(
lambda _: {'timeout_limit': datetime.datetime.now().isoformat(" ", "seconds")},
id="set-timeout-limit",
),
pytest.param(
lambda timeout: {'staged_at': (datetime.datetime.now() - datetime.timedelta(minutes=2*timeout)).isoformat(" ", "seconds")},
id="set-staged-at",
),
])
def test_staging_ci_timeout(env, repo, config, page, update_op: Callable[[int], dict]):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
"""If a staging timeouts (~ delay since staged greater than
configured)... requeue?
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
m, _, c2 = repo.make_commits(
None,
Commit('initial', tree={'f': 'm'}),
Commit('first', tree={'f': 'c1'}),
Commit('second', tree={'f': 'c2'}),
)
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
repo.make_ref('heads/master', m)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
pr = repo.make_pr(title='title', body='body', target='master', head=c2)
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
repo.post_status(pr.head, 'success')
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
pr.post_comment('hansen r+ rebase-merge', config['role_reviewer']['token'])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
pr_id = to_pr(env, pr)
assert pr_id.staging_id
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
timeout = env['runbot_merge.project'].search([]).ci_timeout
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
pr_id.staging_id.write(update_op(timeout))
[IMP] *: trigger-ify staging cron The staging cron turns out to be pretty reasonable to trigger, as we already have a handler on the transition of a batch to `not blocked`, which is exactly when we want to create a staging (that and the completion of the previous staging). The batch transition is in a compute which is not awesome, but on the flip side we also cancel active stagings in that exact scenario (if it applies), so that matches. The only real finesse is that one of the tests wants to observe the instant between the end of a staging (and creation of splits) and the start of the next one, which because the staging cron is triggered by the failure of the previous staging is now "atomic", requiring disabling the staging cron, which means the trigger is skipped entirely. So this requires triggering the staging cron by hand.
2024-08-01 15:15:32 +07:00
env.run_crons(None)
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
assert pr_id.state == 'error', "timeout should fail the PR"
dangerbox = pr_page(page, pr).cssselect('.alert-danger span')
assert dangerbox
assert dangerbox[0].text == 'timed out (>60 minutes)'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_timeout_bump_on_pending(env, repo, config):
with repo:
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
[m, c] = repo.make_commits(
None,
Commit('initial', tree={'f': '0'}),
Commit('c', tree={'f': '1'}),
)
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
repo.make_ref('heads/master', m)
[IMP] runbot_merge: update staging timeout on 'pending' CI If the CI is greatly backed up (either insufficient capacity or jobs spike) a timeout which is normally perfectly fine might be insufficient e.g. given a 2h timeout, if a job normally takes 80mn but the staging's job starts 40mn after the staging was actually created we're sunk. And cancelling the staging once the job has finally gotten started is not going to improve load on the CI, it just wastes a CI slot. Therefore assume a `pending` event denotes the actual start of the job on the CI, and reset the timeout to start from that moment so ci_timeout is the timeout of the CI job itself, not of the staging having been created. Closes #202
2019-09-23 20:42:18 +07:00
[FIX] runbot_merge: don't over-bump timeout By updating the staging timeout every time we run `_compute_state` and still have a `pending` status, we'd actually bump the timeout *on every success CI* except for the last one. Which was never the intention and can add an hour or two to the mergebot-side timeout. Instead, add an `updated_at` attribute to statuses (name taken from the webhook payload even though we don't use that), read it when we see `pending` required statuses, and update the staging timeout based on that if necessary. That way as long as we don't get *new* pending statuses, the timeout doesn't get updated. Fixes #952
2024-09-20 17:17:17 +07:00
prx = repo.make_pr(target='master', head=c)
repo.post_status(prx.head, 'success', 'ci/runbot')
repo.post_status(prx.head, 'success', 'legal/cla')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
[IMP] runbot_merge: update staging timeout on 'pending' CI If the CI is greatly backed up (either insufficient capacity or jobs spike) a timeout which is normally perfectly fine might be insufficient e.g. given a 2h timeout, if a job normally takes 80mn but the staging's job starts 40mn after the staging was actually created we're sunk. And cancelling the staging once the job has finally gotten started is not going to improve load on the CI, it just wastes a CI slot. Therefore assume a `pending` event denotes the actual start of the job on the CI, and reset the timeout to start from that moment so ci_timeout is the timeout of the CI job itself, not of the staging having been created. Closes #202
2019-09-23 20:42:18 +07:00
st = env['runbot_merge.stagings'].search([])
old_timeout = odoo.fields.Datetime.to_string(datetime.datetime.now() - datetime.timedelta(days=15))
st.timeout_limit = old_timeout
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[FIX] runbot_merge: don't over-bump timeout By updating the staging timeout every time we run `_compute_state` and still have a `pending` status, we'd actually bump the timeout *on every success CI* except for the last one. Which was never the intention and can add an hour or two to the mergebot-side timeout. Instead, add an `updated_at` attribute to statuses (name taken from the webhook payload even though we don't use that), read it when we see `pending` required statuses, and update the staging timeout based on that if necessary. That way as long as we don't get *new* pending statuses, the timeout doesn't get updated. Fixes #952
2024-09-20 17:17:17 +07:00
repo.post_status('staging.master', 'pending', 'ci/runbot')
env.run_crons(None)
assert st.timeout_limit > old_timeout, "receiving a pending status should bump the timeout"
st.timeout_limit = old_timeout
# clear the statuses cache to remove the memoized status times
st.statuses_cache = "{}"
st.commit_ids.statuses = "{}"
with repo:
repo.post_status('staging.master', 'success', 'legal/cla')
[IMP] *: rely only on triggers to run statuses propagation The cron had been converted to using mostly triggers in 7cd9afe7f2ff2cbaaabe0ecf6eb364b55aaf8d60 but I forgot to update the *tests* to avoid explicitly triggering it.
2024-07-30 18:42:00 +07:00
env.run_crons(None)
[FIX] runbot_merge: don't over-bump timeout By updating the staging timeout every time we run `_compute_state` and still have a `pending` status, we'd actually bump the timeout *on every success CI* except for the last one. Which was never the intention and can add an hour or two to the mergebot-side timeout. Instead, add an `updated_at` attribute to statuses (name taken from the webhook payload even though we don't use that), read it when we see `pending` required statuses, and update the staging timeout based on that if necessary. That way as long as we don't get *new* pending statuses, the timeout doesn't get updated. Fixes #952
2024-09-20 17:17:17 +07:00
assert st.timeout_limit == old_timeout, "receiving a success status should *not* bump the timeout"
[IMP] runbot_merge: update staging timeout on 'pending' CI If the CI is greatly backed up (either insufficient capacity or jobs spike) a timeout which is normally perfectly fine might be insufficient e.g. given a 2h timeout, if a job normally takes 80mn but the staging's job starts 40mn after the staging was actually created we're sunk. And cancelling the staging once the job has finally gotten started is not going to improve load on the CI, it just wastes a CI slot. Therefore assume a `pending` event denotes the actual start of the job on the CI, and reset the timeout to start from that moment so ci_timeout is the timeout of the CI job itself, not of the staging having been created. Closes #202
2019-09-23 20:42:18 +07:00
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
def test_staging_ci_failure_single(env, repo, users, config, page):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
""" on failure of single-PR staging, mark & notify failure
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
c2 = repo.make_commit(c1, 'second', None, tree={'m': 'c2'})
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
pr = repo.make_pr(title='title', body='body', target='master', head=c2)
repo.post_status(pr.head, 'success', 'ci/runbot')
repo.post_status(pr.head, 'success', 'legal/cla')
pr.post_comment('hansen r+ rebase-merge', config['role_reviewer']['token'])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
pr_id = to_pr(env, pr)
assert pr_id.staging_id
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
repo.post_status('staging.master', 'failure', 'a/b')
repo.post_status('staging.master', 'success', 'legal/cla')
repo.post_status('staging.master', 'failure', 'ci/runbot') # stable genius
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
assert pr_id.state == 'error'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
assert pr.comments == [
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
(users['reviewer'], 'hansen r+ rebase-merge'),
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
seen(env, pr, users),
[IMP] *: review mergebot & forwardbot messages for pinging Old messages were quite inconsistent in their pinging of the PR author and reviewer. Reviewed messages (probably missed some but...) and try to more consistently ping when the feedback requires some sort of action in order to proceed. Fixes #592
2022-06-23 19:25:07 +07:00
(users['user'], "Merge method set to rebase and merge, using the PR as merge commit message."),
(users['user'], '@%(user)s @%(reviewer)s staging failed: ci/runbot' % users)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
]
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
dangerbox = pr_page(page, pr).cssselect('.alert-danger span')
assert dangerbox
assert dangerbox[0].text == 'ci/runbot'
[IMP] *: require explicitly specifying whether exceptions in logs are valid Seems like a good idea to better keep track of the log of an Odoo used to testing, and avoid silently ignoring logged errors. - intercept odoo's stderr via a pipe, that way we can still write it back out and pytest is able to read & buffer it, pytest's capfd would not work correctly: it breaks output capturing (and printing on failure); and because of the way it hooks in it's unable to capture from subprocesses inheriting the standard stream, cf pytest-dev/pytest#4428 - update the env fixture to check that the odoo log doesn't have any exception on failure - make that check conditional on the `expect_log_errors` marker, this way we can mark tests for which we expect errors to be logged, and assert that that does happen
2024-06-11 20:41:03 +07:00
[IMP] runbot_merge: error reporting on fast-forward failure When a staging's fast-forward (to the target branch) fails, the mergebot would provide no useful information on the staging or the dashboard. This is because the reason was set to the HTTP status, which in case of a fast-forward error is just "422 client error: unprocessable entity". Improve this by trying to parse github's response in that case, and using the JSON error message as failure reason. This provides more useful failure information like "update is not a fast forward", "reference does not exist", or a branch protection failure. Closes #591
2022-06-08 19:45:32 +07:00
def test_ff_failure(env, repo, config, page):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
""" target updated while the PR is being staged => redo staging """
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
c2 = repo.make_commit(c1, 'second', None, tree={'m': 'c2'})
prx = repo.make_pr(title='title', body='body', target='master', head=c2)
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen r+ rebase-merge', config['role_reviewer']['token'])
env.run_crons()
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
st = to_pr(env, prx).staging_id
[IMP] runbot_merge: error reporting on fast-forward failure When a staging's fast-forward (to the target branch) fails, the mergebot would provide no useful information on the staging or the dashboard. This is because the reason was set to the HTTP status, which in case of a fast-forward error is just "422 client error: unprocessable entity". Improve this by trying to parse github's response in that case, and using the JSON error message as failure reason. This provides more useful failure information like "update is not a fast forward", "reference does not exist", or a branch protection failure. Closes #591
2022-06-08 19:45:32 +07:00
assert st
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m2 = repo.make_commit('heads/master', 'cockblock', None, tree={'m': 'm', 'm2': 'm2'})
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert repo.commit('heads/master').id == m2
# report staging success & run cron to merge
staging = repo.commit('heads/staging.master')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
repo.post_status('staging.master', 'success', 'legal/cla')
repo.post_status('staging.master', 'success', 'ci/runbot')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] runbot_merge: error reporting on fast-forward failure When a staging's fast-forward (to the target branch) fails, the mergebot would provide no useful information on the staging or the dashboard. This is because the reason was set to the HTTP status, which in case of a fast-forward error is just "422 client error: unprocessable entity". Improve this by trying to parse github's response in that case, and using the JSON error message as failure reason. This provides more useful failure information like "update is not a fast forward", "reference does not exist", or a branch protection failure. Closes #591
2022-06-08 19:45:32 +07:00
assert st.reason == 'update is not a fast forward'
# check that it's added as title on the staging
doc = html.fromstring(page('/runbot_merge'))
_new, prev = doc.cssselect('li.staging')
assert 'bg-gray-lighter' in prev.classes, "ff failure is ~ cancelling"
[REF] forwardport: update re_matches to not use a regex Using a regex as the pattern is quite frustrating due to all the escaping necessary, which in this refactoring I found out I'd missed, multiple times. Convert the pattern to something bespoke but not too complicated, we may want to add anchoring support and a bit more finesse and the future but for now straightforward "holes" seem to work well. I've added support for capturing and even named groups even if this as yet unnecessary and unused. Fixes #861 [^1]: https://docs.pytest.org/en/stable/reference.html#pytest.hookspec.pytest_assertrepr_compare
2024-06-04 17:15:29 +07:00
assert 'fast forward failed (update is not a fast forward)' in prev.get('title')
[IMP] runbot_merge: error reporting on fast-forward failure When a staging's fast-forward (to the target branch) fails, the mergebot would provide no useful information on the staging or the dashboard. This is because the reason was set to the HTTP status, which in case of a fast-forward error is just "422 client error: unprocessable entity". Improve this by trying to parse github's response in that case, and using the JSON error message as failure reason. This provides more useful failure information like "update is not a fast forward", "reference does not exist", or a branch protection failure. Closes #591
2022-06-08 19:45:32 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
assert to_pr(env, prx).staging_id, "merge should not have succeeded"
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert repo.commit('heads/staging.master').id != staging.id,\
"PR should be staged to a new commit"
[IMP] *: require explicitly specifying whether exceptions in logs are valid Seems like a good idea to better keep track of the log of an Odoo used to testing, and avoid silently ignoring logged errors. - intercept odoo's stderr via a pipe, that way we can still write it back out and pytest is able to read & buffer it, pytest's capfd would not work correctly: it breaks output capturing (and printing on failure); and because of the way it hooks in it's unable to capture from subprocesses inheriting the standard stream, cf pytest-dev/pytest#4428 - update the env fixture to check that the odoo log doesn't have any exception on failure - make that check conditional on the `expect_log_errors` marker, this way we can mark tests for which we expect errors to be logged, and assert that that does happen
2024-06-11 20:41:03 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_ff_failure_batch(env, repo, users, config):
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
a1 = repo.make_commit(m, 'a1', None, tree={'m': 'm', 'a': '1'})
a2 = repo.make_commit(a1, 'a2', None, tree={'m': 'm', 'a': '2'})
repo.make_ref('heads/A', a2)
A = repo.make_pr(title='A', body=None, target='master', head='A')
repo.post_status(A.head, 'success', 'legal/cla')
repo.post_status(A.head, 'success', 'ci/runbot')
A.post_comment('hansen r+ rebase-merge', config['role_reviewer']['token'])
b1 = repo.make_commit(m, 'b1', None, tree={'m': 'm', 'b': '1'})
b2 = repo.make_commit(b1, 'b2', None, tree={'m': 'm', 'b': '2'})
repo.make_ref('heads/B', b2)
B = repo.make_pr(title='B', body=None, target='master', head='B')
repo.post_status(B.head, 'success', 'legal/cla')
repo.post_status(B.head, 'success', 'ci/runbot')
B.post_comment('hansen r+ rebase-merge', config['role_reviewer']['token'])
c1 = repo.make_commit(m, 'c1', None, tree={'m': 'm', 'c': '1'})
c2 = repo.make_commit(c1, 'c2', None, tree={'m': 'm', 'c': '2'})
repo.make_ref('heads/C', c2)
C = repo.make_pr(title='C', body=None, target='master', head='C')
repo.post_status(C.head, 'success', 'legal/cla')
repo.post_status(C.head, 'success', 'ci/runbot')
C.post_comment('hansen r+ rebase-merge', config['role_reviewer']['token'])
env.run_crons()
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
pr_a = to_pr(env, A)
pr_b = to_pr(env, B)
pr_c = to_pr(env, C)
[ADD] runbot_merge: one more test, still doesn't repro staging 13
2018-09-19 23:49:52 +07:00
messages = [
c['commit']['message']
for c in repo.log('heads/staging.master')
]
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
assert part_of('a2', pr_a) in messages
assert part_of('b2', pr_b) in messages
assert part_of('c2', pr_c) in messages
[ADD] runbot_merge: one more test, still doesn't repro staging 13
2018-09-19 23:49:52 +07:00
# block FF
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] forwardport: unmodified fw automatically inherit overrides Before this change, a CI override would have to be replicated on most / all forward-ports of the base PR. This was intentional to see how it would shake out, the answer being that it's rather annoying. Also add a `statuses_full` computed field on PRs for the aggregate status: the existing `statuses` field is just a copy of the commit statuses which I didn't remember I kept free of the overrides so the commit statuses could be displayed "as-is" in the backend (the overrides are displayed separately). And while at it fix the PR dashboard to use that new field: that was basically the intention but then I went on to use the "wrong" field hence #433. Mebbe the UI part should be displayed using a computed M2M (?) as a table or as tags instead? This m2m could indicate whether the status is an override or an "intrinsic" status. Also removed some dead code: * leftover from the removed tagging feature (removed the tag manipulation but forgot some of the setup / computations) * unused local variables * an empty skipped test case Fixes #439. Fixes #433.
2021-01-13 14:18:17 +07:00
repo.make_commit('heads/master', 'NO!', None, tree={'m': 'm2'})
[ADD] runbot_merge: one more test, still doesn't repro staging 13
2018-09-19 23:49:52 +07:00
old_staging = repo.commit('heads/staging.master')
# confirm staging
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status('heads/staging.master', 'success', 'legal/cla')
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
env.run_crons()
[ADD] runbot_merge: one more test, still doesn't repro staging 13
2018-09-19 23:49:52 +07:00
new_staging = repo.commit('heads/staging.master')
assert new_staging.id != old_staging.id
# confirm again
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status('heads/staging.master', 'success', 'legal/cla')
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
env.run_crons()
[ADD] runbot_merge: one more test, still doesn't repro staging 13
2018-09-19 23:49:52 +07:00
messages = {
c['commit']['message']
for c in repo.log('heads/master')
}
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
reviewer = get_partner(env, users["reviewer"]).formatted_email
[ADD] runbot_merge: one more test, still doesn't repro staging 13
2018-09-19 23:49:52 +07:00
assert messages == {
'initial', 'NO!',
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
part_of('a1', pr_a), part_of('a2', pr_a), f'A\n\ncloses {pr_a.display_name}\n\nSigned-off-by: {reviewer}',
part_of('b1', pr_b), part_of('b2', pr_b), f'B\n\ncloses {pr_b.display_name}\n\nSigned-off-by: {reviewer}',
part_of('c1', pr_c), part_of('c2', pr_c), f'C\n\ncloses {pr_c.display_name}\n\nSigned-off-by: {reviewer}',
[ADD] runbot_merge: one more test, still doesn't repro staging 13
2018-09-19 23:49:52 +07:00
}
[FIX] runbot_merge: properly handle retarget from deactivated branch A deactivated branch is generally treated as unmanaged which is mostly correct except for the case of retargeting an existing PR. When a branch is deactivated the corresponding PRs are not removed, so it's possible to have live PRs associated with ~unmanamaged branches. When retargeting those PRs to active branches, the mergebot would assume there was no existing PR and would create a duplicate, then either get completely lost (before a84595ea04feec74b972eb05bcf30b6be2f83729) or blow up (after the same). Properly search amongst deactivated branches for retargeting sources so we update the relevant PR instead of trying to create duplicates. Fixes #169
2019-08-27 16:23:34 +07:00
class TestPREdition:
[IMP] runbot_merge: backend UI - Update branch name to prefix with project as it can be hard to differentiate when filtering by or trying to set targets, given some targets are extremely common (e.g. `master`/`main`) and not all fields are filtered by project (or even can be). - Add a proper menu item and list view for batches, maybe it'll be of use one day. - Upgrade label in PR search, it's more likely to be needed than author or target. - Put PRs first in the mergebot menu, as it's *by far* the most likely item to look for, unless it's staging in order to cancel one.
2024-07-15 20:52:08 +07:00
def test_edit(self, env, project, repo, config):
[FIX] runbot_merge: properly handle retarget from deactivated branch A deactivated branch is generally treated as unmanaged which is mostly correct except for the case of retargeting an existing PR. When a branch is deactivated the corresponding PRs are not removed, so it's possible to have live PRs associated with ~unmanamaged branches. When retargeting those PRs to active branches, the mergebot would assume there was no existing PR and would create a duplicate, then either get completely lost (before a84595ea04feec74b972eb05bcf30b6be2f83729) or blow up (after the same). Properly search amongst deactivated branches for retargeting sources so we update the relevant PR instead of trying to create duplicates. Fixes #169
2019-08-27 16:23:34 +07:00
""" Editing PR:
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[FIX] runbot_merge: properly handle retarget from deactivated branch A deactivated branch is generally treated as unmanaged which is mostly correct except for the case of retargeting an existing PR. When a branch is deactivated the corresponding PRs are not removed, so it's possible to have live PRs associated with ~unmanamaged branches. When retargeting those PRs to active branches, the mergebot would assume there was no existing PR and would create a duplicate, then either get completely lost (before a84595ea04feec74b972eb05bcf30b6be2f83729) or blow up (after the same). Properly search amongst deactivated branches for retargeting sources so we update the relevant PR instead of trying to create duplicates. Fixes #169
2019-08-27 16:23:34 +07:00
* title (-> message)
* body (-> message)
* base.ref (-> target)
"""
branch_1 = env['runbot_merge.branch'].create({
'name': '1.0',
'project_id': env['runbot_merge.project'].search([]).id,
})
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
repo.make_ref('heads/1.0', m)
repo.make_ref('heads/2.0', m)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
c2 = repo.make_commit(c1, 'second', None, tree={'m': 'c2'})
prx = repo.make_pr(title='title', body='body', target='master', head=c2)
[FIX] runbot_merge: unstage on staging-relevant PR modifications Stagings would be cancelled automatically if the PR's commits were updated, but not if the target (base) was changed, even though that has a drastic impact on staging. Add hooks to unstage PRs if their base is updated, or if their message is updated and relevant to staging (merge or rebase-merge methods). Fixes #604
2022-06-09 13:55:34 +07:00
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen rebase-ff r+', config['role_reviewer']['token'])
env.run_crons()
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[FIX] runbot_merge: unstage on staging-relevant PR modifications Stagings would be cancelled automatically if the PR's commits were updated, but not if the target (base) was changed, even though that has a drastic impact on staging. Add hooks to unstage PRs if their base is updated, or if their message is updated and relevant to staging (merge or rebase-merge methods). Fixes #604
2022-06-09 13:55:34 +07:00
assert pr.state == 'ready'
st = pr.staging_id
assert st
[FIX] runbot_merge: properly handle retarget from deactivated branch A deactivated branch is generally treated as unmanaged which is mostly correct except for the case of retargeting an existing PR. When a branch is deactivated the corresponding PRs are not removed, so it's possible to have live PRs associated with ~unmanamaged branches. When retargeting those PRs to active branches, the mergebot would assume there was no existing PR and would create a duplicate, then either get completely lost (before a84595ea04feec74b972eb05bcf30b6be2f83729) or blow up (after the same). Properly search amongst deactivated branches for retargeting sources so we update the relevant PR instead of trying to create duplicates. Fixes #169
2019-08-27 16:23:34 +07:00
assert pr.message == 'title\n\nbody'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo: prx.title = "title 2"
[FIX] runbot_merge: properly handle retarget from deactivated branch A deactivated branch is generally treated as unmanaged which is mostly correct except for the case of retargeting an existing PR. When a branch is deactivated the corresponding PRs are not removed, so it's possible to have live PRs associated with ~unmanamaged branches. When retargeting those PRs to active branches, the mergebot would assume there was no existing PR and would create a duplicate, then either get completely lost (before a84595ea04feec74b972eb05bcf30b6be2f83729) or blow up (after the same). Properly search amongst deactivated branches for retargeting sources so we update the relevant PR instead of trying to create duplicates. Fixes #169
2019-08-27 16:23:34 +07:00
assert pr.message == 'title 2\n\nbody'
[FIX] runbot_merge: correctly handle emptying PR body The previous version of the code assumed `pr['body']` is always a string, which is not correct, when the PR body is emptied the body itself is removed (its value is `None`). Add a case for this in the PR edition test, and avoid blowing up (or adding empty newlines) when the PR body is empty. For PR creation this issue was fixed in c2db5659d8d325939db66b07d0cb257e749bea82 but apparently I missed that the exact same issue occurs just a few lines above. Also turns out github does *not* send change information when the body is updated from (or to?) `None`, so don't even bother with that, just check every time if the overall message has been updated. Fixes #629
2022-07-11 19:00:35 +07:00
with repo: prx.body = None
assert pr.message == "title 2"
[FIX] runbot_merge: unstage on staging-relevant PR modifications Stagings would be cancelled automatically if the PR's commits were updated, but not if the target (base) was changed, even though that has a drastic impact on staging. Add hooks to unstage PRs if their base is updated, or if their message is updated and relevant to staging (merge or rebase-merge methods). Fixes #604
2022-06-09 13:55:34 +07:00
assert pr.staging_id, \
"message edition does not affect staging of rebased PRs"
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo: prx.base = '1.0'
[FIX] runbot_merge: properly handle retarget from deactivated branch A deactivated branch is generally treated as unmanaged which is mostly correct except for the case of retargeting an existing PR. When a branch is deactivated the corresponding PRs are not removed, so it's possible to have live PRs associated with ~unmanamaged branches. When retargeting those PRs to active branches, the mergebot would assume there was no existing PR and would create a duplicate, then either get completely lost (before a84595ea04feec74b972eb05bcf30b6be2f83729) or blow up (after the same). Properly search amongst deactivated branches for retargeting sources so we update the relevant PR instead of trying to create duplicates. Fixes #169
2019-08-27 16:23:34 +07:00
assert pr.target == branch_1
[FIX] runbot_merge: unstage on staging-relevant PR modifications Stagings would be cancelled automatically if the PR's commits were updated, but not if the target (base) was changed, even though that has a drastic impact on staging. Add hooks to unstage PRs if their base is updated, or if their message is updated and relevant to staging (merge or rebase-merge methods). Fixes #604
2022-06-09 13:55:34 +07:00
assert not pr.staging_id, "updated the base of a staged PR should have unstaged it"
[CHG] runbot_merge: move staging readiness to batch Staging readiness is a batch-level concerns, and many of the markers are already there though a few need to be aggregated from the PRs. As such, staging has no reason to be performed in terms of PRs anymore, it should be performed via batches directly. There is a bit of a mess in order not to completely fuck up when retargeting PRs (implicitly via freeze wizard, or explicitely) as for now we're moving PRs between batches in order to keep the batches *mostly* target-bound. Some of the side-effects in managing the coherence of the targeting and moving PRs between batches is... not great. This might need to be revisited and cleaned up with those scenarios better considered.
2024-02-05 22:10:15 +07:00
assert st.state == 'cancelled', f"expected cancellation, got {st.state}"
[IMP] runbot_merge: backend UI - Update branch name to prefix with project as it can be hard to differentiate when filtering by or trying to set targets, given some targets are extremely common (e.g. `master`/`main`) and not all fields are filtered by project (or even can be). - Add a proper menu item and list view for batches, maybe it'll be of use one day. - Upgrade label in PR search, it's more likely to be needed than author or target. - Put PRs first in the mergebot menu, as it's *by far* the most likely item to look for, unless it's staging in order to cancel one.
2024-07-15 20:52:08 +07:00
assert st.reason == f"{pr.display_name} target (base) branch was changed from '{project.name}:master' to '{project.name}:1.0'"
[FIX] runbot_merge: properly handle retarget from deactivated branch A deactivated branch is generally treated as unmanaged which is mostly correct except for the case of retargeting an existing PR. When a branch is deactivated the corresponding PRs are not removed, so it's possible to have live PRs associated with ~unmanamaged branches. When retargeting those PRs to active branches, the mergebot would assume there was no existing PR and would create a duplicate, then either get completely lost (before a84595ea04feec74b972eb05bcf30b6be2f83729) or blow up (after the same). Properly search amongst deactivated branches for retargeting sources so we update the relevant PR instead of trying to create duplicates. Fixes #169
2019-08-27 16:23:34 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo: prx.base = '2.0'
[FIX] runbot_merge: properly handle retarget from deactivated branch A deactivated branch is generally treated as unmanaged which is mostly correct except for the case of retargeting an existing PR. When a branch is deactivated the corresponding PRs are not removed, so it's possible to have live PRs associated with ~unmanamaged branches. When retargeting those PRs to active branches, the mergebot would assume there was no existing PR and would create a duplicate, then either get completely lost (before a84595ea04feec74b972eb05bcf30b6be2f83729) or blow up (after the same). Properly search amongst deactivated branches for retargeting sources so we update the relevant PR instead of trying to create duplicates. Fixes #169
2019-08-27 16:23:34 +07:00
assert not pr.exists()
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[FIX] runbot_merge: properly update squash flag on PR retarget closes #82
2019-03-04 15:52:21 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo: prx.base = '1.0'
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
assert to_pr(env, prx).target == branch_1
[FIX] runbot_merge: properly update squash flag on PR retarget closes #82
2019-03-04 15:52:21 +07:00
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
def test_retarget_update_commits(self, env, project, repo):
""" Retargeting a PR should update its commits count, as well as follow
the new target's requirements
[FIX] runbot_merge: properly handle retarget from deactivated branch A deactivated branch is generally treated as unmanaged which is mostly correct except for the case of retargeting an existing PR. When a branch is deactivated the corresponding PRs are not removed, so it's possible to have live PRs associated with ~unmanamaged branches. When retargeting those PRs to active branches, the mergebot would assume there was no existing PR and would create a duplicate, then either get completely lost (before a84595ea04feec74b972eb05bcf30b6be2f83729) or blow up (after the same). Properly search amongst deactivated branches for retargeting sources so we update the relevant PR instead of trying to create duplicates. Fixes #169
2019-08-27 16:23:34 +07:00
"""
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
project.repo_ids.write({
'status_ids': [
(5, 0, 0),
(0, 0, {'context': 'a', 'branch_filter': [('name', '=', 'master')]}),
(0, 0, {'context': 'b', 'branch_filter': [('name', '!=', 'master')]}),
]
})
[FIX] runbot_merge: properly handle retarget from deactivated branch A deactivated branch is generally treated as unmanaged which is mostly correct except for the case of retargeting an existing PR. When a branch is deactivated the corresponding PRs are not removed, so it's possible to have live PRs associated with ~unmanamaged branches. When retargeting those PRs to active branches, the mergebot would assume there was no existing PR and would create a duplicate, then either get completely lost (before a84595ea04feec74b972eb05bcf30b6be2f83729) or blow up (after the same). Properly search amongst deactivated branches for retargeting sources so we update the relevant PR instead of trying to create duplicates. Fixes #169
2019-08-27 16:23:34 +07:00
branch_1 = env['runbot_merge.branch'].create({
'name': '1.0',
'project_id': env['runbot_merge.project'].search([]).id,
})
master = env['runbot_merge.branch'].search([('name', '=', 'master')])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] runbot_merge: further validation of squash update on retargeting It should have already been working, added an additional check for update-then-retarget just in case but that worked out of the box. So not sure why odoo/odoo#40106 failed. Closes #256
2019-11-18 20:21:16 +07:00
# master is 1 commit ahead of 1.0
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
[m] = repo.make_commits(None, Commit('initial', tree={'m': 'm'}), ref='heads/1.0')
[m2] = repo.make_commits(m, Commit('second', tree={'m': 'm2'}), ref='heads/master')
[FIX] runbot_merge: properly handle retarget from deactivated branch A deactivated branch is generally treated as unmanaged which is mostly correct except for the case of retargeting an existing PR. When a branch is deactivated the corresponding PRs are not removed, so it's possible to have live PRs associated with ~unmanamaged branches. When retargeting those PRs to active branches, the mergebot would assume there was no existing PR and would create a duplicate, then either get completely lost (before a84595ea04feec74b972eb05bcf30b6be2f83729) or blow up (after the same). Properly search amongst deactivated branches for retargeting sources so we update the relevant PR instead of trying to create duplicates. Fixes #169
2019-08-27 16:23:34 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
# the PR builds on master, but is errorneously targeted to 1.0
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
repo.make_commits(m2, Commit('first', tree={'m': 'm3'}), ref='heads/abranch')
prx = repo.make_pr(title='title', body='body', target='1.0', head='abranch')
repo.post_status('heads/abranch', 'success', 'a')
env.run_crons()
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[FIX] runbot_merge: properly handle retarget from deactivated branch A deactivated branch is generally treated as unmanaged which is mostly correct except for the case of retargeting an existing PR. When a branch is deactivated the corresponding PRs are not removed, so it's possible to have live PRs associated with ~unmanamaged branches. When retargeting those PRs to active branches, the mergebot would assume there was no existing PR and would create a duplicate, then either get completely lost (before a84595ea04feec74b972eb05bcf30b6be2f83729) or blow up (after the same). Properly search amongst deactivated branches for retargeting sources so we update the relevant PR instead of trying to create duplicates. Fixes #169
2019-08-27 16:23:34 +07:00
assert not pr.squash
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
assert pr.status == 'pending'
assert pr.state == 'opened'
[FIX] runbot_merge: properly update squash flag on PR retarget closes #82
2019-03-04 15:52:21 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.base = 'master'
[FIX] runbot_merge: properly handle retarget from deactivated branch A deactivated branch is generally treated as unmanaged which is mostly correct except for the case of retargeting an existing PR. When a branch is deactivated the corresponding PRs are not removed, so it's possible to have live PRs associated with ~unmanamaged branches. When retargeting those PRs to active branches, the mergebot would assume there was no existing PR and would create a duplicate, then either get completely lost (before a84595ea04feec74b972eb05bcf30b6be2f83729) or blow up (after the same). Properly search amongst deactivated branches for retargeting sources so we update the relevant PR instead of trying to create duplicates. Fixes #169
2019-08-27 16:23:34 +07:00
assert pr.target == master
assert pr.squash
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
assert pr.status == 'success'
assert pr.state == 'validated'
[FIX] runbot_merge: properly update squash flag on PR retarget closes #82
2019-03-04 15:52:21 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.base = '1.0'
[FIX] runbot_merge: properly handle retarget from deactivated branch A deactivated branch is generally treated as unmanaged which is mostly correct except for the case of retargeting an existing PR. When a branch is deactivated the corresponding PRs are not removed, so it's possible to have live PRs associated with ~unmanamaged branches. When retargeting those PRs to active branches, the mergebot would assume there was no existing PR and would create a duplicate, then either get completely lost (before a84595ea04feec74b972eb05bcf30b6be2f83729) or blow up (after the same). Properly search amongst deactivated branches for retargeting sources so we update the relevant PR instead of trying to create duplicates. Fixes #169
2019-08-27 16:23:34 +07:00
assert pr.target == branch_1
assert not pr.squash
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
assert pr.status == 'pending'
assert pr.state == 'opened'
[FIX] runbot_merge: properly update squash flag on PR retarget closes #82
2019-03-04 15:52:21 +07:00
[IMP] runbot_merge: further validation of squash update on retargeting It should have already been working, added an additional check for update-then-retarget just in case but that worked out of the box. So not sure why odoo/odoo#40106 failed. Closes #256
2019-11-18 20:21:16 +07:00
# check if things also work right when modifying the PR then
# retargeting (don't see why not but...)
with repo:
c2 = repo.make_commit(m2, 'xxx', None, tree={'m': 'm4'})
repo.update_ref(prx.ref, c2, force=True)
assert pr.head == c2
assert not pr.squash
with repo:
prx.base = 'master'
assert pr.squash
[ADD] runbot_merge: tests to check behaviour of github in case of updating closed PRs
2020-02-07 22:15:26 +07:00
@pytest.mark.xfail(reason="github doesn't allow retargeting closed PRs", strict=True)
def test_retarget_closed(self, env, repo):
branch_1 = env['runbot_merge.branch'].create({
'name': '1.0',
'project_id': env['runbot_merge.project'].search([]).id,
})
with repo:
# master is 1 commit ahead of 1.0
[m] = repo.make_commits(None, repo.Commit('initial', tree={'1': '1'}), ref='heads/1.0')
repo.make_commits(m, repo.Commit('second', tree={'m': 'm'}), ref='heads/master')
[c] = repo.make_commits(m, repo.Commit('first', tree={'m': 'm3'}), ref='heads/abranch')
prx = repo.make_pr(title='title', body='body', target='1.0', head=c)
env.run_crons()
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[ADD] runbot_merge: tests to check behaviour of github in case of updating closed PRs
2020-02-07 22:15:26 +07:00
assert pr.target == branch_1
with repo:
prx.close()
with repo:
prx.base = 'master'
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
def test_close_staged(env, repo, config, page):
[FIX] runbot_merge: when closing a staged PR, cancel the staging
2018-05-31 21:50:36 +07:00
"""
When closing a staged PR, cancel the staging
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
c = repo.make_commit(m, 'fist', None, tree={'m': 'c1'})
prx = repo.make_pr(title='title', body='body', target='master', head=c)
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen r+', config['role_reviewer']['token'])
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
assert pr.reviewed_by
[FIX] runbot_merge: when closing a staged PR, cancel the staging
2018-05-31 21:50:36 +07:00
assert pr.state == 'ready'
assert pr.staging_id
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.close()
env.run_crons()
[FIX] runbot_merge: when closing a staged PR, cancel the staging
2018-05-31 21:50:36 +07:00
assert not pr.staging_id
assert not env['runbot_merge.stagings'].search([])
[FIX] runbot_merge: tagging on closed PR Closed tagging was broken since the raw-sql alterations of the close hook: because it's raw SQL, the write() method doesn't get invoked anymore and as a result the tagging feedback record is not created, and never executed. Add a test to check for the PR's proper tagging, and fix this issue by explicitly creating a tagging record. Closes #49
2018-11-22 22:01:44 +07:00
assert pr.state == 'closed'
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
assert pr_page(page, prx).cssselect('.alert-light')
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
assert not pr.reviewed_by
with repo:
prx.open()
assert pr.state == 'validated'
assert not pr.reviewed_by
with repo:
prx.post_comment('hansen r+', config['role_reviewer']['token'])
assert pr.reviewed_by
pr.write({'closed': True})
assert not pr.reviewed_by
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_forward_port(env, repo, config):
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
head = m
for i in range(110):
head = repo.make_commit(head, 'c_%03d' % i, None, tree={'m': 'm', 'f': str(i)})
# not sure why we wanted to wait here
with repo:
pr = repo.make_pr(title='PR', body=None, target='master', head=head)
repo.post_status(pr.head, 'success', 'legal/cla')
repo.post_status(pr.head, 'success', 'ci/runbot')
pr.post_comment('hansen r+ merge', config['role_reviewer']['token'])
env.run_crons()
[FIX] runbot_merge: handling of PRs of >50 commits A limitation to 50 commits PRs was put in place to avoid rebasing huge PRs (as a rebase means 1 merge + 1 commit *per source commit*), however the way it was done would also limit regular merges, and the way the limitation was implemented was not clear. * explicitly check that limit in the rebase case * make error message on PR sizes (rebase 50 or merge 250) clearer * remove limit from commits-fetching (check it beforehand) * add a test to merge >50 commits PRs * fix the local implementation of pulls/:number/commits to properly paginate
2018-09-20 20:02:18 +07:00
[IMP] runbot_merge: remove unnecessary uniquifier dummy commits "Uniquifier" commits were introduced to ensure branches of a staging on which nothing had been staged would still be rebuilt properly. This means technically the branches on which something had been staged never *needed* a uniquifier, strictly speaking. And those lead to extra building, because once the actually staged PRs get pushed from staging to their final destination it's an unknown commit to the runbot, which needs to rebuild it instead of being able to just use the staging it already has. Thus only add the uniquifier where it *might* be necessary: technically the runbot should not manage this use case much better, however there are still issues like an ancillary build working with the same branch tip (e.g. the "current master") and sending a failure result which would fail the entire staging. The uniquifier guards against this issue. Also update rebase semantics to always update the *commit date* of the rebased commits: this ensures the tip commit is always "recent" in the case of a rebase-ff (which is common as that's what single-commit PRs do), as the runbot may skip commits it considers "old". Also update some of the utility methods around repos / commits to be simpler, and avoid assuming the result is JSON-decodable (sometimes it is not). Also update the handling of commit statuses using postgres' ON CONFLICT and jsonb support, hopefully this improves (or even fixes) the serialization errors. Should be compatible with 9.5 onwards which is *ancient* at this point. Fixes #509
2021-08-09 18:21:24 +07:00
st = repo.commit('staging.master')
[FIX] runbot_merge: handling of PRs of >50 commits A limitation to 50 commits PRs was put in place to avoid rebasing huge PRs (as a rebase means 1 merge + 1 commit *per source commit*), however the way it was done would also limit regular merges, and the way the limitation was implemented was not clear. * explicitly check that limit in the rebase case * make error message on PR sizes (rebase 50 or merge 250) clearer * remove limit from commits-fetching (check it beforehand) * add a test to merge >50 commits PRs * fix the local implementation of pulls/:number/commits to properly paginate
2018-09-20 20:02:18 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
repo.post_status('staging.master', 'success', 'legal/cla')
repo.post_status('staging.master', 'success', 'ci/runbot')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[FIX] runbot_merge: handling of PRs of >50 commits A limitation to 50 commits PRs was put in place to avoid rebasing huge PRs (as a rebase means 1 merge + 1 commit *per source commit*), however the way it was done would also limit regular merges, and the way the limitation was implemented was not clear. * explicitly check that limit in the rebase case * make error message on PR sizes (rebase 50 or merge 250) clearer * remove limit from commits-fetching (check it beforehand) * add a test to merge >50 commits PRs * fix the local implementation of pulls/:number/commits to properly paginate
2018-09-20 20:02:18 +07:00
[IMP] runbot_merge: remove unnecessary uniquifier dummy commits "Uniquifier" commits were introduced to ensure branches of a staging on which nothing had been staged would still be rebuilt properly. This means technically the branches on which something had been staged never *needed* a uniquifier, strictly speaking. And those lead to extra building, because once the actually staged PRs get pushed from staging to their final destination it's an unknown commit to the runbot, which needs to rebuild it instead of being able to just use the staging it already has. Thus only add the uniquifier where it *might* be necessary: technically the runbot should not manage this use case much better, however there are still issues like an ancillary build working with the same branch tip (e.g. the "current master") and sending a failure result which would fail the entire staging. The uniquifier guards against this issue. Also update rebase semantics to always update the *commit date* of the rebased commits: this ensures the tip commit is always "recent" in the case of a rebase-ff (which is common as that's what single-commit PRs do), as the runbot may skip commits it considers "old". Also update some of the utility methods around repos / commits to be simpler, and avoid assuming the result is JSON-decodable (sometimes it is not). Also update the handling of commit statuses using postgres' ON CONFLICT and jsonb support, hopefully this improves (or even fixes) the serialization errors. Should be compatible with 9.5 onwards which is *ancient* at this point. Fixes #509
2021-08-09 18:21:24 +07:00
h = repo.commit('master')
assert st.id == h.id
[FIX] runbot_merge: handling of PRs of >50 commits A limitation to 50 commits PRs was put in place to avoid rebasing huge PRs (as a rebase means 1 merge + 1 commit *per source commit*), however the way it was done would also limit regular merges, and the way the limitation was implemented was not clear. * explicitly check that limit in the rebase case * make error message on PR sizes (rebase 50 or merge 250) clearer * remove limit from commits-fetching (check it beforehand) * add a test to merge >50 commits PRs * fix the local implementation of pulls/:number/commits to properly paginate
2018-09-20 20:02:18 +07:00
assert set(h.parents) == {m, pr.head}
[IMP] runbot_merge: remove unnecessary uniquifier dummy commits "Uniquifier" commits were introduced to ensure branches of a staging on which nothing had been staged would still be rebuilt properly. This means technically the branches on which something had been staged never *needed* a uniquifier, strictly speaking. And those lead to extra building, because once the actually staged PRs get pushed from staging to their final destination it's an unknown commit to the runbot, which needs to rebuild it instead of being able to just use the staging it already has. Thus only add the uniquifier where it *might* be necessary: technically the runbot should not manage this use case much better, however there are still issues like an ancillary build working with the same branch tip (e.g. the "current master") and sending a failure result which would fail the entire staging. The uniquifier guards against this issue. Also update rebase semantics to always update the *commit date* of the rebased commits: this ensures the tip commit is always "recent" in the case of a rebase-ff (which is common as that's what single-commit PRs do), as the runbot may skip commits it considers "old". Also update some of the utility methods around repos / commits to be simpler, and avoid assuming the result is JSON-decodable (sometimes it is not). Also update the handling of commit statuses using postgres' ON CONFLICT and jsonb support, hopefully this improves (or even fixes) the serialization errors. Should be compatible with 9.5 onwards which is *ancient* at this point. Fixes #509
2021-08-09 18:21:24 +07:00
commits = {c['sha'] for c in repo.log('master')}
[FIX] runbot_merge: handling of PRs of >50 commits A limitation to 50 commits PRs was put in place to avoid rebasing huge PRs (as a rebase means 1 merge + 1 commit *per source commit*), however the way it was done would also limit regular merges, and the way the limitation was implemented was not clear. * explicitly check that limit in the rebase case * make error message on PR sizes (rebase 50 or merge 250) clearer * remove limit from commits-fetching (check it beforehand) * add a test to merge >50 commits PRs * fix the local implementation of pulls/:number/commits to properly paginate
2018-09-20 20:02:18 +07:00
assert len(commits) == 112
[IMP] *: testing helpers * add a sorted method on fake models * fix recordset equality to ignore ids order * when creating commits on a ref, add a param to only *update* the ref (forcefully): when simulating a force-push we don't want to *create* a ref as that might silently be done in the wrong repository entirely * fix pytest.skip call at the module level, not sure where it came from and why I missed it until now
2019-10-14 14:33:21 +07:00
@pytest.mark.skip("Needs to find a way to make set_ref fail on *second* call.")
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_rebase_failure(env, repo, users, config):
[FIX] runbot_merge: forcefully rollback ref after a failed rebase() rebase() can fail after merge(), during set_ref(), having already updated the target. Under the pre-rebase model, stage() assumed on a staging failure on a given repo it only had to rollback stagings having succeeded. This assumption fails in a post-rebase model as even a failed staging can have modified the target, leading to the next staging (if multiple batches are ready) containing the failed one. Things can get really strange if the set_ref failure was (as it probably is) some sort of transient failure, as the following staging will likely succeed (under the assumption that most PRs/batches pass staging) as PR1's content gets merged as part of PR2, and PR2 is merged empty of content later on.
2018-10-17 19:18:49 +07:00
""" It looks like gh.rebase() can fail in the final ref-setting after
the merging & commits creation has been performed. At this point, the
staging will fail (yay) but the target branch (tmp) would not get reset,
leading to the next PR being staged *on top* of the one being staged
right there, and pretty much integrating it, leading to very, very
strange results if the entire thing passes staging.
Seen: https://github.com/odoo/odoo/pull/27835#issuecomment-430505429
PR 27835 was merged to tmp at df0ae6c00e085dbaabcfec821208c9ace2f4b02d
then the set_ref failed, following which PR 27840 is merged to tmp at
819b5414c27a92031a9ce3f159a8f466a4fd698c note that the first (left)
parent is the merge commit from PR 27835. The set_ref of PR 27840
succeeded resulting in PR 27835 being integrated into the squashing of
27840 (without any renaming or anything, just the content), following
which PR 27835 was merged and squashed as a "no-content" commit.
Problem: I need to make try_staging > stage > rebase > set_ref fail
but only the first time, and not the set_ref in try_staging itself, and
that call is performed *in a subprocess* when running <remote> tests.
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
[FIX] runbot_merge: forcefully rollback ref after a failed rebase() rebase() can fail after merge(), during set_ref(), having already updated the target. Under the pre-rebase model, stage() assumed on a staging failure on a given repo it only had to rollback stagings having succeeded. This assumption fails in a post-rebase model as even a failed staging can have modified the target, leading to the next staging (if multiple batches are ready) containing the failed one. Things can get really strange if the set_ref failure was (as it probably is) some sort of transient failure, as the following staging will likely succeed (under the assumption that most PRs/batches pass staging) as PR1's content gets merged as part of PR2, and PR2 is merged empty of content later on.
2018-10-17 19:18:49 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
commit_a = repo.make_commit(m, 'A', None, tree={'m': 'm', 'a': 'a'})
repo.make_ref('heads/a', commit_a)
pr_a = repo.make_pr(title='A', body=None, target='master', head='a')
repo.post_status(pr_a.head, 'success', 'ci/runbot')
repo.post_status(pr_a.head, 'success', 'legal/cla')
pr_a.post_comment('hansen r+', config['role_reviewer']['token'])
[FIX] runbot_merge: forcefully rollback ref after a failed rebase() rebase() can fail after merge(), during set_ref(), having already updated the target. Under the pre-rebase model, stage() assumed on a staging failure on a given repo it only had to rollback stagings having succeeded. This assumption fails in a post-rebase model as even a failed staging can have modified the target, leading to the next staging (if multiple batches are ready) containing the failed one. Things can get really strange if the set_ref failure was (as it probably is) some sort of transient failure, as the following staging will likely succeed (under the assumption that most PRs/batches pass staging) as PR1's content gets merged as part of PR2, and PR2 is merged empty of content later on.
2018-10-17 19:18:49 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
commit_b = repo.make_commit(m, 'B', None, tree={'m': 'm', 'b': 'b'})
repo.make_ref('heads/b', commit_b)
pr_b = repo.make_pr(title='B', body=None, target='master', head='b')
repo.post_status(pr_b.head, 'success', 'ci/runbot')
repo.post_status(pr_b.head, 'success', 'legal/cla')
pr_b.post_comment('hansen r+', config['role_reviewer']['token'])
[FIX] runbot_merge: forcefully rollback ref after a failed rebase() rebase() can fail after merge(), during set_ref(), having already updated the target. Under the pre-rebase model, stage() assumed on a staging failure on a given repo it only had to rollback stagings having succeeded. This assumption fails in a post-rebase model as even a failed staging can have modified the target, leading to the next staging (if multiple batches are ready) containing the failed one. Things can get really strange if the set_ref failure was (as it probably is) some sort of transient failure, as the following staging will likely succeed (under the assumption that most PRs/batches pass staging) as PR1's content gets merged as part of PR2, and PR2 is merged empty of content later on.
2018-10-17 19:18:49 +07:00
from odoo.addons.runbot_merge.github import GH
original = GH.set_ref
counter = itertools.count(start=1)
def wrapper(*args):
assert next(counter) != 2, "make it seem like updating the branch post-rebase fails"
return original(*args)
[IMP] runbot_merge: extract commit validation to cron Before this, impacting a commit's statuses on the relevant PR or staging would be performed immediatly / inline with its consumption. This, however, is problematic if we want to implement additional processing like #87 (and possibly though probably not #52): webhook handlers should be kept short and fast, feeding back into github would not be acceptable. - flag commits as needing processing instead of processing them immediately, this uses a partial index as it looks like the recommended / proper way to index a boolean column in which one of the values is searched much more than the other (todo: eventually check if that actually does anythnig) - add a new cron for commits processing - alter tests so they use this new cron (mostly by migrating them to `run_crons` though not solely as some still need more detailed management to properly check intermediate steps) Fix an issue with closing a staged PR while at it (the "merging" tag would potentially never be removed).
2019-03-05 14:01:38 +07:00
env['runbot_merge.commit']._notify()
[IMP] forwardport: unmodified fw automatically inherit overrides Before this change, a CI override would have to be replicated on most / all forward-ports of the base PR. This was intentional to see how it would shake out, the answer being that it's rather annoying. Also add a `statuses_full` computed field on PRs for the aggregate status: the existing `statuses` field is just a copy of the commit statuses which I didn't remember I kept free of the overrides so the commit statuses could be displayed "as-is" in the backend (the overrides are displayed separately). And while at it fix the PR dashboard to use that new field: that was basically the intention but then I went on to use the "wrong" field hence #433. Mebbe the UI part should be displayed using a computed M2M (?) as a table or as tags instead? This m2m could indicate whether the status is an override or an "intrinsic" status. Also removed some dead code: * leftover from the removed tagging feature (removed the tag manipulation but forgot some of the setup / computations) * unused local variables * an empty skipped test case Fixes #439. Fixes #433.
2021-01-13 14:18:17 +07:00
with mock.patch.object(GH, 'set_ref', autospec=True, side_effect=wrapper):
[FIX] runbot_merge: forcefully rollback ref after a failed rebase() rebase() can fail after merge(), during set_ref(), having already updated the target. Under the pre-rebase model, stage() assumed on a staging failure on a given repo it only had to rollback stagings having succeeded. This assumption fails in a post-rebase model as even a failed staging can have modified the target, leading to the next staging (if multiple batches are ready) containing the failed one. Things can get really strange if the set_ref failure was (as it probably is) some sort of transient failure, as the following staging will likely succeed (under the assumption that most PRs/batches pass staging) as PR1's content gets merged as part of PR2, and PR2 is merged empty of content later on.
2018-10-17 19:18:49 +07:00
env['runbot_merge.project']._check_progress()
[IMP] runbot_merge: small reorg of main models file To prep for the addition of the freeze wizard: * move projects out of `pull_requests.py` * then realize half the methods there have no relation to projects and move them to more relevant places in `pull_requests.py` * update corresponding crons (and tests using those crons) as the methods have changed model, and the cron definitions thus need to be updated * split update to labels out of sending feedback comments while at it: labels are not used much during tests so their manipulation can be avoided; and labels are not as urgent as feedback so the crons can be quite a bit slower * move the project view out of `mergebot.xml` as well
2021-11-10 19:13:34 +07:00
env['runbot_merge.pull_requests.feedback']._send()
[IMP] runbot_merge: send integratin failure comment via feedback queue If a transient github failure makes the integration fail but also makes the following reset fail the entire staging process would be cancelled (and operations so far rollbacked) except for the failure comment which would be effected, as in odoo/odoo#26380. By pushing the comment to the feedback queue, if the reset fails the comment is rollbacked and "unqueued".
2018-11-27 17:53:10 +07:00
[FIX] runbot_merge: forcefully rollback ref after a failed rebase() rebase() can fail after merge(), during set_ref(), having already updated the target. Under the pre-rebase model, stage() assumed on a staging failure on a given repo it only had to rollback stagings having succeeded. This assumption fails in a post-rebase model as even a failed staging can have modified the target, leading to the next staging (if multiple batches are ready) containing the failed one. Things can get really strange if the set_ref failure was (as it probably is) some sort of transient failure, as the following staging will likely succeed (under the assumption that most PRs/batches pass staging) as PR1's content gets merged as part of PR2, and PR2 is merged empty of content later on.
2018-10-17 19:18:49 +07:00
assert pr_a.comments == [
(users['reviewer'], 'hansen r+'),
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
seen(env, pr_a, users),
[REF] forwardport: update re_matches to not use a regex Using a regex as the pattern is quite frustrating due to all the escaping necessary, which in this refactoring I found out I'd missed, multiple times. Convert the pattern to something bespoke but not too complicated, we may want to add anchoring support and a bit more finesse and the future but for now straightforward "holes" seem to work well. I've added support for capturing and even named groups even if this as yet unnecessary and unused. Fixes #861 [^1]: https://docs.pytest.org/en/stable/reference.html#pytest.hookspec.pytest_assertrepr_compare
2024-06-04 17:15:29 +07:00
(users['user'], matches('Unable to stage PR')),
[FIX] runbot_merge: forcefully rollback ref after a failed rebase() rebase() can fail after merge(), during set_ref(), having already updated the target. Under the pre-rebase model, stage() assumed on a staging failure on a given repo it only had to rollback stagings having succeeded. This assumption fails in a post-rebase model as even a failed staging can have modified the target, leading to the next staging (if multiple batches are ready) containing the failed one. Things can get really strange if the set_ref failure was (as it probably is) some sort of transient failure, as the following staging will likely succeed (under the assumption that most PRs/batches pass staging) as PR1's content gets merged as part of PR2, and PR2 is merged empty of content later on.
2018-10-17 19:18:49 +07:00
]
assert pr_b.comments == [
(users['reviewer'], 'hansen r+'),
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
seen(env, pr_b, users),
[FIX] runbot_merge: forcefully rollback ref after a failed rebase() rebase() can fail after merge(), during set_ref(), having already updated the target. Under the pre-rebase model, stage() assumed on a staging failure on a given repo it only had to rollback stagings having succeeded. This assumption fails in a post-rebase model as even a failed staging can have modified the target, leading to the next staging (if multiple batches are ready) containing the failed one. Things can get really strange if the set_ref failure was (as it probably is) some sort of transient failure, as the following staging will likely succeed (under the assumption that most PRs/batches pass staging) as PR1's content gets merged as part of PR2, and PR2 is merged empty of content later on.
2018-10-17 19:18:49 +07:00
]
assert repo.read_tree(repo.commit('heads/staging.master')) == {
[ADD] forwardbot * Cherrypicking is handrolled because there seems to be no easy way to programmatically edit commit messages during the cherrypicking sequence: `-n` basically squashes all commits and `-e` invokes a subprocess. `-e` with `VISUAL=false` kinda sorta works (in that it interrupts the process before each commit), however there doesn't seem to be clean status codes so it's difficult to know if the cherrypick failed or if it's just waiting for a commit of this step. Instead, cherrypick commits individually then edit / rewrite their commit messages: * add a reference to the original commit * convert signed-off-by to something else as the original commit was signed off but not necessarily this one * Can't assign users when creating PRs: only repository collaborators or people who commented on the issue / PR (which we're in the process of creating) can be assigned. PR authors are as likely to be collaborators as not, and we can have non-collaborator reviewers. So pinging via a regular comment seems less fraught as a way to notify users.
2019-08-23 21:16:30 +07:00
'm': 'm',
'b': 'b',
[FIX] runbot_merge: forcefully rollback ref after a failed rebase() rebase() can fail after merge(), during set_ref(), having already updated the target. Under the pre-rebase model, stage() assumed on a staging failure on a given repo it only had to rollback stagings having succeeded. This assumption fails in a post-rebase model as even a failed staging can have modified the target, leading to the next staging (if multiple batches are ready) containing the failed one. Things can get really strange if the set_ref failure was (as it probably is) some sort of transient failure, as the following staging will likely succeed (under the assumption that most PRs/batches pass staging) as PR1's content gets merged as part of PR2, and PR2 is merged empty of content later on.
2018-10-17 19:18:49 +07:00
}
[FIX runbot_merge: prevent reopening a merged PR Fixes #305
2020-02-10 15:48:03 +07:00
def test_reopen_merged_pr(env, repo, config, users):
""" Reopening a *merged* PR should cause us to immediately close it again,
and insult whoever did it
"""
with repo:
[m] = repo.make_commits(
None,
repo.Commit('initial', tree={'0': '0'}),
ref = 'heads/master'
)
[c] = repo.make_commits(
m, repo.Commit('second', tree={'0': '1'}),
ref='heads/abranch'
)
prx = repo.make_pr(target='master', head='abranch')
repo.post_status(c, 'success', 'legal/cla')
repo.post_status(c, 'success', 'ci/runbot')
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
with repo:
repo.post_status('staging.master', 'success', 'legal/cla')
repo.post_status('staging.master', 'success', 'ci/runbot')
env.run_crons()
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[FIX runbot_merge: prevent reopening a merged PR Fixes #305
2020-02-10 15:48:03 +07:00
assert prx.state == 'closed'
assert pr.state == 'merged'
repo.add_collaborator(users['other'], config['role_other']['token'])
with repo:
prx.open(config['role_other']['token'])
env.run_crons()
assert prx.state == 'closed'
assert pr.state == 'merged'
assert prx.comments == [
(users['reviewer'], 'hansen r+'),
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
seen(env, prx, users),
[IMP] *: review mergebot & forwardbot messages for pinging Old messages were quite inconsistent in their pinging of the PR author and reviewer. Reviewed messages (probably missed some but...) and try to more consistently ping when the feedback requires some sort of action in order to proceed. Fixes #592
2022-06-23 19:25:07 +07:00
(users['user'], "@%s ya silly goose you can't reopen a merged PR." % users['other'])
[FIX runbot_merge: prevent reopening a merged PR Fixes #305
2020-02-10 15:48:03 +07:00
]
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
class TestNoRequiredStatus:
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
@pytest.mark.defaultstatuses
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
def test_basic(self, env, repo, config):
""" check that mergebot can work on a repo with no CI at all
"""
[IMP] runbot_merge: split status configuration into own object Having the required statuses be a mere list of contexts has become a bit too limiting for our needs as it doesn't allow e.g. adding new required statuses on only some branches of a repository (e.g. only master), nor does it allow putting checks on only branches, or only stagings, which would be useful for overridable checks and the like, or for checks which only make sense linked to a specific revision range (e.g. "incremental" linting which would only check whatever's been modified in a PR). Split the required statuses into a separate set of objects, any of which can be separately marked as applying only to some branches (no branch = all branches). Fixes #382
2020-07-10 15:21:43 +07:00
env['runbot_merge.repository'].search([('name', '=', repo.name)]).status_ids = False
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
with repo:
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
[m, c] = repo.make_commits(
None,
Commit('initial', tree={'0': '0'}),
Commit('first', tree={'0': '1'}),
)
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
repo.make_ref('heads/master', m)
[FIX] runbot_merge: behaviour when no CI are required If the required_statuses are empty, PRs should always be validated (and just require a review) rather than never be merge-able. Fixes #216
2019-10-03 21:04:30 +07:00
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
pr = repo.make_pr(title='title', body='body', target='master', head=c)
pr.post_comment('hansen r+', config['role_reviewer']['token'])
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
env.run_crons()
[FIX] runbot_merge: behaviour when no CI are required If the required_statuses are empty, PRs should always be validated (and just require a review) rather than never be merge-able. Fixes #216
2019-10-03 21:04:30 +07:00
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
pr_id = to_pr(env, pr)
st = env['runbot_merge.stagings'].search([], context={'active_test': False})
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
assert st.state == 'success'
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
assert pr_id.state == 'merged'
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
@pytest.mark.defaultstatuses
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
def test_updated(self, env, repo, config):
[IMP] runbot_merge: split status configuration into own object Having the required statuses be a mere list of contexts has become a bit too limiting for our needs as it doesn't allow e.g. adding new required statuses on only some branches of a repository (e.g. only master), nor does it allow putting checks on only branches, or only stagings, which would be useful for overridable checks and the like, or for checks which only make sense linked to a specific revision range (e.g. "incremental" linting which would only check whatever's been modified in a PR). Split the required statuses into a separate set of objects, any of which can be separately marked as applying only to some branches (no branch = all branches). Fixes #382
2020-07-10 15:21:43 +07:00
env['runbot_merge.repository'].search([('name', '=', repo.name)]).status_ids = False
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
with repo:
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
[m, c] = repo.make_commits(
None,
Commit('initial', tree={'0': '0'}),
Commit('first', tree={'0': '1'}),
)
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
repo.make_ref('heads/master', m)
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
pr = repo.make_pr(title='title', body='body', target='master', head=c)
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
env.run_crons()
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
pr_id = to_pr(env, pr)
assert pr_id.state == 'validated'
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
# normal push
with repo:
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
repo.make_commits(c, repo.Commit('second', tree={'0': '2'}), ref=pr.ref)
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
env.run_crons()
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
assert pr_id.state == 'validated'
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
with repo:
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
pr.post_comment('hansen r+', config['role_reviewer']['token'])
assert pr_id.state == 'ready'
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
# force push
with repo:
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
repo.make_commits(m, repo.Commit('xxx', tree={'0': 'm'}), ref=pr.ref)
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
env.run_crons()
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
assert pr_id.state == 'validated'
[FIX] runbot_merge: updating PRs in repos without required statuses The PR creation had been fixed to always validate even without a commit found (in case there was no need for a commit), but the update of a PR in such a situation was not tested, and thus naturally did not work because why would it work if it wasn't tested? Also remove the conditional skip on updating a PR to a new head.
2020-02-07 22:11:12 +07:00
with repo:
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
pr.post_comment('hansen r+', config['role_reviewer']['token'])
assert pr_id.state == 'ready'
[FIX] runbot_merge: behaviour when no CI are required If the required_statuses are empty, PRs should always be validated (and just require a review) rather than never be merge-able. Fixes #216
2019-10-03 21:04:30 +07:00
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
class TestRetry:
@pytest.mark.xfail(reason="This may not be a good idea as it could lead to tons of rebuild spam")
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_auto_retry_push(self, env, repo, config):
[IMP] runbot_merge: send feedback on CI failure following r+ Will comment any time a statuses update folds to a CI failure on a reviewed pull request. Might be somewhat spammy, we'll see. No notification if the PR is not reviewed yet. fixes #87
2019-03-05 15:03:26 +07:00
prx = _simple_init(repo)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
repo.post_status(prx.head, 'success', 'ci/runbot')
repo.post_status(prx.head, 'success', 'legal/cla')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
assert to_pr(env, prx).staging_id
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
staging_head = repo.commit('heads/staging.master')
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
repo.post_status('staging.master', 'success', 'legal/cla')
repo.post_status('staging.master', 'failure', 'ci/runbot')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr.state == 'error'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
repo.update_ref(prx.ref, repo.make_commit(prx.head, 'third', None, tree={'m': 'c3'}), force=True)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr.state == 'approved'
env['runbot_merge.project']._check_progress()
assert pr.state == 'approved'
repo.post_status(prx.head, 'success', 'ci/runbot')
repo.post_status(prx.head, 'success', 'legal/cla')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr.state == 'ready'
staging_head2 = repo.commit('heads/staging.master')
assert staging_head2 != staging_head
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
repo.post_status('staging.master', 'success', 'legal/cla')
repo.post_status('staging.master', 'success', 'ci/runbot')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr.state == 'merged'
[IMP] allow delegate reviewers to retry and r-
2018-03-26 22:29:49 +07:00
@pytest.mark.parametrize('retrier', ['user', 'other', 'reviewer'])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_retry_comment(self, env, repo, retrier, users, config):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
""" An accepted but failed PR should be re-tried when the author or a
reviewer asks for it
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] runbot_merge: message when approving a PR in error I thought I'd removed the error message when approving an already approved PR but apparently not? However we can improve the message in that specific case, to make the expected operation clearer. Fixes #906
2024-07-09 19:06:19 +07:00
pr = _simple_init(repo)
repo.post_status(pr.head, 'success', 'ci/runbot')
repo.post_status(pr.head, 'success', 'legal/cla')
pr.post_comment(f'hansen r+ delegate={users["other"]} rebase-merge',
config["role_reviewer"]['token'])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] runbot_merge: message when approving a PR in error I thought I'd removed the error message when approving an already approved PR but apparently not? However we can improve the message in that specific case, to make the expected operation clearer. Fixes #906
2024-07-09 19:06:19 +07:00
pr_id = to_pr(env, pr)
assert pr_id.staging_id
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
staging_head = repo.commit('heads/staging.master')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
repo.post_status('staging.master', 'success', 'legal/cla')
repo.post_status('staging.master', 'failure', 'ci/runbot')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] runbot_merge: message when approving a PR in error I thought I'd removed the error message when approving an already approved PR but apparently not? However we can improve the message in that specific case, to make the expected operation clearer. Fixes #906
2024-07-09 19:06:19 +07:00
assert pr_id.state == 'error'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] runbot_merge: message when approving a PR in error I thought I'd removed the error message when approving an already approved PR but apparently not? However we can improve the message in that specific case, to make the expected operation clearer. Fixes #906
2024-07-09 19:06:19 +07:00
pr.post_comment('hansen r+ rebase-ff', config["role_reviewer"]['token'])
env.run_crons()
assert pr_id.state == 'error'
assert pr.comments == [
(users['reviewer'], f'hansen r+ delegate={users["other"]} rebase-merge'),
seen(env, pr, users),
(users['user'], 'Merge method set to rebase and merge, using the PR as merge commit message.'),
(users['user'], '@{user} @{reviewer} staging failed: ci/runbot'.format_map(users)),
(users['reviewer'], 'hansen r+ rebase-ff'),
(users['user'], "This PR is already reviewed, it's in error, you might want to `retry` it instead "
"(if you have already confirmed the error is not legitimate)."),
(users['user'], 'Merge method set to rebase and fast-forward.'),
]
assert pr_id.merge_method == 'rebase-ff'
with repo:
pr.post_comment('hansen retry', config['role_' + retrier]['token'])
assert pr_id.state == 'ready'
[IMP] *: trigger-ify staging cron The staging cron turns out to be pretty reasonable to trigger, as we already have a handler on the transition of a batch to `not blocked`, which is exactly when we want to create a staging (that and the completion of the previous staging). The batch transition is in a compute which is not awesome, but on the flip side we also cancel active stagings in that exact scenario (if it applies), so that matches. The only real finesse is that one of the tests wants to observe the instant between the end of a staging (and creation of splits) and the start of the next one, which because the staging cron is triggered by the failure of the previous staging is now "atomic", requiring disabling the staging cron, which means the trigger is skipped entirely. So this requires triggering the staging cron by hand.
2024-08-01 15:15:32 +07:00
env.run_crons(None)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
staging_head2 = repo.commit('heads/staging.master')
assert staging_head2 != staging_head
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
repo.post_status('staging.master', 'success', 'legal/cla')
repo.post_status('staging.master', 'success', 'ci/runbot')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] runbot_merge: message when approving a PR in error I thought I'd removed the error message when approving an already approved PR but apparently not? However we can improve the message in that specific case, to make the expected operation clearer. Fixes #906
2024-07-09 19:06:19 +07:00
assert pr_id.state == 'merged'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
def test_retry_again_message(self, env, repo, users, config, page):
""" For a retried PR, the error message on the PR's page should be the
later staging
"""
with repo:
pr = _simple_init(repo)
repo.post_status(pr.head, 'success', 'ci/runbot')
repo.post_status(pr.head, 'success', 'legal/cla')
pr.post_comment('hansen r+ delegate=%s rebase-merge' % users['other'],
config["role_reviewer"]['token'])
env.run_crons()
pr_id = to_pr(env, pr)
assert pr_id.staging_id
with repo:
repo.post_status('staging.master', 'success', 'legal/cla')
repo.post_status('staging.master', 'failure', 'ci/runbot',
target_url='https://example.com/whocares')
env.run_crons()
assert pr_id.state == 'error'
with repo:
pr.post_comment('hansen retry', config['role_reviewer']['token'])
[IMP] *: trigger-ify staging cron The staging cron turns out to be pretty reasonable to trigger, as we already have a handler on the transition of a batch to `not blocked`, which is exactly when we want to create a staging (that and the completion of the previous staging). The batch transition is in a compute which is not awesome, but on the flip side we also cancel active stagings in that exact scenario (if it applies), so that matches. The only real finesse is that one of the tests wants to observe the instant between the end of a staging (and creation of splits) and the start of the next one, which because the staging cron is triggered by the failure of the previous staging is now "atomic", requiring disabling the staging cron, which means the trigger is skipped entirely. So this requires triggering the staging cron by hand.
2024-08-01 15:15:32 +07:00
env.run_crons(None)
[FIX] runbot_message: error on PR page The page of PRs in "error" is currently kinda broken: it does not show any feedback aside from the PR being in error which is not very useful. The intent was always to show an explanation, but when adding the page I just deref'd `staging_id` which always fails though in two different ways: * when the PR can not be staged at all (because of a conflict) there is no staging at all with a reason to show, so there should be a fallback that the PR could not even be staged * `staging_id` is a related field which deref's to the staging_ids of the first *active* batch, except when a staging completes (successfully or not) both staging and batch are disabled. Plus the first batch will be the one for the first staging so if the PR is retried and fails again the wrong reason may be displayed. So update the section to show what we want: the reason of the staging of the *last* batch attached to the PR. NOTE: there's one failure mode remaining, namely if a staging fails then on retry the PR conflicts with the new state of the repository (so it can't be staged at all), the "reason" will remain that of the staging. This could be mitigated by attaching a "nonsense" batch on failure to stage (similar to the forwardport stuff), that batch would have no staging, therefore no staging reason, therefore fallback. Closes #525
2021-08-30 19:40:38 +07:00
with repo:
repo.post_status('staging.master', 'success', 'legal/cla')
repo.post_status('staging.master', 'failure', 'ci/runbot',
target_url='https://example.com/ohno')
env.run_crons()
assert pr_id.state == 'error'
dangerbox = pr_page(page, pr).cssselect('.alert-danger span')
assert dangerbox
assert dangerbox[0].text == 'ci/runbot (view more at https://example.com/ohno)'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_retry_ignored(self, env, repo, users, config):
[ADD] runbot_merge: various feedback messages Send reponse comments when users mis-interact with robodoo e.g. send comments they don't have the right to, or commands which don't make sense in the PR's state, or tentative interactions with robodoo from unmanaged PRs.
2018-10-16 17:40:45 +07:00
""" Check feedback in case of ignored retry command on a non-error PR.
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx = _simple_init(repo)
[IMP] runbot_merge: send merge method warning faster, and on review - Instead of warning about the merge method on ready PRs, also warn on *approved* (but exclude staged just cuz), as that's really when the user wants to know that they forgot to set the merge method - The cron only triggers hourly, but *if* a user approves a PR *and* the merge method is not set yet, chances are good they'll need a reminder (if they `r+ rebase-merge` or w/e the cron will just ignore the PR and it's no skin off our back), so `_trigger` the cron for validation. - Also do the same when skipchecks is set as it's very similar. In reality we might want to hook off of the state transitioning to reviewed but I'm not sure there's good ways to do that (triggering a cron inside a compute doesn't seem like a good idea). Update a pair of tests which would approve a multi-commit PR without setting a merge method, just because the helper they use to build the PR happens to create multiple commits. Fix #891
2024-06-13 18:30:07 +07:00
prx.post_comment('hansen r+ rebase-ff', config['role_reviewer']['token'])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx.post_comment('hansen retry', config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: various feedback messages Send reponse comments when users mis-interact with robodoo e.g. send comments they don't have the right to, or commands which don't make sense in the PR's state, or tentative interactions with robodoo from unmanaged PRs.
2018-10-16 17:40:45 +07:00
assert prx.comments == [
[IMP] runbot_merge: send merge method warning faster, and on review - Instead of warning about the merge method on ready PRs, also warn on *approved* (but exclude staged just cuz), as that's really when the user wants to know that they forgot to set the merge method - The cron only triggers hourly, but *if* a user approves a PR *and* the merge method is not set yet, chances are good they'll need a reminder (if they `r+ rebase-merge` or w/e the cron will just ignore the PR and it's no skin off our back), so `_trigger` the cron for validation. - Also do the same when skipchecks is set as it's very similar. In reality we might want to hook off of the state transitioning to reviewed but I'm not sure there's good ways to do that (triggering a cron inside a compute doesn't seem like a good idea). Update a pair of tests which would approve a multi-commit PR without setting a merge method, just because the helper they use to build the PR happens to create multiple commits. Fix #891
2024-06-13 18:30:07 +07:00
(users['reviewer'], 'hansen r+ rebase-ff'),
[ADD] runbot_merge: various feedback messages Send reponse comments when users mis-interact with robodoo e.g. send comments they don't have the right to, or commands which don't make sense in the PR's state, or tentative interactions with robodoo from unmanaged PRs.
2018-10-16 17:40:45 +07:00
(users['reviewer'], 'hansen retry'),
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
seen(env, prx, users),
[IMP] runbot_merge: send merge method warning faster, and on review - Instead of warning about the merge method on ready PRs, also warn on *approved* (but exclude staged just cuz), as that's really when the user wants to know that they forgot to set the merge method - The cron only triggers hourly, but *if* a user approves a PR *and* the merge method is not set yet, chances are good they'll need a reminder (if they `r+ rebase-merge` or w/e the cron will just ignore the PR and it's no skin off our back), so `_trigger` the cron for validation. - Also do the same when skipchecks is set as it's very similar. In reality we might want to hook off of the state transitioning to reviewed but I'm not sure there's good ways to do that (triggering a cron inside a compute doesn't seem like a good idea). Update a pair of tests which would approve a multi-commit PR without setting a merge method, just because the helper they use to build the PR happens to create multiple commits. Fix #891
2024-06-13 18:30:07 +07:00
(users['user'], "Merge method set to rebase and fast-forward."),
[CHG] runbot_merge, forwardbot: merge commands parser - move all commands parsing to runbot_merge as part of the long-term unification effort (#789) - set up an actual parser-ish structure to parse the commands to something approaching a sum type (fixes #507) - this is mostly prep for reworking the commands set (#673), although *strict command parsing* has been implemented (cf update to `test_unknown_commands`)
2023-10-16 15:46:29 +07:00
(users['user'], "@{reviewer} retry makes no sense when the PR is not in error.".format_map(users)),
[ADD] runbot_merge: various feedback messages Send reponse comments when users mis-interact with robodoo e.g. send comments they don't have the right to, or commands which don't make sense in the PR's state, or tentative interactions with robodoo from unmanaged PRs.
2018-10-16 17:40:45 +07:00
]
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
@pytest.mark.defaultstatuses
[IMP] allow delegate reviewers to retry and r-
2018-03-26 22:29:49 +07:00
@pytest.mark.parametrize('disabler', ['user', 'other', 'reviewer'])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_retry_disable(self, env, repo, disabler, users, config):
with repo:
prx = _simple_init(repo)
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
repo.post_status(prx.head, 'success')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx.post_comment('hansen r+ delegate=%s rebase-merge' % users['other'],
config["role_reviewer"]['token'])
env.run_crons()
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
pr_id = to_pr(env, prx)
staging_id = pr_id.staging_id
assert staging_id
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
repo.post_status('staging.master', 'failure')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
assert staging_id.state == 'failure'
assert not staging_id.active
assert pr_id.state == 'error'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r-', config['role_' + disabler]['token'])
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
assert pr_id.state == 'validated'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.make_commit(prx.ref, 'third', None, tree={'m': 'c3'})
# just in case, apparently in some case the first post_status uses the old head...
with repo:
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
repo.post_status(prx.head, 'success')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
assert pr_id.state == 'validated'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
class TestMergeMethod:
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
"""
[REM] runbot_merge: support for squash+/squash- AL thinks it's not useful and it's better to always squash/rebase a single commit & merge multiple. Mark tests as xfail'd instead of removing them. Also mark test_edit_retarget_managed as skipped explicitly
2018-06-01 16:59:18 +07:00
if event['pull_request']['commits'] == 1, "squash" (/rebase); otherwise
regular merge
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_pr_single_commit(self, repo, env, config):
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
""" If single commit, default to rebase & FF
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
m2 = repo.make_commit(m, 'second', None, tree={'m': 'm', 'm2': 'm2'})
repo.make_ref('heads/master', m2)
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
prx = repo.make_pr(title='title', body='body', target='master', head=c1)
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen r+', config['role_reviewer']['token'])
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
assert to_pr(env, prx).squash
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
assert to_pr(env, prx).staging_id
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
staging = repo.commit('heads/staging.master')
[IMP] runbot_merge: pluginify github mock This is the preparation of an attempt to make these tests work with both a local github mock (in-memory) and a remote actual github. Move a bunch of fixtures relying on the specific github implementation (and odoo-as-library access) to the "local" plugin, including splitting the "repo" fixture. The specific fixtures will likely have to be adjusted as the remote endpoint is fleshed out.
2018-06-05 15:10:32 +07:00
assert not repo.is_ancestor(prx.head, of=staging.id),\
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
"the pr head should not be an ancestor of the staging branch in a squash merge"
[IMP] runbot_merge: pluginify github mock This is the preparation of an attempt to make these tests work with both a local github mock (in-memory) and a remote actual github. Move a bunch of fixtures relying on the specific github implementation (and odoo-as-library access) to the "local" plugin, including splitting the "repo" fixture. The specific fixtures will likely have to be adjusted as the remote endpoint is fleshed out.
2018-06-05 15:10:32 +07:00
assert repo.read_tree(staging) == {
[ADD] forwardbot * Cherrypicking is handrolled because there seems to be no easy way to programmatically edit commit messages during the cherrypicking sequence: `-n` basically squashes all commits and `-e` invokes a subprocess. `-e` with `VISUAL=false` kinda sorta works (in that it interrupts the process before each commit), however there doesn't seem to be clean status codes so it's difficult to know if the cherrypick failed or if it's just waiting for a commit of this step. Instead, cherrypick commits individually then edit / rewrite their commit messages: * add a reference to the original commit * convert signed-off-by to something else as the original commit was signed off but not necessarily this one * Can't assign users when creating PRs: only repository collaborators or people who commented on the issue / PR (which we're in the process of creating) can be assigned. PR authors are as likely to be collaborators as not, and we can have non-collaborator reviewers. So pinging via a regular comment seems less fraught as a way to notify users.
2019-08-23 21:16:30 +07:00
'm': 'c1', 'm2': 'm2',
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
}, "the tree should still be correctly merged"
[IMP] runbot_merge: remove unnecessary uniquifier dummy commits "Uniquifier" commits were introduced to ensure branches of a staging on which nothing had been staged would still be rebuilt properly. This means technically the branches on which something had been staged never *needed* a uniquifier, strictly speaking. And those lead to extra building, because once the actually staged PRs get pushed from staging to their final destination it's an unknown commit to the runbot, which needs to rebuild it instead of being able to just use the staging it already has. Thus only add the uniquifier where it *might* be necessary: technically the runbot should not manage this use case much better, however there are still issues like an ancillary build working with the same branch tip (e.g. the "current master") and sending a failure result which would fail the entire staging. The uniquifier guards against this issue. Also update rebase semantics to always update the *commit date* of the rebased commits: this ensures the tip commit is always "recent" in the case of a rebase-ff (which is common as that's what single-commit PRs do), as the runbot may skip commits it considers "old". Also update some of the utility methods around repos / commits to be simpler, and avoid assuming the result is JSON-decodable (sometimes it is not). Also update the handling of commit statuses using postgres' ON CONFLICT and jsonb support, hopefully this improves (or even fixes) the serialization errors. Should be compatible with 9.5 onwards which is *ancient* at this point. Fixes #509
2021-08-09 18:21:24 +07:00
assert staging.parents == [m2],\
[FIX] runbot_merge: ensure all staging branches are built/tested Before this change, when staging batches only affecting one repo (of n) the unaffected repositories would get a staging branch exactly matching the target. As a result, either runbot_merge or runbot would simply return the result of an unrelated build, potentially providing incorrect information and either failing a staging which should have succeeded (e.g. change in repo A broke B, PR is making a change in repo A which fixes B, but B's state is reported as the previous broken build) or succeeding a staging which should have failed (change in repo A breaking B except a previous build of the exact same B succeeded with a different A and is returned). To fix this issue, create a dummy commit at the head of each staging branch. Because commit dates are included in the hash and have a second precision it's pretty unlikely that we can get built duplicates, but just to be completely sure some random bits are added to the commit message as well. Various tests fixed to correctly handle the extra dummy commit on staging branches. fixes #35
2018-09-10 21:00:26 +07:00
"dummy commit aside, the previous master's tip should be the sole parent of the staging commit"
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
repo.post_status('staging.master', 'success', 'legal/cla')
repo.post_status('staging.master', 'success', 'ci/runbot')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[IMP] runbot_merge: map PR commits to integrated commits * when rebasing, store a map of rebased to source, that way it'll be possible to link cherry-picked forward ports to the originally integrated commit rather than just the one from the PR (which was likely not itself integrated as the straight merge mode is somewhat rare: as of 5600 PRs merged so far only 100 were straight merged) * while at it, store the "merge head" of the PR (whether squashed, merged or rebased) and put *that* in the commit message fixes #161
2019-07-31 14:19:39 +07:00
assert pr.state == 'merged'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert prx.state == 'closed'
[IMP] runbot_merge: map PR commits to integrated commits * when rebasing, store a map of rebased to source, that way it'll be possible to link cherry-picked forward ports to the originally integrated commit rather than just the one from the PR (which was likely not itself integrated as the straight merge mode is somewhat rare: as of 5600 PRs merged so far only 100 were straight merged) * while at it, store the "merge head" of the PR (whether squashed, merged or rebased) and put *that* in the commit message fixes #161
2019-07-31 14:19:39 +07:00
assert json.loads(pr.commits_map) == {
[IMP] runbot_merge: remove unnecessary uniquifier dummy commits "Uniquifier" commits were introduced to ensure branches of a staging on which nothing had been staged would still be rebuilt properly. This means technically the branches on which something had been staged never *needed* a uniquifier, strictly speaking. And those lead to extra building, because once the actually staged PRs get pushed from staging to their final destination it's an unknown commit to the runbot, which needs to rebuild it instead of being able to just use the staging it already has. Thus only add the uniquifier where it *might* be necessary: technically the runbot should not manage this use case much better, however there are still issues like an ancillary build working with the same branch tip (e.g. the "current master") and sending a failure result which would fail the entire staging. The uniquifier guards against this issue. Also update rebase semantics to always update the *commit date* of the rebased commits: this ensures the tip commit is always "recent" in the case of a rebase-ff (which is common as that's what single-commit PRs do), as the runbot may skip commits it considers "old". Also update some of the utility methods around repos / commits to be simpler, and avoid assuming the result is JSON-decodable (sometimes it is not). Also update the handling of commit statuses using postgres' ON CONFLICT and jsonb support, hopefully this improves (or even fixes) the serialization errors. Should be compatible with 9.5 onwards which is *ancient* at this point. Fixes #509
2021-08-09 18:21:24 +07:00
c1: staging.id,
'': staging.id,
[IMP] runbot_merge: map PR commits to integrated commits * when rebasing, store a map of rebased to source, that way it'll be possible to link cherry-picked forward ports to the originally integrated commit rather than just the one from the PR (which was likely not itself integrated as the straight merge mode is somewhat rare: as of 5600 PRs merged so far only 100 were straight merged) * while at it, store the "merge head" of the PR (whether squashed, merged or rebased) and put *that* in the commit message fixes #161
2019-07-31 14:19:39 +07:00
}, "for a squash, the one PR commit should be mapped to the one rebased commit"
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[CHG] allow delegate reviewers to configure the merge method After internal discussions it was concluded that this didn't extend much more trust than allowing authors to accept their single-PR commits without additional supervisions, and it would avoid some inconveniences and PR-blocking. Fixes #69 (nice)
2021-10-05 20:05:17 +07:00
def test_delegate_method(self, repo, env, users, config):
"""Delegates should be able to configure the merge method.
"""
with repo:
m, _ = repo.make_commits(
None,
Commit('initial', tree={'m': 'm'}),
Commit('second', tree={'m2': 'm2'}),
ref="heads/master"
)
[c1] = repo.make_commits(m, Commit('first', tree={'m': 'c1'}))
pr = repo.make_pr(target='master', head=c1)
repo.post_status(pr.head, 'success', 'legal/cla')
repo.post_status(pr.head, 'success', 'ci/runbot')
pr.post_comment('hansen delegate+', config['role_reviewer']['token'])
pr.post_comment('hansen merge', config['role_user']['token'])
env.run_crons()
assert pr.user == users['user']
assert to_pr(env, pr).merge_method == 'merge'
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
def test_pr_update_to_many_commits(self, repo, env):
[ADD] runbot_merge: update squash flags when PR commits are updated If the PR's commits count changes, the squash state should be updated to match/reflect.
2018-06-01 17:33:31 +07:00
"""
If a PR starts with 1 commit and a second commit is added, the PR
should be unflagged as squash
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
m2 = repo.make_commit(m, 'second', None, tree={'m': 'm', 'm2': 'm2'})
repo.make_ref('heads/master', m2)
[ADD] runbot_merge: update squash flags when PR commits are updated If the PR's commits count changes, the squash state should be updated to match/reflect.
2018-06-01 17:33:31 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
prx = repo.make_pr(title='title', body='body', target='master', head=c1)
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[ADD] runbot_merge: update squash flags when PR commits are updated If the PR's commits count changes, the squash state should be updated to match/reflect.
2018-06-01 17:33:31 +07:00
assert pr.squash, "a PR with a single commit should be squashed"
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.make_commit(prx.ref, 'second2', None, tree={'m': 'c2'})
[ADD] runbot_merge: update squash flags when PR commits are updated If the PR's commits count changes, the squash state should be updated to match/reflect.
2018-06-01 17:33:31 +07:00
assert not pr.squash, "a PR with a single commit should not be squashed"
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
def test_pr_reset_to_single_commit(self, repo, env):
[ADD] runbot_merge: update squash flags when PR commits are updated If the PR's commits count changes, the squash state should be updated to match/reflect.
2018-06-01 17:33:31 +07:00
"""
If a PR starts at >1 commits and is reset back to 1, the PR should be
re-flagged as squash
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
m2 = repo.make_commit(m, 'second', None, tree={'m': 'm', 'm2': 'm2'})
repo.make_ref('heads/master', m2)
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
c2 = repo.make_commit(c1, 'second2', None, tree={'m': 'c2'})
prx = repo.make_pr(title='title', body='body', target='master', head=c2)
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[IMP] runbot_merge: drop merge method on squash When moving from !squash to squash to !squash, it's a bit odd / risky to keep the merge method as-is. So drop it.
2020-05-28 18:27:34 +07:00
pr.merge_method = 'rebase-merge'
[ADD] runbot_merge: update squash flags when PR commits are updated If the PR's commits count changes, the squash state should be updated to match/reflect.
2018-06-01 17:33:31 +07:00
assert not pr.squash, "a PR with a single commit should not be squashed"
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.update_ref(
prx.ref,
repo.make_commit(m, 'fixup', None, tree={'m': 'c2'}),
force=True
)
[ADD] runbot_merge: update squash flags when PR commits are updated If the PR's commits count changes, the squash state should be updated to match/reflect.
2018-06-01 17:33:31 +07:00
assert pr.squash, "a PR with a single commit should be squashed"
[IMP] runbot_merge: drop merge method on squash When moving from !squash to squash to !squash, it's a bit odd / risky to keep the merge method as-is. So drop it.
2020-05-28 18:27:34 +07:00
assert not pr.merge_method, \
"resetting a PR to a single commit should remove the merge method"
[ADD] runbot_merge: update squash flags when PR commits are updated If the PR's commits count changes, the squash state should be updated to match/reflect.
2018-06-01 17:33:31 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_pr_no_method(self, repo, env, users, config):
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
""" a multi-repo PR should not be staged by default, should also get
feedback indicating a merge method is necessary
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[CHG] allow delegate reviewers to configure the merge method After internal discussions it was concluded that this didn't extend much more trust than allowing authors to accept their single-PR commits without additional supervisions, and it would avoid some inconveniences and PR-blocking. Fixes #69 (nice)
2021-10-05 20:05:17 +07:00
_, m1, _ = repo.make_commits(
None,
Commit('M0', tree={'m': '0'}),
Commit('M1', tree={'m': '1'}),
Commit('M2', tree={'m': '2'}),
ref='heads/master'
)
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
[CHG] allow delegate reviewers to configure the merge method After internal discussions it was concluded that this didn't extend much more trust than allowing authors to accept their single-PR commits without additional supervisions, and it would avoid some inconveniences and PR-blocking. Fixes #69 (nice)
2021-10-05 20:05:17 +07:00
_, b1 = repo.make_commits(
m1,
Commit('B0', tree={'b': '0'}),
Commit('B1', tree={'b': '1'}),
)
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx = repo.make_pr(title='title', body='body', target='master', head=b1)
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
[CHG] allow delegate reviewers to configure the merge method After internal discussions it was concluded that this didn't extend much more trust than allowing authors to accept their single-PR commits without additional supervisions, and it would avoid some inconveniences and PR-blocking. Fixes #69 (nice)
2021-10-05 20:05:17 +07:00
assert not to_pr(env, prx).staging_id
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
assert prx.comments == [
(users['reviewer'], 'hansen r+'),
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
seen(env, prx, users),
[IMP] *: review mergebot & forwardbot messages for pinging Old messages were quite inconsistent in their pinging of the PR author and reviewer. Reviewed messages (probably missed some but...) and try to more consistently ping when the feedback requires some sort of action in order to proceed. Fixes #592
2022-06-23 19:25:07 +07:00
(users['user'], """@{user} @{reviewer} because this PR has multiple \
commits, I need to know how to merge it:
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
* `merge` to merge directly, using the PR as merge commit message
* `rebase-merge` to rebase and merge, using the PR as merge commit message
* `rebase-ff` to rebase and fast-forward
[IMP] *: review mergebot & forwardbot messages for pinging Old messages were quite inconsistent in their pinging of the PR author and reviewer. Reviewed messages (probably missed some but...) and try to more consistently ping when the feedback requires some sort of action in order to proceed. Fixes #592
2022-06-23 19:25:07 +07:00
""".format_map(users)),
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
]
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_pr_method_no_review(self, repo, env, users, config):
[CHG] allow delegate reviewers to configure the merge method After internal discussions it was concluded that this didn't extend much more trust than allowing authors to accept their single-PR commits without additional supervisions, and it would avoid some inconveniences and PR-blocking. Fixes #69 (nice)
2021-10-05 20:05:17 +07:00
""" Configuring the method should be independent from the review
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m0 = repo.make_commit(None, 'M0', None, tree={'m': '0'})
m1 = repo.make_commit(m0, 'M1', None, tree={'m': '1'})
m2 = repo.make_commit(m1, 'M2', None, tree={'m': '2'})
repo.make_ref('heads/master', m2)
b0 = repo.make_commit(m1, 'B0', None, tree={'m': '1', 'b': '0'})
b1 = repo.make_commit(b0, 'B1', None, tree={'m': '1', 'b': '1'})
prx = repo.make_pr(title='title', body='body', target='master', head=b1)
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx.post_comment('hansen rebase-merge', config['role_reviewer']['token'])
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
assert pr.merge_method == 'rebase-merge'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen merge', config['role_reviewer']['token'])
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
assert pr.merge_method == 'merge'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen rebase-ff', config['role_reviewer']['token'])
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
assert pr.merge_method == 'rebase-ff'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] runbot_merge: send feedback when merge method is changed When a user changes the merge method via github messages, no feedback is sent. This could lead to strange behavior, for example when a user try to joke with the mergebot like this: > robodoo are you goin ti merge my PR rogntudju ! This sets the merge method to "merge" and the user is not aware of it.
2018-12-13 19:28:20 +07:00
assert prx.comments == [
(users['reviewer'], 'hansen rebase-merge'),
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
seen(env, prx, users),
[IMP] *: review mergebot & forwardbot messages for pinging Old messages were quite inconsistent in their pinging of the PR author and reviewer. Reviewed messages (probably missed some but...) and try to more consistently ping when the feedback requires some sort of action in order to proceed. Fixes #592
2022-06-23 19:25:07 +07:00
(users['user'], "Merge method set to rebase and merge, using the PR as merge commit message."),
[IMP] runbot_merge: send feedback when merge method is changed When a user changes the merge method via github messages, no feedback is sent. This could lead to strange behavior, for example when a user try to joke with the mergebot like this: > robodoo are you goin ti merge my PR rogntudju ! This sets the merge method to "merge" and the user is not aware of it.
2018-12-13 19:28:20 +07:00
(users['reviewer'], 'hansen merge'),
[IMP] *: review mergebot & forwardbot messages for pinging Old messages were quite inconsistent in their pinging of the PR author and reviewer. Reviewed messages (probably missed some but...) and try to more consistently ping when the feedback requires some sort of action in order to proceed. Fixes #592
2022-06-23 19:25:07 +07:00
(users['user'], "Merge method set to merge directly, using the PR as merge commit message."),
[IMP] runbot_merge: send feedback when merge method is changed When a user changes the merge method via github messages, no feedback is sent. This could lead to strange behavior, for example when a user try to joke with the mergebot like this: > robodoo are you goin ti merge my PR rogntudju ! This sets the merge method to "merge" and the user is not aware of it.
2018-12-13 19:28:20 +07:00
(users['reviewer'], 'hansen rebase-ff'),
[IMP] *: review mergebot & forwardbot messages for pinging Old messages were quite inconsistent in their pinging of the PR author and reviewer. Reviewed messages (probably missed some but...) and try to more consistently ping when the feedback requires some sort of action in order to proceed. Fixes #592
2022-06-23 19:25:07 +07:00
(users['user'], "Merge method set to rebase and fast-forward."),
[IMP] runbot_merge: send feedback when merge method is changed When a user changes the merge method via github messages, no feedback is sent. This could lead to strange behavior, for example when a user try to joke with the mergebot like this: > robodoo are you goin ti merge my PR rogntudju ! This sets the merge method to "merge" and the user is not aware of it.
2018-12-13 19:28:20 +07:00
]
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_pr_rebase_merge(self, repo, env, users, config):
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
""" test result on rebase-merge
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
left: PR
right: post-merge result
+------+ +------+
| M0 | | M0 |
+--^---+ +--^---+
| |
| |
+--+---+ +--+---+
+----> M1 <--+ | M1 <--+
| +------+ | +------+ |
| | |
| | |
+--+---+ +---+---+ +------+ +---+---+
| B0 | | M2 | | B0 +------> M2 |
+--^---+ +-------+ +--^---+ +---^---+
| | |
+--+---+ +--+---+ |
PR | B1 | | B1 | |
+------+ +--^---+ |
| +---+---+
+----------+ merge |
+-------+
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m0 = repo.make_commit(None, 'M0', None, tree={'m': '0'})
m1 = repo.make_commit(m0, 'M1', None, tree={'m': '1'})
m2 = repo.make_commit(m1, 'M2', None, tree={'m': '2'})
repo.make_ref('heads/master', m2)
# test commit ordering issue while at it: github sorts commits on
# author.date instead of doing so topologically which is absolutely
# not what we want
committer = {'name': 'a', 'email': 'a', 'date': '2018-10-08T11:48:43Z'}
author0 = {'name': 'a', 'email': 'a', 'date': '2018-10-01T14:58:38Z'}
author1 = {'name': 'a', 'email': 'a', 'date': '2015-10-01T14:58:38Z'}
b0 = repo.make_commit(m1, 'B0', author=author0, committer=committer, tree={'m': '1', 'b': '0'})
b1 = repo.make_commit(b0, 'B1', author=author1, committer=committer, tree={'m': '1', 'b': '1'})
prx = repo.make_pr(title='title', body='body', target='master', head=b1)
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen r+ rebase-merge', config['role_reviewer']['token'])
env.run_crons()
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
pr_id = to_pr(env, prx)
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
# create a dag (msg:str, parents:set) from the log
staging = log_to_node(repo.log('heads/staging.master'))
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
# then compare to the dag version of the right graph
nm2 = node('M2', node('M1', node('M0')))
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
nb1 = node(part_of('B1', pr_id), node(part_of('B0', pr_id), nm2))
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
reviewer = get_partner(env, users["reviewer"]).formatted_email
[FIX] runbot_merge: ensure all staging branches are built/tested Before this change, when staging batches only affecting one repo (of n) the unaffected repositories would get a staging branch exactly matching the target. As a result, either runbot_merge or runbot would simply return the result of an unrelated build, potentially providing incorrect information and either failing a staging which should have succeeded (e.g. change in repo A broke B, PR is making a change in repo A which fixes B, but B's state is reported as the previous broken build) or succeeding a staging which should have failed (change in repo A breaking B except a previous build of the exact same B succeeded with a different A and is returned). To fix this issue, create a dummy commit at the head of each staging branch. Because commit dates are included in the hash and have a second precision it's pretty unlikely that we can get built duplicates, but just to be completely sure some random bits are added to the commit message as well. Various tests fixed to correctly handle the extra dummy commit on staging branches. fixes #35
2018-09-10 21:00:26 +07:00
merge_head = (
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
f'title\n\nbody\n\ncloses {pr_id.display_name}\n\nSigned-off-by: {reviewer}',
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
frozenset([nm2, nb1])
)
[IMP] runbot_merge: remove unnecessary uniquifier dummy commits "Uniquifier" commits were introduced to ensure branches of a staging on which nothing had been staged would still be rebuilt properly. This means technically the branches on which something had been staged never *needed* a uniquifier, strictly speaking. And those lead to extra building, because once the actually staged PRs get pushed from staging to their final destination it's an unknown commit to the runbot, which needs to rebuild it instead of being able to just use the staging it already has. Thus only add the uniquifier where it *might* be necessary: technically the runbot should not manage this use case much better, however there are still issues like an ancillary build working with the same branch tip (e.g. the "current master") and sending a failure result which would fail the entire staging. The uniquifier guards against this issue. Also update rebase semantics to always update the *commit date* of the rebased commits: this ensures the tip commit is always "recent" in the case of a rebase-ff (which is common as that's what single-commit PRs do), as the runbot may skip commits it considers "old". Also update some of the utility methods around repos / commits to be simpler, and avoid assuming the result is JSON-decodable (sometimes it is not). Also update the handling of commit statuses using postgres' ON CONFLICT and jsonb support, hopefully this improves (or even fixes) the serialization errors. Should be compatible with 9.5 onwards which is *ancient* at this point. Fixes #509
2021-08-09 18:21:24 +07:00
assert staging == merge_head
[FIX] runbot_merge: unstage on staging-relevant PR modifications Stagings would be cancelled automatically if the PR's commits were updated, but not if the target (base) was changed, even though that has a drastic impact on staging. Add hooks to unstage PRs if their base is updated, or if their message is updated and relevant to staging (merge or rebase-merge methods). Fixes #604
2022-06-09 13:55:34 +07:00
st = pr_id.staging_id
assert st
with repo: prx.title = 'title 2'
assert not pr_id.staging_id, "updating the message of a merge-staged PR should unstage rien"
assert st.reason == f'{pr_id.display_name} merge message updated'
# since we updated the description, the merge_head value is impacted,
# and it's checked again later on
merge_head = (
merge_head[0].replace('title', 'title 2'),
merge_head[1],
)
env.run_crons()
assert pr_id.staging_id, "PR should immediately be re-stageable"
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status('heads/staging.master', 'success', 'legal/cla')
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
env.run_crons()
[FIX] runbot_merge: ensure all staging branches are built/tested Before this change, when staging batches only affecting one repo (of n) the unaffected repositories would get a staging branch exactly matching the target. As a result, either runbot_merge or runbot would simply return the result of an unrelated build, potentially providing incorrect information and either failing a staging which should have succeeded (e.g. change in repo A broke B, PR is making a change in repo A which fixes B, but B's state is reported as the previous broken build) or succeeding a staging which should have failed (change in repo A breaking B except a previous build of the exact same B succeeded with a different A and is returned). To fix this issue, create a dummy commit at the head of each staging branch. Because commit dates are included in the hash and have a second precision it's pretty unlikely that we can get built duplicates, but just to be completely sure some random bits are added to the commit message as well. Various tests fixed to correctly handle the extra dummy commit on staging branches. fixes #35
2018-09-10 21:00:26 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[IMP] runbot_merge: map PR commits to integrated commits * when rebasing, store a map of rebased to source, that way it'll be possible to link cherry-picked forward ports to the originally integrated commit rather than just the one from the PR (which was likely not itself integrated as the straight merge mode is somewhat rare: as of 5600 PRs merged so far only 100 were straight merged) * while at it, store the "merge head" of the PR (whether squashed, merged or rebased) and put *that* in the commit message fixes #161
2019-07-31 14:19:39 +07:00
assert pr.state == 'merged'
[FIX] runbot_merge: ensure all staging branches are built/tested Before this change, when staging batches only affecting one repo (of n) the unaffected repositories would get a staging branch exactly matching the target. As a result, either runbot_merge or runbot would simply return the result of an unrelated build, potentially providing incorrect information and either failing a staging which should have succeeded (e.g. change in repo A broke B, PR is making a change in repo A which fixes B, but B's state is reported as the previous broken build) or succeeding a staging which should have failed (change in repo A breaking B except a previous build of the exact same B succeeded with a different A and is returned). To fix this issue, create a dummy commit at the head of each staging branch. Because commit dates are included in the hash and have a second precision it's pretty unlikely that we can get built duplicates, but just to be completely sure some random bits are added to the commit message as well. Various tests fixed to correctly handle the extra dummy commit on staging branches. fixes #35
2018-09-10 21:00:26 +07:00
# check that the dummy commit is not in the final master
master = log_to_node(repo.log('heads/master'))
assert master == merge_head
[IMP] runbot_merge: map PR commits to integrated commits * when rebasing, store a map of rebased to source, that way it'll be possible to link cherry-picked forward ports to the originally integrated commit rather than just the one from the PR (which was likely not itself integrated as the straight merge mode is somewhat rare: as of 5600 PRs merged so far only 100 were straight merged) * while at it, store the "merge head" of the PR (whether squashed, merged or rebased) and put *that* in the commit message fixes #161
2019-07-31 14:19:39 +07:00
head = repo.commit('heads/master')
final_tree = repo.read_tree(head)
[ADD] forwardbot * Cherrypicking is handrolled because there seems to be no easy way to programmatically edit commit messages during the cherrypicking sequence: `-n` basically squashes all commits and `-e` invokes a subprocess. `-e` with `VISUAL=false` kinda sorta works (in that it interrupts the process before each commit), however there doesn't seem to be clean status codes so it's difficult to know if the cherrypick failed or if it's just waiting for a commit of this step. Instead, cherrypick commits individually then edit / rewrite their commit messages: * add a reference to the original commit * convert signed-off-by to something else as the original commit was signed off but not necessarily this one * Can't assign users when creating PRs: only repository collaborators or people who commented on the issue / PR (which we're in the process of creating) can be assigned. PR authors are as likely to be collaborators as not, and we can have non-collaborator reviewers. So pinging via a regular comment seems less fraught as a way to notify users.
2019-08-23 21:16:30 +07:00
assert final_tree == {'m': '2', 'b': '1'}, "sanity check of final tree"
[IMP] runbot_merge: map PR commits to integrated commits * when rebasing, store a map of rebased to source, that way it'll be possible to link cherry-picked forward ports to the originally integrated commit rather than just the one from the PR (which was likely not itself integrated as the straight merge mode is somewhat rare: as of 5600 PRs merged so far only 100 were straight merged) * while at it, store the "merge head" of the PR (whether squashed, merged or rebased) and put *that* in the commit message fixes #161
2019-07-31 14:19:39 +07:00
r1 = repo.commit(head.parents[1])
r0 = repo.commit(r1.parents[0])
assert json.loads(pr.commits_map) == {
b0: r0.id,
b1: r1.id,
'': head.id,
}
assert r0.parents == [m2]
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_pr_rebase_ff(self, repo, env, users, config):
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
""" test result on rebase-merge
left: PR
right: post-merge result
+------+ +------+
| M0 | | M0 |
+--^---+ +--^---+
| |
| |
+--+---+ +--+---+
+----> M1 <--+ | M1 <--+
| +------+ | +------+ |
| | |
| | |
+--+---+ +---+---+ +------+ +---+---+
| B0 | | M2 | | B0 +------> M2 |
+--^---+ +-------+ +--^---+ +---^---+
| |
+--+---+ +--+---+
PR | B1 | | B1 |
+------+ +--^---+
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] runbot_merge: remove unnecessary uniquifier dummy commits "Uniquifier" commits were introduced to ensure branches of a staging on which nothing had been staged would still be rebuilt properly. This means technically the branches on which something had been staged never *needed* a uniquifier, strictly speaking. And those lead to extra building, because once the actually staged PRs get pushed from staging to their final destination it's an unknown commit to the runbot, which needs to rebuild it instead of being able to just use the staging it already has. Thus only add the uniquifier where it *might* be necessary: technically the runbot should not manage this use case much better, however there are still issues like an ancillary build working with the same branch tip (e.g. the "current master") and sending a failure result which would fail the entire staging. The uniquifier guards against this issue. Also update rebase semantics to always update the *commit date* of the rebased commits: this ensures the tip commit is always "recent" in the case of a rebase-ff (which is common as that's what single-commit PRs do), as the runbot may skip commits it considers "old". Also update some of the utility methods around repos / commits to be simpler, and avoid assuming the result is JSON-decodable (sometimes it is not). Also update the handling of commit statuses using postgres' ON CONFLICT and jsonb support, hopefully this improves (or even fixes) the serialization errors. Should be compatible with 9.5 onwards which is *ancient* at this point. Fixes #509
2021-08-09 18:21:24 +07:00
_, m1, m2 = repo.make_commits(
None,
Commit('M0', tree={'m': '0'}),
Commit('M1', tree={'m': '1'}),
Commit('M2', tree={'m': '2'}),
ref='heads/master'
)
b0, b1 = repo.make_commits(
m1,
Commit('B0', tree={'b': '0'}, author={'name': 'Maarten Tromp', 'email': 'm.tromp@example.nl', 'date': '1651-03-30T12:00:00Z'}),
Commit('B1', tree={'b': '1'}, author={'name': 'Rein Huydecoper', 'email': 'r.huydecoper@example.nl', 'date': '1986-04-17T12:00:00Z'}),
)
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx = repo.make_pr(title='title', body='body', target='master', head=b1)
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen r+ rebase-ff', config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
pr_id = to_pr(env, prx)
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
# create a dag (msg:str, parents:set) from the log
staging = log_to_node(repo.log('heads/staging.master'))
# then compare to the dag version of the right graph
nm2 = node('M2', node('M1', node('M0')))
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
reviewer = get_partner(env, users["reviewer"]).formatted_email
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
nb1 = node(f'B1\n\ncloses {pr_id.display_name}\n\nSigned-off-by: {reviewer}',
node(part_of('B0', pr_id), nm2))
[IMP] runbot_merge: remove unnecessary uniquifier dummy commits "Uniquifier" commits were introduced to ensure branches of a staging on which nothing had been staged would still be rebuilt properly. This means technically the branches on which something had been staged never *needed* a uniquifier, strictly speaking. And those lead to extra building, because once the actually staged PRs get pushed from staging to their final destination it's an unknown commit to the runbot, which needs to rebuild it instead of being able to just use the staging it already has. Thus only add the uniquifier where it *might* be necessary: technically the runbot should not manage this use case much better, however there are still issues like an ancillary build working with the same branch tip (e.g. the "current master") and sending a failure result which would fail the entire staging. The uniquifier guards against this issue. Also update rebase semantics to always update the *commit date* of the rebased commits: this ensures the tip commit is always "recent" in the case of a rebase-ff (which is common as that's what single-commit PRs do), as the runbot may skip commits it considers "old". Also update some of the utility methods around repos / commits to be simpler, and avoid assuming the result is JSON-decodable (sometimes it is not). Also update the handling of commit statuses using postgres' ON CONFLICT and jsonb support, hopefully this improves (or even fixes) the serialization errors. Should be compatible with 9.5 onwards which is *ancient* at this point. Fixes #509
2021-08-09 18:21:24 +07:00
assert staging == nb1
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status('heads/staging.master', 'success', 'legal/cla')
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
env.run_crons()
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[IMP] runbot_merge: map PR commits to integrated commits * when rebasing, store a map of rebased to source, that way it'll be possible to link cherry-picked forward ports to the originally integrated commit rather than just the one from the PR (which was likely not itself integrated as the straight merge mode is somewhat rare: as of 5600 PRs merged so far only 100 were straight merged) * while at it, store the "merge head" of the PR (whether squashed, merged or rebased) and put *that* in the commit message fixes #161
2019-07-31 14:19:39 +07:00
assert pr.state == 'merged'
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
# check that the dummy commit is not in the final master
master = log_to_node(repo.log('heads/master'))
assert master == nb1
[IMP] runbot_merge: map PR commits to integrated commits * when rebasing, store a map of rebased to source, that way it'll be possible to link cherry-picked forward ports to the originally integrated commit rather than just the one from the PR (which was likely not itself integrated as the straight merge mode is somewhat rare: as of 5600 PRs merged so far only 100 were straight merged) * while at it, store the "merge head" of the PR (whether squashed, merged or rebased) and put *that* in the commit message fixes #161
2019-07-31 14:19:39 +07:00
head = repo.commit('heads/master')
final_tree = repo.read_tree(head)
[ADD] forwardbot * Cherrypicking is handrolled because there seems to be no easy way to programmatically edit commit messages during the cherrypicking sequence: `-n` basically squashes all commits and `-e` invokes a subprocess. `-e` with `VISUAL=false` kinda sorta works (in that it interrupts the process before each commit), however there doesn't seem to be clean status codes so it's difficult to know if the cherrypick failed or if it's just waiting for a commit of this step. Instead, cherrypick commits individually then edit / rewrite their commit messages: * add a reference to the original commit * convert signed-off-by to something else as the original commit was signed off but not necessarily this one * Can't assign users when creating PRs: only repository collaborators or people who commented on the issue / PR (which we're in the process of creating) can be assigned. PR authors are as likely to be collaborators as not, and we can have non-collaborator reviewers. So pinging via a regular comment seems less fraught as a way to notify users.
2019-08-23 21:16:30 +07:00
assert final_tree == {'m': '2', 'b': '1'}, "sanity check of final tree"
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
[IMP] runbot_merge: map PR commits to integrated commits * when rebasing, store a map of rebased to source, that way it'll be possible to link cherry-picked forward ports to the originally integrated commit rather than just the one from the PR (which was likely not itself integrated as the straight merge mode is somewhat rare: as of 5600 PRs merged so far only 100 were straight merged) * while at it, store the "merge head" of the PR (whether squashed, merged or rebased) and put *that* in the commit message fixes #161
2019-07-31 14:19:39 +07:00
m1 = head
m0 = repo.commit(m1.parents[0])
assert json.loads(pr.commits_map) == {
'': m1.id, # merge commit
b1: m1.id, # second PR's commit
b0: m0.id, # first PR's commit
}
assert m0.parents == [m2], "can't hurt to check the parent of our root commit"
[IMP] runbot_merge: remove unnecessary uniquifier dummy commits "Uniquifier" commits were introduced to ensure branches of a staging on which nothing had been staged would still be rebuilt properly. This means technically the branches on which something had been staged never *needed* a uniquifier, strictly speaking. And those lead to extra building, because once the actually staged PRs get pushed from staging to their final destination it's an unknown commit to the runbot, which needs to rebuild it instead of being able to just use the staging it already has. Thus only add the uniquifier where it *might* be necessary: technically the runbot should not manage this use case much better, however there are still issues like an ancillary build working with the same branch tip (e.g. the "current master") and sending a failure result which would fail the entire staging. The uniquifier guards against this issue. Also update rebase semantics to always update the *commit date* of the rebased commits: this ensures the tip commit is always "recent" in the case of a rebase-ff (which is common as that's what single-commit PRs do), as the runbot may skip commits it considers "old". Also update some of the utility methods around repos / commits to be simpler, and avoid assuming the result is JSON-decodable (sometimes it is not). Also update the handling of commit statuses using postgres' ON CONFLICT and jsonb support, hopefully this improves (or even fixes) the serialization errors. Should be compatible with 9.5 onwards which is *ancient* at this point. Fixes #509
2021-08-09 18:21:24 +07:00
assert m0.author['date'] != m0.committer['date'], "commit date should have been rewritten"
assert m1.author['date'] != m1.committer['date'], "commit date should have been rewritten"
utcday = datetime.datetime.utcnow().date()
def parse(dt):
return datetime.datetime.strptime(dt, "%Y-%m-%dT%H:%M:%SZ")
# FIXME: actual commit creation could run before the date rollover and
# local datetime.utcnow() after
assert parse(m0.committer['date']).date() == utcday
# FIXME: git date storage is unreliable and non-portable outside of an
# unsigned 31b epoch range so the m0 event may get flung in the
# future (compared to the literal datum), this test unexpectedly
# becoming true if run on the exact wrong day
assert parse(m0.author['date']).date() != utcday
assert parse(m1.committer['date']).date() == utcday
assert parse(m0.author['date']).date() != utcday
[IMP] runbot_merge: map PR commits to integrated commits * when rebasing, store a map of rebased to source, that way it'll be possible to link cherry-picked forward ports to the originally integrated commit rather than just the one from the PR (which was likely not itself integrated as the straight merge mode is somewhat rare: as of 5600 PRs merged so far only 100 were straight merged) * while at it, store the "merge head" of the PR (whether squashed, merged or rebased) and put *that* in the commit message fixes #161
2019-07-31 14:19:39 +07:00
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
@pytest.mark.skip(reason="what do if the PR contains merge commits???")
def test_pr_contains_merges(self, repo, env):
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
pass
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_pr_force_merge_single_commit(self, repo, env, users, config):
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
""" should be possible to flag a PR as regular-merged, regardless of
its commits count
M M<--+
^ ^ |
| -> | C0
+ | ^
C0 + |
gib-+
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, "M", None, tree={'a': 'a'})
repo.make_ref('heads/master', m)
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c0 = repo.make_commit(m, 'C0', None, tree={'a': 'b'})
prx = repo.make_pr(title="gibberish", body="blahblah", target='master', head=c0)
[IMP] *: trigger-ify staging cron The staging cron turns out to be pretty reasonable to trigger, as we already have a handler on the transition of a batch to `not blocked`, which is exactly when we want to create a staging (that and the completion of the previous staging). The batch transition is in a compute which is not awesome, but on the flip side we also cancel active stagings in that exact scenario (if it applies), so that matches. The only real finesse is that one of the tests wants to observe the instant between the end of a staging (and creation of splits) and the start of the next one, which because the staging cron is triggered by the failure of the previous staging is now "atomic", requiring disabling the staging cron, which means the trigger is skipped entirely. So this requires triggering the staging cron by hand.
2024-08-01 15:15:32 +07:00
env.run_crons(None)
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen r+ merge', config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
env.run_crons()
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
master = repo.commit('heads/master')
assert master.parents == [m, prx.head], \
"master's parents should be the old master & the PR head"
m = node('M')
c0 = node('C0', m)
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
reviewer = get_partner(env, users["reviewer"]).formatted_email
expected = node('gibberish\n\nblahblah\n\ncloses {}#{}'
'\n\nSigned-off-by: {}'.format(repo.name, prx.number, reviewer), m, c0)
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
assert log_to_node(repo.log('heads/master')), expected
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[IMP] runbot_merge: map PR commits to integrated commits * when rebasing, store a map of rebased to source, that way it'll be possible to link cherry-picked forward ports to the originally integrated commit rather than just the one from the PR (which was likely not itself integrated as the straight merge mode is somewhat rare: as of 5600 PRs merged so far only 100 were straight merged) * while at it, store the "merge head" of the PR (whether squashed, merged or rebased) and put *that* in the commit message fixes #161
2019-07-31 14:19:39 +07:00
assert json.loads(pr.commits_map) == {
prx.head: prx.head,
'': master.id
}
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_unrebase_emptymessage(self, repo, env, users, config):
[FIX] runbot_merge: handle PRs with no body (not just empty)
2018-09-19 19:40:36 +07:00
""" When merging between master branches (e.g. forward port), the PR
may have only a title
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, "M", None, tree={'a': 'a'})
repo.make_ref('heads/master', m)
[FIX] runbot_merge: handle PRs with no body (not just empty)
2018-09-19 19:40:36 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c0 = repo.make_commit(m, 'C0', None, tree={'a': 'b'})
prx = repo.make_pr(title="gibberish", body=None, target='master', head=c0)
[IMP] *: trigger-ify staging cron The staging cron turns out to be pretty reasonable to trigger, as we already have a handler on the transition of a batch to `not blocked`, which is exactly when we want to create a staging (that and the completion of the previous staging). The batch transition is in a compute which is not awesome, but on the flip side we also cancel active stagings in that exact scenario (if it applies), so that matches. The only real finesse is that one of the tests wants to observe the instant between the end of a staging (and creation of splits) and the start of the next one, which because the staging cron is triggered by the failure of the previous staging is now "atomic", requiring disabling the staging cron, which means the trigger is skipped entirely. So this requires triggering the staging cron by hand.
2024-08-01 15:15:32 +07:00
env.run_crons(None)
[FIX] runbot_merge: handle PRs with no body (not just empty)
2018-09-19 19:40:36 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen r+ merge', config['role_reviewer']['token'])
env.run_crons()
[FIX] runbot_merge: handle PRs with no body (not just empty)
2018-09-19 19:40:36 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
env.run_crons()
[FIX] runbot_merge: handle PRs with no body (not just empty)
2018-09-19 19:40:36 +07:00
master = repo.commit('heads/master')
assert master.parents == [m, prx.head], \
"master's parents should be the old master & the PR head"
m = node('M')
c0 = node('C0', m)
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
reviewer = get_partner(env, users["reviewer"]).formatted_email
expected = node('gibberish\n\ncloses {}#{}'
'\n\nSigned-off-by: {}'.format(repo.name, prx.number, reviewer), m, c0)
[FIX] runbot_merge: handle PRs with no body (not just empty)
2018-09-19 19:40:36 +07:00
assert log_to_node(repo.log('heads/master')), expected
[IMP] runbot_merge: split out content after separator when creating commit Currently when creating *merges* the commit message is the concatenation of the PR title and the PR body. However it can be convenient to include description test which would not be included in the commit message e.g. PR template stuff. "Thematic breaks" seem like a good way to do this: the commit message will only include the content preceding the first thematic break, everything else is ignored (except headings which are not ignored, double negations FTW). Might be that that's a bit excessive and we should only ignore what follows the *last* thematic break. Or that there needs to be a more specific marker. We'll see. Fixes #443.
2021-01-12 18:24:34 +07:00
@pytest.mark.parametrize('separator', [
'***', '___', '\n---',
'*'*12, '\n----------------',
'- - -', ' ** ** **'
])
def test_pr_message_break(self, repo, env, users, config, separator):
""" If the PR message contains a "thematic break", only the part before
should be included in the merge commit's message.
"""
reviewer = get_partner(env, users["reviewer"]).formatted_email
with repo:
root = repo.make_commits(None, Commit("root", tree={'a': 'a'}), ref='heads/master')
[IMP] runbot_merge, forwardport: minor cleanups Remove unused imports, unnecessary f-strings, dead code, fix less-than-ideal operators.
2023-08-10 18:21:21 +07:00
repo.make_commits(root, Commit('C', tree={'a': 'b'}), ref='heads/change')
[IMP] runbot_merge: split out content after separator when creating commit Currently when creating *merges* the commit message is the concatenation of the PR title and the PR body. However it can be convenient to include description test which would not be included in the commit message e.g. PR template stuff. "Thematic breaks" seem like a good way to do this: the commit message will only include the content preceding the first thematic break, everything else is ignored (except headings which are not ignored, double negations FTW). Might be that that's a bit excessive and we should only ignore what follows the *last* thematic break. Or that there needs to be a more specific marker. We'll see. Fixes #443.
2021-01-12 18:24:34 +07:00
pr = repo.make_pr(title="title", body=f'first\n{separator}\nsecond',
[IMP] runbot_merge, forwardport: minor cleanups Remove unused imports, unnecessary f-strings, dead code, fix less-than-ideal operators.
2023-08-10 18:21:21 +07:00
target='master', head='change')
[IMP] runbot_merge: split out content after separator when creating commit Currently when creating *merges* the commit message is the concatenation of the PR title and the PR body. However it can be convenient to include description test which would not be included in the commit message e.g. PR template stuff. "Thematic breaks" seem like a good way to do this: the commit message will only include the content preceding the first thematic break, everything else is ignored (except headings which are not ignored, double negations FTW). Might be that that's a bit excessive and we should only ignore what follows the *last* thematic break. Or that there needs to be a more specific marker. We'll see. Fixes #443.
2021-01-12 18:24:34 +07:00
repo.post_status(pr.head, 'success', 'legal/cla')
repo.post_status(pr.head, 'success', 'ci/runbot')
pr.post_comment('hansen r+ merge', config['role_reviewer']['token'])
env.run_crons()
with repo:
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
env.run_crons()
head = repo.commit('heads/master')
assert head.message == textwrap.dedent(f"""\
title
first
closes {repo.name}#{pr.number}
Signed-off-by: {reviewer}
""").strip(), "should not contain the content which follows the thematic break"
def test_pr_message_setex_title(self, repo, env, users, config):
""" should not break on a proper SETEX-style title """
reviewer = get_partner(env, users["reviewer"]).formatted_email
with repo:
root = repo.make_commits(None, Commit("root", tree={'a': 'a'}), ref='heads/master')
[IMP] runbot_merge, forwardport: minor cleanups Remove unused imports, unnecessary f-strings, dead code, fix less-than-ideal operators.
2023-08-10 18:21:21 +07:00
repo.make_commits(root, Commit('C', tree={'a': 'b'}), ref='heads/change')
[IMP] runbot_merge: split out content after separator when creating commit Currently when creating *merges* the commit message is the concatenation of the PR title and the PR body. However it can be convenient to include description test which would not be included in the commit message e.g. PR template stuff. "Thematic breaks" seem like a good way to do this: the commit message will only include the content preceding the first thematic break, everything else is ignored (except headings which are not ignored, double negations FTW). Might be that that's a bit excessive and we should only ignore what follows the *last* thematic break. Or that there needs to be a more specific marker. We'll see. Fixes #443.
2021-01-12 18:24:34 +07:00
pr = repo.make_pr(title="title", body="""\
Title
---
This is some text
Title 2
-------
This is more text
***
removed
""",
[IMP] runbot_merge, forwardport: minor cleanups Remove unused imports, unnecessary f-strings, dead code, fix less-than-ideal operators.
2023-08-10 18:21:21 +07:00
target='master', head='change')
[IMP] runbot_merge: split out content after separator when creating commit Currently when creating *merges* the commit message is the concatenation of the PR title and the PR body. However it can be convenient to include description test which would not be included in the commit message e.g. PR template stuff. "Thematic breaks" seem like a good way to do this: the commit message will only include the content preceding the first thematic break, everything else is ignored (except headings which are not ignored, double negations FTW). Might be that that's a bit excessive and we should only ignore what follows the *last* thematic break. Or that there needs to be a more specific marker. We'll see. Fixes #443.
2021-01-12 18:24:34 +07:00
repo.post_status(pr.head, 'success', 'legal/cla')
repo.post_status(pr.head, 'success', 'ci/runbot')
pr.post_comment('hansen r+ merge', config['role_reviewer']['token'])
env.run_crons()
with repo:
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
env.run_crons()
head = repo.commit('heads/master')
assert head.message == textwrap.dedent(f"""\
title
Title
---
This is some text
Title 2
-------
This is more text
closes {repo.name}#{pr.number}
Signed-off-by: {reviewer}
""").strip(), "should not break the SETEX titles"
[FIX] runbot_merge: incorrect processing of rebased commit messages 5cf3617eef9ce848d19d8d06c22e47586889df36 intended to create merge messages with only the content of PR descriptions before the first thematic break. However this processing was incorrectly applied to all messages being processed (meaning rebased / squashed commit messages as well). Properly apply thematic break processing to only commit messages created from PR descriptions.
2021-01-21 19:15:32 +07:00
def test_rebase_no_edit(self, repo, env, users, config):
""" Only the merge messages should be de-breaked
"""
reviewer = get_partner(env, users["reviewer"]).formatted_email
with repo:
root = repo.make_commits(None, Commit("root", tree={'a': 'a'}), ref='heads/master')
[IMP] runbot_merge, forwardport: minor cleanups Remove unused imports, unnecessary f-strings, dead code, fix less-than-ideal operators.
2023-08-10 18:21:21 +07:00
repo.make_commits(root, Commit('Commit\n\nfirst\n***\nsecond', tree={'a': 'b'}), ref='heads/change')
pr = repo.make_pr(title="PR", body='first\n***\nsecond',
[FIX] runbot_merge: avoid editing title line of commits When a commit is lacking the purpose (?) tag e.g. `[FIX]`, `[IMP]`, ..., a normal commit message of the form `<module>: <info>` marches the looks of a git pseudo-header. This results in a commit rewrite rejiggering the entire thing and breaking the message by moving the title to the pseudo-headers and mis-promoting either the `closes` line of body content to "title", resulting in a really crappy commit message e.g. odoo/odoo@d4aa9ad0319402e7f7f631af54f132b6aff59dcd. Update the commit rewriting procedure to specifically skip the title line, and re-inject it without processing in the output. Fixes #540
2021-10-20 14:46:53 +07:00
target='master', head='change')
[FIX] runbot_merge: incorrect processing of rebased commit messages 5cf3617eef9ce848d19d8d06c22e47586889df36 intended to create merge messages with only the content of PR descriptions before the first thematic break. However this processing was incorrectly applied to all messages being processed (meaning rebased / squashed commit messages as well). Properly apply thematic break processing to only commit messages created from PR descriptions.
2021-01-21 19:15:32 +07:00
repo.post_status(pr.head, 'success', 'legal/cla')
repo.post_status(pr.head, 'success', 'ci/runbot')
pr.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
with repo:
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
env.run_crons()
head = repo.commit('heads/master')
assert head.message == textwrap.dedent(f"""\
Commit
first
***
second
closes {repo.name}#{pr.number}
Signed-off-by: {reviewer}
""").strip(), "squashed / rebased messages should not be stripped"
[FIX] runbot_merge: avoid editing title line of commits When a commit is lacking the purpose (?) tag e.g. `[FIX]`, `[IMP]`, ..., a normal commit message of the form `<module>: <info>` marches the looks of a git pseudo-header. This results in a commit rewrite rejiggering the entire thing and breaking the message by moving the title to the pseudo-headers and mis-promoting either the `closes` line of body content to "title", resulting in a really crappy commit message e.g. odoo/odoo@d4aa9ad0319402e7f7f631af54f132b6aff59dcd. Update the commit rewriting procedure to specifically skip the title line, and re-inject it without processing in the output. Fixes #540
2021-10-20 14:46:53 +07:00
def test_title_no_edit(self, repo, env, users, config):
"""The first line of a commit message should not be taken in account for
rewriting, especially as it can be untagged and interpreted as a
pseudo-header
"""
with repo:
repo.make_commits(None, Commit("0", tree={'a': '1'}), ref='heads/master')
repo.make_commits(
'master',
Commit('Some: thing\n\nis odd', tree={'b': '1'}),
Commit('thing: thong', tree={'b': '2'}),
ref='heads/change')
pr = repo.make_pr(target='master', head='change')
repo.post_status(pr.head, 'success', 'legal/cla')
repo.post_status(pr.head, 'success', 'ci/runbot')
pr.post_comment('hansen rebase-ff r+', config['role_reviewer']['token'])
env.run_crons()
pr_id = to_pr(env, pr)
assert pr_id.staging_id # check PR is staged
reviewer = get_partner(env, users["reviewer"]).formatted_email
staging_head = repo.commit('staging.master')
assert staging_head.message == f"""\
thing: thong
closes {pr_id.display_name}
Signed-off-by: {reviewer}"""
assert repo.commit(staging_head.parents[0]).message == f"""\
Some: thing
is odd
[CHG] runbot_merge: add signoff & related to all commits if rebased. Untouched commits (straight merge) remain unalterated, but all rebased or squashed commits now get signoff and `Related` headers added on top of the already previously added `part-of`. Implement by generalising `_build_merge_message` to `_build_message` and having `add_self_references` delegate to it, removes some of the redundancy / differential handling. Update the `part_of` helper to also add the S-O-B header to the PR, although it currently does not reference the entire forward port chain. Fixes #876
2024-05-30 15:55:40 +07:00
Part-of: {pr_id.display_name}
Signed-off-by: {reviewer}"""
[FIX] runbot_merge: avoid editing title line of commits When a commit is lacking the purpose (?) tag e.g. `[FIX]`, `[IMP]`, ..., a normal commit message of the form `<module>: <info>` marches the looks of a git pseudo-header. This results in a commit rewrite rejiggering the entire thing and breaking the message by moving the title to the pseudo-headers and mis-promoting either the `closes` line of body content to "title", resulting in a really crappy commit message e.g. odoo/odoo@d4aa9ad0319402e7f7f631af54f132b6aff59dcd. Update the commit rewriting procedure to specifically skip the title line, and re-inject it without processing in the output. Fixes #540
2021-10-20 14:46:53 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_pr_mergehead(self, repo, env, config):
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
""" if the head of the PR is a merge commit and one of the parents is
in the target, replicate the merge commit instead of merging
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
rankdir="BT"
M2 -> M1
C0 -> M1
C1 -> C0
C1 -> M2
C1 [label = "\\N / MERGE"]
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m1 = repo.make_commit(None, "M1", None, tree={'a': '0'})
m2 = repo.make_commit(m1, "M2", None, tree={'a': '1'})
repo.make_ref('heads/master', m2)
c0 = repo.make_commit(m1, 'C0', None, tree={'a': '0', 'b': '2'})
c1 = repo.make_commit([c0, m2], 'C1', None, tree={'a': '1', 'b': '2'})
prx = repo.make_pr(title="T", body="TT", target='master', head=c1)
env.run_crons()
with repo:
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen r+ merge', config['role_reviewer']['token'])
env.run_crons()
with repo:
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
env.run_crons()
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
master = repo.commit('heads/master')
assert master.parents == [m2, c0]
m1 = node('M1')
expected = node('C1', node('C0', m1), node('M2', m1))
assert log_to_node(repo.log('heads/master')), expected
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_pr_mergehead_nonmember(self, repo, env, users, config):
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
""" if the head of the PR is a merge commit but none of the parents is
in the target, merge normally
rankdir="BT"
M2 -> M1
B0 -> M1
C0 -> M1
C1 -> C0
C1 -> B0
MERGE -> M2
MERGE -> C1
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m1 = repo.make_commit(None, "M1", None, tree={'a': '0'})
m2 = repo.make_commit(m1, "M2", None, tree={'a': '1'})
repo.make_ref('heads/master', m2)
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
b0 = repo.make_commit(m1, 'B0', None, tree={'a': '0', 'bb': 'bb'})
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c0 = repo.make_commit(m1, 'C0', None, tree={'a': '0', 'b': '2'})
c1 = repo.make_commit([c0, b0], 'C1', None, tree={'a': '0', 'b': '2', 'bb': 'bb'})
prx = repo.make_pr(title="T", body="TT", target='master', head=c1)
env.run_crons()
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen r+ merge', config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status('heads/staging.master', 'success', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
env.run_crons()
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
master = repo.commit('heads/master')
assert master.parents == [m2, c1]
[ADD] forwardbot * Cherrypicking is handrolled because there seems to be no easy way to programmatically edit commit messages during the cherrypicking sequence: `-n` basically squashes all commits and `-e` invokes a subprocess. `-e` with `VISUAL=false` kinda sorta works (in that it interrupts the process before each commit), however there doesn't seem to be clean status codes so it's difficult to know if the cherrypick failed or if it's just waiting for a commit of this step. Instead, cherrypick commits individually then edit / rewrite their commit messages: * add a reference to the original commit * convert signed-off-by to something else as the original commit was signed off but not necessarily this one * Can't assign users when creating PRs: only repository collaborators or people who commented on the issue / PR (which we're in the process of creating) can be assigned. PR authors are as likely to be collaborators as not, and we can have non-collaborator reviewers. So pinging via a regular comment seems less fraught as a way to notify users.
2019-08-23 21:16:30 +07:00
assert repo.read_tree(master) == {'a': '1', 'b': '2', 'bb': 'bb'}
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
m1 = node('M1')
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
reviewer = get_partner(env, users["reviewer"]).formatted_email
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
expected = node(
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
'T\n\nTT\n\ncloses {}#{}\n\nSigned-off-by: {}'.format(repo.name, prx.number, reviewer),
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
node('M2', m1),
node('C1', node('C0', m1), node('B0', m1))
)
assert log_to_node(repo.log('heads/master')), expected
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
[ADD] runbot_merge: squash mode (partial) Re-introduce a "squash" mode solely for the purpose of fixing up commit messages without having to go and edit them: for now "squash" only works for single-commit PRs, acts as a normal integration (`rebase-ff`) *but* replaces the message of the commit itself by that of the PR, similar to the `merge` modes. This means maintainers can update commit messages to standards by editing the PR description (though this is obviously sensible to edition races with the original author). Fixes #539
2021-10-20 13:58:12 +07:00
def test_squash_merge(self, repo, env, config, users):
[IMP] runbot_merge, forwardport: minor cleanups Remove unused imports, unnecessary f-strings, dead code, fix less-than-ideal operators.
2023-08-10 18:21:21 +07:00
other_user = requests.get('https://api.github.com/user', headers={
[FIX] runbot_merge: multi-commit squashing If commits have different authors (/ committers), the mergebot would ask github to create a commit with an author (/ committer) of `None` / `null`. Apparently github really does not like that, and complains that > nil is not an object So remove the key entirely. Also fix the collision between `author` and the `Co-Authored-By` list, which could lead to trying to set an `author` of `[name, email]` instead of an object, which is also not accepted by github.
2022-12-07 19:25:08 +07:00
'Authorization': 'token %s' % config['role_other']['token'],
}).json()
other_user = {
'name': other_user['name'] or other_user['login'],
# FIXME: not guaranteed
'email': other_user['email'] or 'other@example.org',
}
a_user = {'name': 'bob', 'email': 'builder@example.org', 'date': '1999-04-12T08:19:30Z'}
[ADD] runbot_merge: squash mode (partial) Re-introduce a "squash" mode solely for the purpose of fixing up commit messages without having to go and edit them: for now "squash" only works for single-commit PRs, acts as a normal integration (`rebase-ff`) *but* replaces the message of the commit itself by that of the PR, similar to the `merge` modes. This means maintainers can update commit messages to standards by editing the PR description (though this is obviously sensible to edition races with the original author). Fixes #539
2021-10-20 13:58:12 +07:00
with repo:
repo.make_commits(None, Commit('initial', tree={'a': '0'}), ref='heads/master')
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[FIX] runbot_merge: updating of commit date on rebase On #509, the rebasing process was changed to forcefully update the commit date of the commits, in order to force trigger builds. However when squashing was re-enabled for #539 for some fool reason it implemented its own bespoke rebasing (despite that not actually saving any API call that I can see), meaning it did *not* update the commit date. As such, an old commit being squashed would not get picked up by the runbot, which is what happened to odoo/documentation#1226 (which ultimately had to be hand-rebased after some confusion as to why it did not work). Update `_stage_squash` to go through `rebase` the normal way, also update `rebase` to pop the commit date entirely instead of setting it manually, and update the squashing test to check that the commit date gets properly updated. Fixes #579, closes #582
2022-02-07 18:00:31 +07:00
repo.make_commits(
'master',
[FIX] runbot_merge: multi-commit squashing If commits have different authors (/ committers), the mergebot would ask github to create a commit with an author (/ committer) of `None` / `null`. Apparently github really does not like that, and complains that > nil is not an object So remove the key entirely. Also fix the collision between `author` and the `Co-Authored-By` list, which could lead to trying to set an `author` of `[name, email]` instead of an object, which is also not accepted by github.
2022-12-07 19:25:08 +07:00
Commit('sub', tree={'b': '0'}, committer=a_user),
[FIX] runbot_merge: updating of commit date on rebase On #509, the rebasing process was changed to forcefully update the commit date of the commits, in order to force trigger builds. However when squashing was re-enabled for #539 for some fool reason it implemented its own bespoke rebasing (despite that not actually saving any API call that I can see), meaning it did *not* update the commit date. As such, an old commit being squashed would not get picked up by the runbot, which is what happened to odoo/documentation#1226 (which ultimately had to be hand-rebased after some confusion as to why it did not work). Update `_stage_squash` to go through `rebase` the normal way, also update `rebase` to pop the commit date entirely instead of setting it manually, and update the squashing test to check that the commit date gets properly updated. Fixes #579, closes #582
2022-02-07 18:00:31 +07:00
ref='heads/other'
)
[ADD] runbot_merge: squash mode (partial) Re-introduce a "squash" mode solely for the purpose of fixing up commit messages without having to go and edit them: for now "squash" only works for single-commit PRs, acts as a normal integration (`rebase-ff`) *but* replaces the message of the commit itself by that of the PR, similar to the `merge` modes. This means maintainers can update commit messages to standards by editing the PR description (though this is obviously sensible to edition races with the original author). Fixes #539
2021-10-20 13:58:12 +07:00
pr1 = repo.make_pr(title='first pr', target='master', head='other')
repo.post_status('other', 'success', 'legal/cla')
repo.post_status('other', 'success', 'ci/runbot')
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[FIX] runbot_merge: multi-commit squashing If commits have different authors (/ committers), the mergebot would ask github to create a commit with an author (/ committer) of `None` / `null`. Apparently github really does not like that, and complains that > nil is not an object So remove the key entirely. Also fix the collision between `author` and the `Co-Authored-By` list, which could lead to trying to set an `author` of `[name, email]` instead of an object, which is also not accepted by github.
2022-12-07 19:25:08 +07:00
pr_2_commits = repo.make_commits(
'master',
Commit('x', tree={'x': '0'}, author=other_user, committer=a_user),
Commit('y', tree={'x': '1'}, author=a_user, committer=other_user),
ref='heads/other2',
)
c1, c2 = map(repo.commit, pr_2_commits)
assert c1.author['name'] != c2.author['name']
assert c1.committer['name'] != c2.committer['name']
[ADD] runbot_merge: squash mode (partial) Re-introduce a "squash" mode solely for the purpose of fixing up commit messages without having to go and edit them: for now "squash" only works for single-commit PRs, acts as a normal integration (`rebase-ff`) *but* replaces the message of the commit itself by that of the PR, similar to the `merge` modes. This means maintainers can update commit messages to standards by editing the PR description (though this is obviously sensible to edition races with the original author). Fixes #539
2021-10-20 13:58:12 +07:00
pr2 = repo.make_pr(title='second pr', target='master', head='other2')
repo.post_status('other2', 'success', 'legal/cla')
repo.post_status('other2', 'success', 'ci/runbot')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[ADD] runbot_merge: squash mode (partial) Re-introduce a "squash" mode solely for the purpose of fixing up commit messages without having to go and edit them: for now "squash" only works for single-commit PRs, acts as a normal integration (`rebase-ff`) *but* replaces the message of the commit itself by that of the PR, similar to the `merge` modes. This means maintainers can update commit messages to standards by editing the PR description (though this is obviously sensible to edition races with the original author). Fixes #539
2021-10-20 13:58:12 +07:00
with repo: # comments sequencing
pr1.post_comment('hansen r+ squash', config['role_reviewer']['token'])
pr2.post_comment('hansen r+ squash', config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[ADD] runbot_merge: squash mode (partial) Re-introduce a "squash" mode solely for the purpose of fixing up commit messages without having to go and edit them: for now "squash" only works for single-commit PRs, acts as a normal integration (`rebase-ff`) *but* replaces the message of the commit itself by that of the PR, similar to the `merge` modes. This means maintainers can update commit messages to standards by editing the PR description (though this is obviously sensible to edition races with the original author). Fixes #539
2021-10-20 13:58:12 +07:00
with repo:
repo.post_status('staging.master', 'success', 'legal/cla')
repo.post_status('staging.master', 'success', 'ci/runbot')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: squash mode (partial) Re-introduce a "squash" mode solely for the purpose of fixing up commit messages without having to go and edit them: for now "squash" only works for single-commit PRs, acts as a normal integration (`rebase-ff`) *but* replaces the message of the commit itself by that of the PR, similar to the `merge` modes. This means maintainers can update commit messages to standards by editing the PR description (though this is obviously sensible to edition races with the original author). Fixes #539
2021-10-20 13:58:12 +07:00
# PR 1 should have merged properly, the PR message should be the
# message of the merged commit
pr1_id = to_pr(env, pr1)
assert pr1_id.state == 'merged'
assert pr1.comments == [
seen(env, pr1, users),
(users['reviewer'], 'hansen r+ squash'),
[IMP] *: review mergebot & forwardbot messages for pinging Old messages were quite inconsistent in their pinging of the PR author and reviewer. Reviewed messages (probably missed some but...) and try to more consistently ping when the feedback requires some sort of action in order to proceed. Fixes #592
2022-06-23 19:25:07 +07:00
(users['user'], 'Merge method set to squash.')
[ADD] runbot_merge: squash mode (partial) Re-introduce a "squash" mode solely for the purpose of fixing up commit messages without having to go and edit them: for now "squash" only works for single-commit PRs, acts as a normal integration (`rebase-ff`) *but* replaces the message of the commit itself by that of the PR, similar to the `merge` modes. This means maintainers can update commit messages to standards by editing the PR description (though this is obviously sensible to edition races with the original author). Fixes #539
2021-10-20 13:58:12 +07:00
]
[ADD] runbot_merge: multi-commit squash mode Fixes #672
2022-11-04 15:16:58 +07:00
pr2_id = to_pr(env, pr2)
assert pr2_id.state == 'merged'
assert pr2.comments == [
seen(env, pr2, users),
(users['reviewer'], 'hansen r+ squash'),
(users['user'], 'Merge method set to squash.'),
]
two, one, _root = repo.log('master')
assert one['commit']['message'] == f"""first pr
[ADD] runbot_merge: squash mode (partial) Re-introduce a "squash" mode solely for the purpose of fixing up commit messages without having to go and edit them: for now "squash" only works for single-commit PRs, acts as a normal integration (`rebase-ff`) *but* replaces the message of the commit itself by that of the PR, similar to the `merge` modes. This means maintainers can update commit messages to standards by editing the PR description (though this is obviously sensible to edition races with the original author). Fixes #539
2021-10-20 13:58:12 +07:00
closes {pr1_id.display_name}
Signed-off-by: {get_partner(env, users["reviewer"]).formatted_email}\
"""
[FIX] runbot_merge: multi-commit squashing If commits have different authors (/ committers), the mergebot would ask github to create a commit with an author (/ committer) of `None` / `null`. Apparently github really does not like that, and complains that > nil is not an object So remove the key entirely. Also fix the collision between `author` and the `Co-Authored-By` list, which could lead to trying to set an `author` of `[name, email]` instead of an object, which is also not accepted by github.
2022-12-07 19:25:08 +07:00
assert one['commit']['committer']['name'] == a_user['name']
assert one['commit']['committer']['email'] == a_user['email']
[ADD] runbot_merge: multi-commit squash mode Fixes #672
2022-11-04 15:16:58 +07:00
commit_date = datetime.datetime.strptime(one['commit']['committer']['date'], '%Y-%m-%dT%H:%M:%SZ')
[FIX] runbot_merge: updating of commit date on rebase On #509, the rebasing process was changed to forcefully update the commit date of the commits, in order to force trigger builds. However when squashing was re-enabled for #539 for some fool reason it implemented its own bespoke rebasing (despite that not actually saving any API call that I can see), meaning it did *not* update the commit date. As such, an old commit being squashed would not get picked up by the runbot, which is what happened to odoo/documentation#1226 (which ultimately had to be hand-rebased after some confusion as to why it did not work). Update `_stage_squash` to go through `rebase` the normal way, also update `rebase` to pop the commit date entirely instead of setting it manually, and update the squashing test to check that the commit date gets properly updated. Fixes #579, closes #582
2022-02-07 18:00:31 +07:00
# using timestamp (and working in seconds) because `pytest.approx`
# silently fails on datetimes (#8395)
assert commit_date.timestamp() == pytest.approx(time.time(), abs=5*60), \
"the commit date of the merged commit should be about now, despite" \
" the source commit being >20 years old"
[ADD] runbot_merge: squash mode (partial) Re-introduce a "squash" mode solely for the purpose of fixing up commit messages without having to go and edit them: for now "squash" only works for single-commit PRs, acts as a normal integration (`rebase-ff`) *but* replaces the message of the commit itself by that of the PR, similar to the `merge` modes. This means maintainers can update commit messages to standards by editing the PR description (though this is obviously sensible to edition races with the original author). Fixes #539
2021-10-20 13:58:12 +07:00
[FIX] runbot_merge: multi-commit squashing If commits have different authors (/ committers), the mergebot would ask github to create a commit with an author (/ committer) of `None` / `null`. Apparently github really does not like that, and complains that > nil is not an object So remove the key entirely. Also fix the collision between `author` and the `Co-Authored-By` list, which could lead to trying to set an `author` of `[name, email]` instead of an object, which is also not accepted by github.
2022-12-07 19:25:08 +07:00
# FIXME: should probably get the token from the project to be sure it's
# the bot user
[IMP] runbot_merge, forwardport: minor cleanups Remove unused imports, unnecessary f-strings, dead code, fix less-than-ideal operators.
2023-08-10 18:21:21 +07:00
current_user = repo._session.get('https://api.github.com/user').json()
[FIX] runbot_merge: multi-commit squashing If commits have different authors (/ committers), the mergebot would ask github to create a commit with an author (/ committer) of `None` / `null`. Apparently github really does not like that, and complains that > nil is not an object So remove the key entirely. Also fix the collision between `author` and the `Co-Authored-By` list, which could lead to trying to set an `author` of `[name, email]` instead of an object, which is also not accepted by github.
2022-12-07 19:25:08 +07:00
current_user = {
'name': current_user['name'] or current_user['login'],
# FIXME: not guaranteed
'email': current_user['email'] or 'user@example.org',
}
# since there are two authors & two committers on pr2, the auhor and
# committer of a squash commit should be reset to the bot's identity
assert two['commit']['committer']['name'] == current_user['name']
assert two['commit']['committer']['email'] == current_user['email']
assert two['commit']['author']['name'] == current_user['name']
assert two['commit']['author']['email'] == current_user['email']
[ADD] runbot_merge: multi-commit squash mode Fixes #672
2022-11-04 15:16:58 +07:00
assert two['commit']['message'] == f"""second pr
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[ADD] runbot_merge: multi-commit squash mode Fixes #672
2022-11-04 15:16:58 +07:00
closes {pr2_id.display_name}
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[FIX] runbot_merge: multi-commit squashing If commits have different authors (/ committers), the mergebot would ask github to create a commit with an author (/ committer) of `None` / `null`. Apparently github really does not like that, and complains that > nil is not an object So remove the key entirely. Also fix the collision between `author` and the `Co-Authored-By` list, which could lead to trying to set an `author` of `[name, email]` instead of an object, which is also not accepted by github.
2022-12-07 19:25:08 +07:00
Signed-off-by: {get_partner(env, users["reviewer"]).formatted_email}
Co-authored-by: {a_user['name']} <{a_user['email']}>
Co-authored-by: {other_user['name']} <{other_user['email']}>\
[ADD] runbot_merge: multi-commit squash mode Fixes #672
2022-11-04 15:16:58 +07:00
"""
assert repo.read_tree(repo.commit(two['sha'])) == {
'a': '0',
'b': '0',
'x': '1',
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
}
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
class TestPRUpdate:
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
""" Pushing on a PR should update the HEAD except for merged PRs, it
can have additional effect (see individual tests)
"""
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
@pytest.fixture(autouse=True)
def master(self, repo):
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[m] = repo.make_commits(None, Commit('initial', tree={'m': 'm'}), ref="heads/master")
return m
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
def test_update_opened(self, env, repo):
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[CHG] runbot_merge: make merge method non-blocking Because of the false negatives due to github's reordering of events on retargeting, blocking merge methods can be rather frustrating or the user as what's happening and how to solve it isn't clear in that case. Keep the warnings and all, but remove the blocking factor: if a PR doesn't have a merge method and is not single-commit, just skip it on staging. This way, PRs which are actually single-commit will stage fine even if the mergebot thinks they shouldn't be. Fixes #957
2024-10-07 13:07:59 +07:00
[c] = repo.make_commits("master", Commit('first', tree={'m': 'c1'}))
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
prx = repo.make_pr(target='master', head=c)
[IMP] *: make to_pr more resilient to webhook delays Github delivery delays keep getting worse. Depending on what comes before `to_pr`, this leads it to fail more often as it runs before the PR it's looking for was signaled to the mergebot. In order to mitigate this issue, add a wait loop in `to_pr`, waiting up to 4 seconds for the PR it's looking for before aborting. Also replace manual lookups by `to_pr` in every method of `TestPRUpdate` while at it since it hit a few of the issues. And remove the xfail test case since it seems unlikely github will change tack (maybe? could be worth testing to be sure).
2024-01-16 21:03:45 +07:00
pr = to_pr(env, prx)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr.head == c
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
# alter & push force PR entirely
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c2] = repo.make_commits("master", Commit('first', tree={'m': 'cc'}))
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
repo.update_ref(prx.ref, c2, force=True)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr.head == c2
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
@pytest.mark.defaultstatuses
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
def test_update_validated(self, env, repo):
""" Should reset to opened
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c] = repo.make_commits("master", Commit('first', tree={'m': 'c1'}))
pr = repo.make_pr(target='master', head=c)
repo.post_status(c, 'success')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
pr_id = to_pr(env, pr)
assert pr_id.head == c
assert pr_id.state == 'validated'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c2] = repo.make_commits("master", Commit('first', tree={'m': 'cc'}))
repo.update_ref(pr.ref, c2, force=True)
assert pr_id.head == c2
assert pr_id.state == 'opened'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_update_approved(self, env, repo, config):
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c] = repo.make_commits("master", Commit('fist', tree={'m': 'c1'}))
prx = repo.make_pr(target='master', head=c)
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx.post_comment('hansen r+', config['role_reviewer']['token'])
[IMP] *: make to_pr more resilient to webhook delays Github delivery delays keep getting worse. Depending on what comes before `to_pr`, this leads it to fail more often as it runs before the PR it's looking for was signaled to the mergebot. In order to mitigate this issue, add a wait loop in `to_pr`, waiting up to 4 seconds for the PR it's looking for before aborting. Also replace manual lookups by `to_pr` in every method of `TestPRUpdate` while at it since it hit a few of the issues. And remove the xfail test case since it seems unlikely github will change tack (maybe? could be worth testing to be sure).
2024-01-16 21:03:45 +07:00
pr = to_pr(env, prx)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr.head == c
assert pr.state == 'approved'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c2] = repo.make_commits("master", Commit('first', tree={'m': 'cc'}))
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
repo.update_ref(prx.ref, c2, force=True)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr.head == c2
[CHG] runbot_merge: unapprove on PR update After discussion with mat, rco and moc, if a PR is updated it should be unapproved for safety reasons: if a reviewer approves a PR, that's what should be merged, if there are things to fix/change a reviewer should at least rubberstamp the changes to avoid mistakes. This is a bit more noisy/constraining, but can be changed or tuned afterwards if it's considered too constraining.
2018-09-03 18:55:39 +07:00
assert pr.state == 'opened'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
@pytest.mark.defaultstatuses
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_update_ready(self, env, repo, config):
[CHG] runbot_merge: unapprove on PR update After discussion with mat, rco and moc, if a PR is updated it should be unapproved for safety reasons: if a reviewer approves a PR, that's what should be merged, if there are things to fix/change a reviewer should at least rubberstamp the changes to avoid mistakes. This is a bit more noisy/constraining, but can be changed or tuned afterwards if it's considered too constraining.
2018-09-03 18:55:39 +07:00
""" Should reset to opened
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c] = repo.make_commits("master", Commit('fist', tree={'m': 'c1'}))
prx = repo.make_pr(target='master', head=c)
repo.post_status(prx.head, 'success')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
[IMP] *: make to_pr more resilient to webhook delays Github delivery delays keep getting worse. Depending on what comes before `to_pr`, this leads it to fail more often as it runs before the PR it's looking for was signaled to the mergebot. In order to mitigate this issue, add a wait loop in `to_pr`, waiting up to 4 seconds for the PR it's looking for before aborting. Also replace manual lookups by `to_pr` in every method of `TestPRUpdate` while at it since it hit a few of the issues. And remove the xfail test case since it seems unlikely github will change tack (maybe? could be worth testing to be sure).
2024-01-16 21:03:45 +07:00
pr = to_pr(env, prx)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr.head == c
assert pr.state == 'ready'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c2] = repo.make_commits(c, Commit('first', tree={'m': 'cc'}))
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
repo.update_ref(prx.ref, c2, force=True)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr.head == c2
[CHG] runbot_merge: unapprove on PR update After discussion with mat, rco and moc, if a PR is updated it should be unapproved for safety reasons: if a reviewer approves a PR, that's what should be merged, if there are things to fix/change a reviewer should at least rubberstamp the changes to avoid mistakes. This is a bit more noisy/constraining, but can be changed or tuned afterwards if it's considered too constraining.
2018-09-03 18:55:39 +07:00
assert pr.state == 'opened'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
@pytest.mark.defaultstatuses
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_update_staged(self, env, repo, config):
[CHG] runbot_merge: unapprove on PR update After discussion with mat, rco and moc, if a PR is updated it should be unapproved for safety reasons: if a reviewer approves a PR, that's what should be merged, if there are things to fix/change a reviewer should at least rubberstamp the changes to avoid mistakes. This is a bit more noisy/constraining, but can be changed or tuned afterwards if it's considered too constraining.
2018-09-03 18:55:39 +07:00
""" Should cancel the staging & reset PR to opened
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c] = repo.make_commits("master", Commit('fist', tree={'m': 'c1'}))
prx = repo.make_pr(target='master', head=c)
repo.post_status(prx.head, 'success')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx.post_comment('hansen r+', config['role_reviewer']['token'])
[IMP] *: make to_pr more resilient to webhook delays Github delivery delays keep getting worse. Depending on what comes before `to_pr`, this leads it to fail more often as it runs before the PR it's looking for was signaled to the mergebot. In order to mitigate this issue, add a wait loop in `to_pr`, waiting up to 4 seconds for the PR it's looking for before aborting. Also replace manual lookups by `to_pr` in every method of `TestPRUpdate` while at it since it hit a few of the issues. And remove the xfail test case since it seems unlikely github will change tack (maybe? could be worth testing to be sure).
2024-01-16 21:03:45 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] *: make to_pr more resilient to webhook delays Github delivery delays keep getting worse. Depending on what comes before `to_pr`, this leads it to fail more often as it runs before the PR it's looking for was signaled to the mergebot. In order to mitigate this issue, add a wait loop in `to_pr`, waiting up to 4 seconds for the PR it's looking for before aborting. Also replace manual lookups by `to_pr` in every method of `TestPRUpdate` while at it since it hit a few of the issues. And remove the xfail test case since it seems unlikely github will change tack (maybe? could be worth testing to be sure).
2024-01-16 21:03:45 +07:00
pr = to_pr(env, prx)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr.state == 'ready'
assert pr.staging_id
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c2] = repo.make_commits(c, Commit('first', tree={'m': 'cc'}))
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
repo.update_ref(prx.ref, c2, force=True)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr.head == c2
[CHG] runbot_merge: unapprove on PR update After discussion with mat, rco and moc, if a PR is updated it should be unapproved for safety reasons: if a reviewer approves a PR, that's what should be merged, if there are things to fix/change a reviewer should at least rubberstamp the changes to avoid mistakes. This is a bit more noisy/constraining, but can be changed or tuned afterwards if it's considered too constraining.
2018-09-03 18:55:39 +07:00
assert pr.state == 'opened'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert not pr.staging_id
assert not env['runbot_merge.stagings'].search([])
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
@pytest.mark.defaultstatuses
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_split(self, env, repo, config):
[FIX] runbot_merge: PR splits should be updated on PR state change On a PR being updated, closed or unreviewed, if it is part of an active staging that staging would get cancelled (yay). However, if the PR was part of a pending *split*, then the split would *not* get cancelled / updated (to remove the PR from it), and the PR could go on to get staged as if everything were right in the world which is an issue. It doesn't look like it actually happened (at least I got no echo of it), but it almost did at least once. fixes #160
2019-07-31 14:20:02 +07:00
""" Should remove the PR from its split, and possibly delete the split
entirely.
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
repo.make_commits("master", Commit('first', tree={'1': '1'}), ref="heads/p1")
prx1 = repo.make_pr(target='master', head='p1')
repo.post_status(prx1.head, 'success')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx1.post_comment('hansen r+', config['role_reviewer']['token'])
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c] = repo.make_commits("master", Commit('first', tree={'2': '2'}), ref="heads/p2")
prx2 = repo.make_pr(target='master', head='p2')
repo.post_status(prx2.head, 'success')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx2.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
[FIX] runbot_merge: PR splits should be updated on PR state change On a PR being updated, closed or unreviewed, if it is part of an active staging that staging would get cancelled (yay). However, if the PR was part of a pending *split*, then the split would *not* get cancelled / updated (to remove the PR from it), and the PR could go on to get staged as if everything were right in the world which is an issue. It doesn't look like it actually happened (at least I got no echo of it), but it almost did at least once. fixes #160
2019-07-31 14:20:02 +07:00
pr1, pr2 = env['runbot_merge.pull_requests'].search([], order='number')
assert pr1.number == prx1.number
assert pr2.number == prx2.number
assert pr1.staging_id == pr2.staging_id
s0 = pr1.staging_id
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
repo.post_status('heads/staging.master', 'failure')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[FIX] runbot_merge: PR splits should be updated on PR state change On a PR being updated, closed or unreviewed, if it is part of an active staging that staging would get cancelled (yay). However, if the PR was part of a pending *split*, then the split would *not* get cancelled / updated (to remove the PR from it), and the PR could go on to get staged as if everything were right in the world which is an issue. It doesn't look like it actually happened (at least I got no echo of it), but it almost did at least once. fixes #160
2019-07-31 14:20:02 +07:00
assert pr1.staging_id and pr1.staging_id != s0, "pr1 should have been re-staged"
assert not pr2.staging_id, "pr2 should not"
# TODO: remote doesn't currently handle env context so can't mess
# around using active_test=False
assert env['runbot_merge.split'].search([])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c2] = repo.make_commits(c, Commit('second', tree={'2': '22'}))
repo.update_ref(prx2.ref, c2, force=True)
[FIX] runbot_merge: PR splits should be updated on PR state change On a PR being updated, closed or unreviewed, if it is part of an active staging that staging would get cancelled (yay). However, if the PR was part of a pending *split*, then the split would *not* get cancelled / updated (to remove the PR from it), and the PR could go on to get staged as if everything were right in the world which is an issue. It doesn't look like it actually happened (at least I got no echo of it), but it almost did at least once. fixes #160
2019-07-31 14:20:02 +07:00
# probably not necessary ATM but...
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[FIX] runbot_merge: PR splits should be updated on PR state change On a PR being updated, closed or unreviewed, if it is part of an active staging that staging would get cancelled (yay). However, if the PR was part of a pending *split*, then the split would *not* get cancelled / updated (to remove the PR from it), and the PR could go on to get staged as if everything were right in the world which is an issue. It doesn't look like it actually happened (at least I got no echo of it), but it almost did at least once. fixes #160
2019-07-31 14:20:02 +07:00
assert pr2.state == 'opened', "state should have been reset"
assert not env['runbot_merge.split'].search([]), "there should be no split left"
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
@pytest.mark.defaultstatuses
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_update_error(self, env, repo, config):
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c] = repo.make_commits("master", Commit('fist', tree={'m': 'c1'}))
prx = repo.make_pr(target='master', head=c)
repo.post_status(prx.head, 'success')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
[IMP] *: make to_pr more resilient to webhook delays Github delivery delays keep getting worse. Depending on what comes before `to_pr`, this leads it to fail more often as it runs before the PR it's looking for was signaled to the mergebot. In order to mitigate this issue, add a wait loop in `to_pr`, waiting up to 4 seconds for the PR it's looking for before aborting. Also replace manual lookups by `to_pr` in every method of `TestPRUpdate` while at it since it hit a few of the issues. And remove the xfail test case since it seems unlikely github will change tack (maybe? could be worth testing to be sure).
2024-01-16 21:03:45 +07:00
pr = to_pr(env, prx)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr.state == 'ready'
assert pr.staging_id
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
repo.post_status('staging.master', 'failure')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert not pr.staging_id
assert pr.state == 'error'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c2] = repo.make_commits(c, Commit('first', tree={'m': 'cc'}))
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
repo.update_ref(prx.ref, c2, force=True)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr.head == c2
[IMP] runbot_merge: add logging to PR sync and reset error PRs to open The choice to keep sync'd PRs in error means it's possible to update the code and re-run the PR directly without it going through review & CI again, which is a bit odd. Remove the special case and always reset a sync'd PR to opened for clarity and simplicity. closes #71 closes #83
2019-03-01 21:52:13 +07:00
assert pr.state == 'opened'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
def test_unknown_pr(self, env, repo):
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[m, c] = repo.make_commits(
None,
Commit('initial', tree={'m': 'm'}),
Commit('first', tree={'m': 'c1'}),
)
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
repo.make_ref('heads/1.0', m)
prx = repo.make_pr(title='title', body='body', target='1.0', head=c)
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
with pytest.raises(TimeoutError):
to_pr(env, prx)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
env['runbot_merge.project'].search([]).write({
'branch_ids': [(0, 0, {'name': '1.0'})]
})
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c2] = repo.make_commits(c, Commit('second', tree={'m': 'c2'}))
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
repo.update_ref(prx.ref, c2, force=True)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
with pytest.raises(TimeoutError):
to_pr(env, prx)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
@pytest.mark.defaultstatuses
[FIX] runbot_merge: validate PRs on head update If a PR gets sync'd to a known-valid commit, it should be marked as valid rather than get in this weird state where it's merely open but github knows it passes CI. Fixes #72
2019-03-04 16:34:40 +07:00
def test_update_to_ci(self, env, repo):
""" If a PR is updated to a known-valid commit, it should be
validated
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c] = repo.make_commits("master", Commit('fist', tree={'m': 'c1'}))
[c2] = repo.make_commits("master", Commit('first', tree={'m': 'cc'}))
repo.post_status(c2, 'success')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
prx = repo.make_pr(target='master', head=c)
[IMP] *: make to_pr more resilient to webhook delays Github delivery delays keep getting worse. Depending on what comes before `to_pr`, this leads it to fail more often as it runs before the PR it's looking for was signaled to the mergebot. In order to mitigate this issue, add a wait loop in `to_pr`, waiting up to 4 seconds for the PR it's looking for before aborting. Also replace manual lookups by `to_pr` in every method of `TestPRUpdate` while at it since it hit a few of the issues. And remove the xfail test case since it seems unlikely github will change tack (maybe? could be worth testing to be sure).
2024-01-16 21:03:45 +07:00
pr = to_pr(env, prx)
[FIX] runbot_merge: validate PRs on head update If a PR gets sync'd to a known-valid commit, it should be marked as valid rather than get in this weird state where it's merely open but github knows it passes CI. Fixes #72
2019-03-04 16:34:40 +07:00
assert pr.head == c
assert pr.state == 'opened'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.update_ref(prx.ref, c2, force=True)
[FIX] runbot_merge: validate PRs on head update If a PR gets sync'd to a known-valid commit, it should be marked as valid rather than get in this weird state where it's merely open but github knows it passes CI. Fixes #72
2019-03-04 16:34:40 +07:00
assert pr.head == c2
assert pr.state == 'validated'
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
@pytest.mark.defaultstatuses
[FIX] runbot_merge: sync PR target and message on `check` Previously the mergebot would only sync the head commit, but synching more is useful. Also update the final sanity check on staging: - as with check, update the message & target branch - reset PR state and post a message when updating message instead of doing so silently Note: maybe only fail the staging if the message is updated *and* relevant to staging (aka there's a merge method and it's not `rebase`)? Fixes #680
2023-01-20 21:16:37 +07:00
def test_update_missed(self, env, repo, config, users):
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
""" Sometimes github's webhooks don't trigger properly, a branch's HEAD
does not get updated and we might e.g. attempt to merge a PR despite it
now being unreviewed or failing CI or somesuch.
[FIX] runbot_merge: sync PR target and message on `check` Previously the mergebot would only sync the head commit, but synching more is useful. Also update the final sanity check on staging: - as with check, update the message & target branch - reset PR state and post a message when updating message instead of doing so silently Note: maybe only fail the staging if the message is updated *and* relevant to staging (aka there's a merge method and it's not `rebase`)? Fixes #680
2023-01-20 21:16:37 +07:00
Therefore during the staging process we should check what we can, reject
the staging if cricical properties were found to mismatch, and notify
the pull request.
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
[FIX] runbot_merge: sync PR target and message on `check` Previously the mergebot would only sync the head commit, but synching more is useful. Also update the final sanity check on staging: - as with check, update the message & target branch - reset PR state and post a message when updating message instead of doing so silently Note: maybe only fail the staging if the message is updated *and* relevant to staging (aka there's a merge method and it's not `rebase`)? Fixes #680
2023-01-20 21:16:37 +07:00
The PR should then be reset to open (and transition to validated on its
own if the existing or new head has valid statuses), we don't want to
put it in an error state as technically there's no error, just something
which went a bit weird.
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
"""
with repo:
[FIX] runbot_merge: sync PR target and message on `check` Previously the mergebot would only sync the head commit, but synching more is useful. Also update the final sanity check on staging: - as with check, update the message & target branch - reset PR state and post a message when updating message instead of doing so silently Note: maybe only fail the staging if the message is updated *and* relevant to staging (aka there's a merge method and it's not `rebase`)? Fixes #680
2023-01-20 21:16:37 +07:00
[c] = repo.make_commits(None, repo.Commit('m', tree={'a': '0'}), ref='heads/master')
repo.make_ref('heads/somethingelse', c)
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
[c] = repo.make_commits(
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
'master', repo.Commit('title \n\nbody', tree={'a': '1'}), ref='heads/abranch')
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
pr = repo.make_pr(target='master', head='abranch')
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
repo.post_status(pr.head, 'success')
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
pr.post_comment('hansen r+', config['role_reviewer']['token'])
[IMP] *: make to_pr more resilient to webhook delays Github delivery delays keep getting worse. Depending on what comes before `to_pr`, this leads it to fail more often as it runs before the PR it's looking for was signaled to the mergebot. In order to mitigate this issue, add a wait loop in `to_pr`, waiting up to 4 seconds for the PR it's looking for before aborting. Also replace manual lookups by `to_pr` in every method of `TestPRUpdate` while at it since it hit a few of the issues. And remove the xfail test case since it seems unlikely github will change tack (maybe? could be worth testing to be sure).
2024-01-16 21:03:45 +07:00
env.run_crons()
pr_id = to_pr(env, pr)
[IMP] *: rely only on triggers to run statuses propagation The cron had been converted to using mostly triggers in 7cd9afe7f2ff2cbaaabe0ecf6eb364b55aaf8d60 but I forgot to update the *tests* to avoid explicitly triggering it.
2024-07-30 18:42:00 +07:00
env.run_crons(None)
[FIX] runbot_merge: a few issues with updated staging check 1cea247e6ce6b8add5bca06634655e43a53024dd tried to improve staging checks to avoid staging PRs in the wrong state, however it had two issues: PR state -------- The process would reset the PR's state to open, but unless the head was being resync'd it wouldn't re-apply the statuses on the state, leading to a PR with all-valid statuses, but a missing CI. Message ------- The message check didn't compose the PR message the same way PR creation / update did (it did not trim the title and description individually, only after concatenation), resulting in a not-actually-existing divergence getting signaled in the case where the PR title ends or the description starts with whitespace. Expand relevant test, add a utility function to compose a PR message and use it everywhere for coherence. Also update the logging and reporting to show a diff of all the updated items (hidden behind a `details` element).
2023-02-14 19:38:37 +07:00
assert pr_id.message == 'title\n\nbody'
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
assert pr_id.state == 'ready'
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
old_reviewer = pr_id.reviewed_by
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
# TODO: find way to somehow skip / ignore the update_ref?
with repo:
# can't push a second commit because then the staging crashes due
# to the PR *actually* having more than 1 commit and thus needing
# a configuration
[c2] = repo.make_commits('heads/master', repo.Commit('c2', tree={'a': '2'}))
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
repo.post_status(c2, 'success')
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
repo.update_ref(pr.ref, c2, force=True)
[FIX] runbot_merge: sync PR target and message on `check` Previously the mergebot would only sync the head commit, but synching more is useful. Also update the final sanity check on staging: - as with check, update the message & target branch - reset PR state and post a message when updating message instead of doing so silently Note: maybe only fail the staging if the message is updated *and* relevant to staging (aka there's a merge method and it's not `rebase`)? Fixes #680
2023-01-20 21:16:37 +07:00
other = env['runbot_merge.branch'].create({
'name': 'somethingelse',
'project_id': env['runbot_merge.project'].search([]).id,
})
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
# we missed the update notification so the db should still be at c and
# in a "ready" state
pr_id.write({
'head': c,
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
'reviewed_by': old_reviewer.id,
[FIX] runbot_merge: sync PR target and message on `check` Previously the mergebot would only sync the head commit, but synching more is useful. Also update the final sanity check on staging: - as with check, update the message & target branch - reset PR state and post a message when updating message instead of doing so silently Note: maybe only fail the staging if the message is updated *and* relevant to staging (aka there's a merge method and it's not `rebase`)? Fixes #680
2023-01-20 21:16:37 +07:00
'message': "Something else",
'target': other.id,
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
})
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
assert pr_id.head == c
assert pr_id.state == "ready"
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
env.run_crons()
# the PR should not get merged, and should be updated
assert pr_id.state == 'validated'
assert pr_id.head == c2
[FIX] runbot_merge: a few issues with updated staging check 1cea247e6ce6b8add5bca06634655e43a53024dd tried to improve staging checks to avoid staging PRs in the wrong state, however it had two issues: PR state -------- The process would reset the PR's state to open, but unless the head was being resync'd it wouldn't re-apply the statuses on the state, leading to a PR with all-valid statuses, but a missing CI. Message ------- The message check didn't compose the PR message the same way PR creation / update did (it did not trim the title and description individually, only after concatenation), resulting in a not-actually-existing divergence getting signaled in the case where the PR title ends or the description starts with whitespace. Expand relevant test, add a utility function to compose a PR message and use it everywhere for coherence. Also update the logging and reporting to show a diff of all the updated items (hidden behind a `details` element).
2023-02-14 19:38:37 +07:00
assert pr_id.message == 'title\n\nbody'
[FIX] runbot_merge: sync PR target and message on `check` Previously the mergebot would only sync the head commit, but synching more is useful. Also update the final sanity check on staging: - as with check, update the message & target branch - reset PR state and post a message when updating message instead of doing so silently Note: maybe only fail the staging if the message is updated *and* relevant to staging (aka there's a merge method and it's not `rebase`)? Fixes #680
2023-01-20 21:16:37 +07:00
assert pr_id.target.name == 'master'
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
assert pr.comments[-1]['body'] == f"""\
@{users['user']} we apparently missed updates to this PR and tried to stage it in a state \
[FIX] runbot_merge: sync PR target and message on `check` Previously the mergebot would only sync the head commit, but synching more is useful. Also update the final sanity check on staging: - as with check, update the message & target branch - reset PR state and post a message when updating message instead of doing so silently Note: maybe only fail the staging if the message is updated *and* relevant to staging (aka there's a merge method and it's not `rebase`)? Fixes #680
2023-01-20 21:16:37 +07:00
which might not have been approved.
[FIX] runbot_merge: a few issues with updated staging check 1cea247e6ce6b8add5bca06634655e43a53024dd tried to improve staging checks to avoid staging PRs in the wrong state, however it had two issues: PR state -------- The process would reset the PR's state to open, but unless the head was being resync'd it wouldn't re-apply the statuses on the state, leading to a PR with all-valid statuses, but a missing CI. Message ------- The message check didn't compose the PR message the same way PR creation / update did (it did not trim the title and description individually, only after concatenation), resulting in a not-actually-existing divergence getting signaled in the case where the PR title ends or the description starts with whitespace. Expand relevant test, add a utility function to compose a PR message and use it everywhere for coherence. Also update the logging and reporting to show a diff of all the updated items (hidden behind a `details` element).
2023-02-14 19:38:37 +07:00
The properties Head, Target, Message were not correctly synchronized and have been updated.
<details><summary>differences</summary>
```diff
Head:
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
- {c}
+ {c2}
[FIX] runbot_merge: a few issues with updated staging check 1cea247e6ce6b8add5bca06634655e43a53024dd tried to improve staging checks to avoid staging PRs in the wrong state, however it had two issues: PR state -------- The process would reset the PR's state to open, but unless the head was being resync'd it wouldn't re-apply the statuses on the state, leading to a PR with all-valid statuses, but a missing CI. Message ------- The message check didn't compose the PR message the same way PR creation / update did (it did not trim the title and description individually, only after concatenation), resulting in a not-actually-existing divergence getting signaled in the case where the PR title ends or the description starts with whitespace. Expand relevant test, add a utility function to compose a PR message and use it everywhere for coherence. Also update the logging and reporting to show a diff of all the updated items (hidden behind a `details` element).
2023-02-14 19:38:37 +07:00
Target branch:
- somethingelse
+ master
Message:
- Something else
+ title
+ body
+
```
</details>
[FIX] runbot_merge: sync PR target and message on `check` Previously the mergebot would only sync the head commit, but synching more is useful. Also update the final sanity check on staging: - as with check, update the message & target branch - reset PR state and post a message when updating message instead of doing so silently Note: maybe only fail the staging if the message is updated *and* relevant to staging (aka there's a merge method and it's not `rebase`)? Fixes #680
2023-01-20 21:16:37 +07:00
Note that we are unable to check the properties Merge Method, Overrides, Draft.
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
[FIX] runbot_merge: sync PR target and message on `check` Previously the mergebot would only sync the head commit, but synching more is useful. Also update the final sanity check on staging: - as with check, update the message & target branch - reset PR state and post a message when updating message instead of doing so silently Note: maybe only fail the staging if the message is updated *and* relevant to staging (aka there's a merge method and it's not `rebase`)? Fixes #680
2023-01-20 21:16:37 +07:00
Please check and re-approve.
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
"""
[FIX] runbot_merge: a few issues with updated staging check 1cea247e6ce6b8add5bca06634655e43a53024dd tried to improve staging checks to avoid staging PRs in the wrong state, however it had two issues: PR state -------- The process would reset the PR's state to open, but unless the head was being resync'd it wouldn't re-apply the statuses on the state, leading to a PR with all-valid statuses, but a missing CI. Message ------- The message check didn't compose the PR message the same way PR creation / update did (it did not trim the title and description individually, only after concatenation), resulting in a not-actually-existing divergence getting signaled in the case where the PR title ends or the description starts with whitespace. Expand relevant test, add a utility function to compose a PR message and use it everywhere for coherence. Also update the logging and reporting to show a diff of all the updated items (hidden behind a `details` element).
2023-02-14 19:38:37 +07:00
# if the head commit doesn't change, that part should still be valid
with repo:
pr.post_comment('hansen r+', config['role_reviewer']['token'])
assert pr_id.state == 'ready'
pr_id.write({'message': 'wrong'})
env.run_crons()
assert pr_id.message == 'title\n\nbody'
assert pr_id.state == 'validated'
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
assert pr.comments[-1]['body'] == f"""\
@{users['user']} we apparently missed updates to this PR and tried to stage it in a state \
[FIX] runbot_merge: a few issues with updated staging check 1cea247e6ce6b8add5bca06634655e43a53024dd tried to improve staging checks to avoid staging PRs in the wrong state, however it had two issues: PR state -------- The process would reset the PR's state to open, but unless the head was being resync'd it wouldn't re-apply the statuses on the state, leading to a PR with all-valid statuses, but a missing CI. Message ------- The message check didn't compose the PR message the same way PR creation / update did (it did not trim the title and description individually, only after concatenation), resulting in a not-actually-existing divergence getting signaled in the case where the PR title ends or the description starts with whitespace. Expand relevant test, add a utility function to compose a PR message and use it everywhere for coherence. Also update the logging and reporting to show a diff of all the updated items (hidden behind a `details` element).
2023-02-14 19:38:37 +07:00
which might not have been approved.
The properties Message were not correctly synchronized and have been updated.
<details><summary>differences</summary>
```diff
Message:
- wrong
+ title
+ body
+
```
</details>
Note that we are unable to check the properties Merge Method, Overrides, Draft.
Please check and re-approve.
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
"""
[FIX] runbot_merge: sync PR target and message on `check` Previously the mergebot would only sync the head commit, but synching more is useful. Also update the final sanity check on staging: - as with check, update the message & target branch - reset PR state and post a message when updating message instead of doing so silently Note: maybe only fail the staging if the message is updated *and* relevant to staging (aka there's a merge method and it's not `rebase`)? Fixes #680
2023-01-20 21:16:37 +07:00
pr_id.write({
'head': c,
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
'reviewed_by': old_reviewer.id,
[FIX] runbot_merge: sync PR target and message on `check` Previously the mergebot would only sync the head commit, but synching more is useful. Also update the final sanity check on staging: - as with check, update the message & target branch - reset PR state and post a message when updating message instead of doing so silently Note: maybe only fail the staging if the message is updated *and* relevant to staging (aka there's a merge method and it's not `rebase`)? Fixes #680
2023-01-20 21:16:37 +07:00
'message': "Something else",
'target': other.id,
[IMP] runbot_merge: add support for draft check 1cea247e6ce6b8add5bca06634655e43a53024dd missed the update of the `draft` flag, add support for it. Fixes #753
2023-06-08 15:03:26 +07:00
'draft': True,
[FIX] runbot_merge: sync PR target and message on `check` Previously the mergebot would only sync the head commit, but synching more is useful. Also update the final sanity check on staging: - as with check, update the message & target branch - reset PR state and post a message when updating message instead of doing so silently Note: maybe only fail the staging if the message is updated *and* relevant to staging (aka there's a merge method and it's not `rebase`)? Fixes #680
2023-01-20 21:16:37 +07:00
})
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
with repo:
pr.post_comment('hansen check')
env.run_crons()
assert pr_id.state == 'validated'
assert pr_id.head == c2
[FIX] runbot_merge: a few issues with updated staging check 1cea247e6ce6b8add5bca06634655e43a53024dd tried to improve staging checks to avoid staging PRs in the wrong state, however it had two issues: PR state -------- The process would reset the PR's state to open, but unless the head was being resync'd it wouldn't re-apply the statuses on the state, leading to a PR with all-valid statuses, but a missing CI. Message ------- The message check didn't compose the PR message the same way PR creation / update did (it did not trim the title and description individually, only after concatenation), resulting in a not-actually-existing divergence getting signaled in the case where the PR title ends or the description starts with whitespace. Expand relevant test, add a utility function to compose a PR message and use it everywhere for coherence. Also update the logging and reporting to show a diff of all the updated items (hidden behind a `details` element).
2023-02-14 19:38:37 +07:00
assert pr_id.message == 'title\n\nbody' # the commit's message was used for the PR
[FIX] runbot_merge: sync PR target and message on `check` Previously the mergebot would only sync the head commit, but synching more is useful. Also update the final sanity check on staging: - as with check, update the message & target branch - reset PR state and post a message when updating message instead of doing so silently Note: maybe only fail the staging if the message is updated *and* relevant to staging (aka there's a merge method and it's not `rebase`)? Fixes #680
2023-01-20 21:16:37 +07:00
assert pr_id.target.name == 'master'
[IMP] runbot_merge: add support for draft check 1cea247e6ce6b8add5bca06634655e43a53024dd missed the update of the `draft` flag, add support for it. Fixes #753
2023-06-08 15:03:26 +07:00
assert not pr_id.draft
assert pr.comments[-1] == (
users['user'],
f"Updated target, squash, message. Updated {pr_id.display_name} to ready. Updated to {c2}."
)
[FIX] mergebot: improve handling of having missed PR updates 1. if we try to stage a PR and realize we'd stored / checked the wrong head, cancel the staging and notify the PR 2. provide a command to forcefully update pr heads (or at least check that a PR's head is up to date) Closes #241
2019-11-20 20:57:40 +07:00
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
@pytest.mark.defaultstatuses
def test_update_closed(self, env, repo, config):
[ADD] runbot_merge: tests to check behaviour of github in case of updating closed PRs
2020-02-07 22:15:26 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c] = repo.make_commits("master", repo.Commit('first', tree={'m': 'm3'}), ref='heads/abranch')
pr = repo.make_pr(target='master', head=c)
pr.post_comment("hansen r+", config['role_reviewer']['token'])
[ADD] runbot_merge: tests to check behaviour of github in case of updating closed PRs
2020-02-07 22:15:26 +07:00
env.run_crons()
[FIX] runbot_merge: update squash flag on reopen While the head gets updated (properly), the squash flag did not which could lead to odd results. Since a PR can only be reopened if it was regular-pushed to (not after a force push) there are two scenarios: * the PR updated to have 0 commits, closed, pushed to with one commit then reopened, after reopening the PR would be marked as !squash and would ask for a merge method (that's what happened with odoo/odoo#51763) * the PR has a single commit, is closed, pushed to then reopened, after reopening the PR would still be marked a squash and potentially straight rebased without asking for a merge method Nothing would break per-se but both scenarios are undesirable. Close #373
2020-05-28 18:10:55 +07:00
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
pr_id = to_pr(env, pr)
assert pr_id.state == 'approved'
assert pr_id.head == c
assert pr_id.squash
assert pr_id.reviewed_by
[ADD] runbot_merge: tests to check behaviour of github in case of updating closed PRs
2020-02-07 22:15:26 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
pr.close()
[ADD] runbot_merge: tests to check behaviour of github in case of updating closed PRs
2020-02-07 22:15:26 +07:00
assert pr.state == 'closed'
assert pr.head == c
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
assert not pr_id.reviewed_by
assert pr_id.squash
[ADD] runbot_merge: tests to check behaviour of github in case of updating closed PRs
2020-02-07 22:15:26 +07:00
with repo:
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
[c2] = repo.make_commits(c, Commit('xxx', tree={'m': 'm4'}))
repo.update_ref(pr.ref, c2)
repo.post_status(c2, "success")
[FIX] runbot_merge: update squash flag on reopen While the head gets updated (properly), the squash flag did not which could lead to odd results. Since a PR can only be reopened if it was regular-pushed to (not after a force push) there are two scenarios: * the PR updated to have 0 commits, closed, pushed to with one commit then reopened, after reopening the PR would be marked as !squash and would ask for a merge method (that's what happened with odoo/odoo#51763) * the PR has a single commit, is closed, pushed to then reopened, after reopening the PR would still be marked a squash and potentially straight rebased without asking for a merge method Nothing would break per-se but both scenarios are undesirable. Close #373
2020-05-28 18:10:55 +07:00
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
assert pr_id.state == 'closed'
assert pr_id.head == c
assert not pr_id.reviewed_by
assert pr_id.squash
[ADD] runbot_merge: tests to check behaviour of github in case of updating closed PRs
2020-02-07 22:15:26 +07:00
[IMP] *: modernize `TestPRUpdate` - Switch to just `default` ci. - Autouse fixture to init the master branch. - Switch to `make_commits`. - Merge `test_reopen_update` and `test_update_closed_revalidate` into `test_update_closed`: the former did basically nothing useful and the latter could easily be folded into `test_update_closed` by just validating the new commit.
2024-09-19 17:17:59 +07:00
with repo:
pr.open()
assert pr_id.state == 'validated'
assert pr_id.head == c2
assert not pr_id.reviewed_by
assert not pr_id.squash
[ADD] runbot_merge: tests to check behaviour of github in case of updating closed PRs
2020-02-07 22:15:26 +07:00
[CHG] runbot_merge: make merge method non-blocking Because of the false negatives due to github's reordering of events on retargeting, blocking merge methods can be rather frustrating or the user as what's happening and how to solve it isn't clear in that case. Keep the warnings and all, but remove the blocking factor: if a PR doesn't have a merge method and is not single-commit, just skip it on staging. This way, PRs which are actually single-commit will stage fine even if the mergebot thinks they shouldn't be. Fixes #957
2024-10-07 13:07:59 +07:00
@pytest.mark.defaultstatuses
def test_update_incorrect_commits_count(self, port, env, project, repo, config, users):
"""This is not a great test but it aims to kinda sorta simulate the
behaviour when a user retargets and updates a PR at about the same time:
github can send the hooks in the wrong order, which leads to the correct
base and head but can lead to the wrong squash status.
[FIX] runbot_merge: update squash flag on reopen While the head gets updated (properly), the squash flag did not which could lead to odd results. Since a PR can only be reopened if it was regular-pushed to (not after a force push) there are two scenarios: * the PR updated to have 0 commits, closed, pushed to with one commit then reopened, after reopening the PR would be marked as !squash and would ask for a merge method (that's what happened with odoo/odoo#51763) * the PR has a single commit, is closed, pushed to then reopened, after reopening the PR would still be marked a squash and potentially straight rebased without asking for a merge method Nothing would break per-se but both scenarios are undesirable. Close #373
2020-05-28 18:10:55 +07:00
"""
[CHG] runbot_merge: make merge method non-blocking Because of the false negatives due to github's reordering of events on retargeting, blocking merge methods can be rather frustrating or the user as what's happening and how to solve it isn't clear in that case. Keep the warnings and all, but remove the blocking factor: if a PR doesn't have a merge method and is not single-commit, just skip it on staging. This way, PRs which are actually single-commit will stage fine even if the mergebot thinks they shouldn't be. Fixes #957
2024-10-07 13:07:59 +07:00
project.write({
'branch_ids': [(0, 0, {
'name': 'xxx',
})]
})
[FIX] runbot_merge: update squash flag on reopen While the head gets updated (properly), the squash flag did not which could lead to odd results. Since a PR can only be reopened if it was regular-pushed to (not after a force push) there are two scenarios: * the PR updated to have 0 commits, closed, pushed to with one commit then reopened, after reopening the PR would be marked as !squash and would ask for a merge method (that's what happened with odoo/odoo#51763) * the PR has a single commit, is closed, pushed to then reopened, after reopening the PR would still be marked a squash and potentially straight rebased without asking for a merge method Nothing would break per-se but both scenarios are undesirable. Close #373
2020-05-28 18:10:55 +07:00
with repo:
[CHG] runbot_merge: make merge method non-blocking Because of the false negatives due to github's reordering of events on retargeting, blocking merge methods can be rather frustrating or the user as what's happening and how to solve it isn't clear in that case. Keep the warnings and all, but remove the blocking factor: if a PR doesn't have a merge method and is not single-commit, just skip it on staging. This way, PRs which are actually single-commit will stage fine even if the mergebot thinks they shouldn't be. Fixes #957
2024-10-07 13:07:59 +07:00
[c] = repo.make_commits("master", Commit("c", tree={"m": "n"}), ref="heads/thing")
pr = repo.make_pr(target='master', head='thing')
[FIX] runbot_merge: update squash flag on reopen While the head gets updated (properly), the squash flag did not which could lead to odd results. Since a PR can only be reopened if it was regular-pushed to (not after a force push) there are two scenarios: * the PR updated to have 0 commits, closed, pushed to with one commit then reopened, after reopening the PR would be marked as !squash and would ask for a merge method (that's what happened with odoo/odoo#51763) * the PR has a single commit, is closed, pushed to then reopened, after reopening the PR would still be marked a squash and potentially straight rebased without asking for a merge method Nothing would break per-se but both scenarios are undesirable. Close #373
2020-05-28 18:10:55 +07:00
[CHG] runbot_merge: make merge method non-blocking Because of the false negatives due to github's reordering of events on retargeting, blocking merge methods can be rather frustrating or the user as what's happening and how to solve it isn't clear in that case. Keep the warnings and all, but remove the blocking factor: if a PR doesn't have a merge method and is not single-commit, just skip it on staging. This way, PRs which are actually single-commit will stage fine even if the mergebot thinks they shouldn't be. Fixes #957
2024-10-07 13:07:59 +07:00
pr_id = to_pr(env, pr)
pr_id.head = '0'*40
with requests.Session() as s:
r = s.post(
f"http://localhost:{port}/runbot_merge/hooks",
headers={
"X-Github-Event": "pull_request",
},
json={
'action': 'synchronize',
'sender': {
'login': users['user'],
},
'repository': {
'full_name': repo.name,
},
'pull_request': {
'number': pr.number,
'head': {'sha': c},
'title': "c",
'commits': 40123,
'base': {
'ref': 'xxx',
'repo': {
'full_name': repo.name,
},
}
}
}
)
r.raise_for_status()
assert pr_id.head == c, "the head should have been updated"
assert not pr_id.squash, "the wrong count should be used"
[FIX] runbot_merge: update squash flag on reopen While the head gets updated (properly), the squash flag did not which could lead to odd results. Since a PR can only be reopened if it was regular-pushed to (not after a force push) there are two scenarios: * the PR updated to have 0 commits, closed, pushed to with one commit then reopened, after reopening the PR would be marked as !squash and would ask for a merge method (that's what happened with odoo/odoo#51763) * the PR has a single commit, is closed, pushed to then reopened, after reopening the PR would still be marked a squash and potentially straight rebased without asking for a merge method Nothing would break per-se but both scenarios are undesirable. Close #373
2020-05-28 18:10:55 +07:00
[CHG] runbot_merge: make merge method non-blocking Because of the false negatives due to github's reordering of events on retargeting, blocking merge methods can be rather frustrating or the user as what's happening and how to solve it isn't clear in that case. Keep the warnings and all, but remove the blocking factor: if a PR doesn't have a merge method and is not single-commit, just skip it on staging. This way, PRs which are actually single-commit will stage fine even if the mergebot thinks they shouldn't be. Fixes #957
2024-10-07 13:07:59 +07:00
with repo:
pr.post_comment("hansen r+", config['role_reviewer']['token'])
repo.post_status(c, 'success')
[IMP] *: make to_pr more resilient to webhook delays Github delivery delays keep getting worse. Depending on what comes before `to_pr`, this leads it to fail more often as it runs before the PR it's looking for was signaled to the mergebot. In order to mitigate this issue, add a wait loop in `to_pr`, waiting up to 4 seconds for the PR it's looking for before aborting. Also replace manual lookups by `to_pr` in every method of `TestPRUpdate` while at it since it hit a few of the issues. And remove the xfail test case since it seems unlikely github will change tack (maybe? could be worth testing to be sure).
2024-01-16 21:03:45 +07:00
env.run_crons()
[CHG] runbot_merge: make merge method non-blocking Because of the false negatives due to github's reordering of events on retargeting, blocking merge methods can be rather frustrating or the user as what's happening and how to solve it isn't clear in that case. Keep the warnings and all, but remove the blocking factor: if a PR doesn't have a merge method and is not single-commit, just skip it on staging. This way, PRs which are actually single-commit will stage fine even if the mergebot thinks they shouldn't be. Fixes #957
2024-10-07 13:07:59 +07:00
assert not pr_id.blocked
assert pr_id.message_ids[::-1].mapped(lambda m: (
((m.subject or '') + '\n\n' + m.body).strip(),
list(map(read_tracking_value, m.tracking_value_ids)),
)) == [
('<p>Pull Request created</p>', []),
('', [('head', c, '0'*40)]),
('', [('head', '0'*40, c), ('squash', 1, 0)]),
[FIX] runbot_merge: tracked value ordering Apparently in odoo 17.0 tracking values are always ordered by field name.
2024-11-20 18:40:15 +07:00
('', [('reviewed_by', '', 'Reviewer'), ('state', 'Opened', 'Approved')]),
[CHG] runbot_merge: make merge method non-blocking Because of the false negatives due to github's reordering of events on retargeting, blocking merge methods can be rather frustrating or the user as what's happening and how to solve it isn't clear in that case. Keep the warnings and all, but remove the blocking factor: if a PR doesn't have a merge method and is not single-commit, just skip it on staging. This way, PRs which are actually single-commit will stage fine even if the mergebot thinks they shouldn't be. Fixes #957
2024-10-07 13:07:59 +07:00
(f'<p>statuses changed on {c}</p>', [('state', 'Approved', 'Ready')]),
]
assert pr_id.staging_id
with repo:
repo.post_status('staging.master', 'success')
env.run_crons()
assert pr_id.merge_date
[ADD] runbot_merge: tests to check behaviour of github in case of updating closed PRs
2020-02-07 22:15:26 +07:00
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
class TestBatching(object):
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def _pr(self, repo, prefix, trees, *, target='master', user, reviewer,
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
statuses=(('ci/runbot', 'success'), ('legal/cla', 'success'))
):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
""" Helper creating a PR from a series of commits on a base
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
*_, c = repo.make_commits(
'heads/{}'.format(target),
*(
repo.Commit('commit_{}_{:02}'.format(prefix, i), tree=t)
for i, t in enumerate(trees)
),
ref='heads/{}'.format(prefix)
)
pr = repo.make_pr(title='title {}'.format(prefix), body='body {}'.format(prefix),
target=target, head=prefix, token=user)
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
for context, result in statuses:
repo.post_status(c, result, context)
if reviewer:
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
pr.post_comment(
'hansen r+%s' % (' rebase-merge' if len(trees) > 1 else ''),
reviewer
)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
return pr
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_staging_batch(self, env, repo, users, config):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
""" If multiple PRs are ready for the same target at the same point,
they should be staged together
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'a': 'some content'})
repo.make_ref('heads/master', m)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
pr1 = self._pr(repo, 'PR1', [{'a': 'AAA'}, {'b': 'BBB'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
pr2 = self._pr(repo, 'PR2', [{'c': 'CCC'}, {'d': 'DDD'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
pr1 = to_pr(env, pr1)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr1.staging_id
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
pr2 = to_pr(env, pr2)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr1.staging_id
assert pr2.staging_id
assert pr1.staging_id == pr2.staging_id
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
log = list(repo.log('heads/staging.master'))
staging = log_to_node(log)
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
reviewer = get_partner(env, users["reviewer"]).formatted_email
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
p1 = node(
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
'title PR1\n\nbody PR1\n\ncloses {}\n\nSigned-off-by: {}'.format(pr1.display_name, reviewer),
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
node('initial'),
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
node(part_of('commit_PR1_01', pr1), node(part_of('commit_PR1_00', pr1), node('initial')))
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
)
p2 = node(
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
'title PR2\n\nbody PR2\n\ncloses {}\n\nSigned-off-by: {}'.format(pr2.display_name, reviewer),
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
p1,
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
node(part_of('commit_PR2_01', pr2), node(part_of('commit_PR2_00', pr2), p1))
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
)
[IMP] runbot_merge: remove unnecessary uniquifier dummy commits "Uniquifier" commits were introduced to ensure branches of a staging on which nothing had been staged would still be rebuilt properly. This means technically the branches on which something had been staged never *needed* a uniquifier, strictly speaking. And those lead to extra building, because once the actually staged PRs get pushed from staging to their final destination it's an unknown commit to the runbot, which needs to rebuild it instead of being able to just use the staging it already has. Thus only add the uniquifier where it *might* be necessary: technically the runbot should not manage this use case much better, however there are still issues like an ancillary build working with the same branch tip (e.g. the "current master") and sending a failure result which would fail the entire staging. The uniquifier guards against this issue. Also update rebase semantics to always update the *commit date* of the rebased commits: this ensures the tip commit is always "recent" in the case of a rebase-ff (which is common as that's what single-commit PRs do), as the runbot may skip commits it considers "old". Also update some of the utility methods around repos / commits to be simpler, and avoid assuming the result is JSON-decodable (sometimes it is not). Also update the handling of commit statuses using postgres' ON CONFLICT and jsonb support, hopefully this improves (or even fixes) the serialization errors. Should be compatible with 9.5 onwards which is *ancient* at this point. Fixes #509
2021-08-09 18:21:24 +07:00
assert staging == p2
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_staging_batch_norebase(self, env, repo, users, config):
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
""" If multiple PRs are ready for the same target at the same point,
they should be staged together
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'a': 'some content'})
repo.make_ref('heads/master', m)
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
pr1 = self._pr(repo, 'PR1', [{'a': 'AAA'}, {'b': 'BBB'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
pr1.post_comment('hansen merge', config['role_reviewer']['token'])
pr2 = self._pr(repo, 'PR2', [{'c': 'CCC'}, {'d': 'DDD'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
pr2.post_comment('hansen merge', config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
pr1 = to_pr(env, pr1)
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
assert pr1.staging_id
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
assert pr1.merge_method == 'merge'
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
pr2 = to_pr(env, pr2)
[ADD] runbot_merge: better integration controls Closes #48
2018-11-26 16:28:13 +07:00
assert pr2.merge_method == 'merge'
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
assert pr1.staging_id
assert pr2.staging_id
assert pr1.staging_id == pr2.staging_id
[IMP] runbot_merge: remove unnecessary uniquifier dummy commits "Uniquifier" commits were introduced to ensure branches of a staging on which nothing had been staged would still be rebuilt properly. This means technically the branches on which something had been staged never *needed* a uniquifier, strictly speaking. And those lead to extra building, because once the actually staged PRs get pushed from staging to their final destination it's an unknown commit to the runbot, which needs to rebuild it instead of being able to just use the staging it already has. Thus only add the uniquifier where it *might* be necessary: technically the runbot should not manage this use case much better, however there are still issues like an ancillary build working with the same branch tip (e.g. the "current master") and sending a failure result which would fail the entire staging. The uniquifier guards against this issue. Also update rebase semantics to always update the *commit date* of the rebased commits: this ensures the tip commit is always "recent" in the case of a rebase-ff (which is common as that's what single-commit PRs do), as the runbot may skip commits it considers "old". Also update some of the utility methods around repos / commits to be simpler, and avoid assuming the result is JSON-decodable (sometimes it is not). Also update the handling of commit statuses using postgres' ON CONFLICT and jsonb support, hopefully this improves (or even fixes) the serialization errors. Should be compatible with 9.5 onwards which is *ancient* at this point. Fixes #509
2021-08-09 18:21:24 +07:00
log = list(repo.log('staging.master'))
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
staging = log_to_node(log)
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
reviewer = get_partner(env, users["reviewer"]).formatted_email
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
p1 = node(
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
'title PR1\n\nbody PR1\n\ncloses {}#{}\n\nSigned-off-by: {}'.format(repo.name, pr1.number, reviewer),
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
node('initial'),
node('commit_PR1_01', node('commit_PR1_00', node('initial')))
)
p2 = node(
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
'title PR2\n\nbody PR2\n\ncloses {}#{}\n\nSigned-off-by: {}'.format(repo.name, pr2.number, reviewer),
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
p1,
node('commit_PR2_01', node('commit_PR2_00', node('initial')))
)
[IMP] runbot_merge: remove unnecessary uniquifier dummy commits "Uniquifier" commits were introduced to ensure branches of a staging on which nothing had been staged would still be rebuilt properly. This means technically the branches on which something had been staged never *needed* a uniquifier, strictly speaking. And those lead to extra building, because once the actually staged PRs get pushed from staging to their final destination it's an unknown commit to the runbot, which needs to rebuild it instead of being able to just use the staging it already has. Thus only add the uniquifier where it *might* be necessary: technically the runbot should not manage this use case much better, however there are still issues like an ancillary build working with the same branch tip (e.g. the "current master") and sending a failure result which would fail the entire staging. The uniquifier guards against this issue. Also update rebase semantics to always update the *commit date* of the rebased commits: this ensures the tip commit is always "recent" in the case of a rebase-ff (which is common as that's what single-commit PRs do), as the runbot may skip commits it considers "old". Also update some of the utility methods around repos / commits to be simpler, and avoid assuming the result is JSON-decodable (sometimes it is not). Also update the handling of commit statuses using postgres' ON CONFLICT and jsonb support, hopefully this improves (or even fixes) the serialization errors. Should be compatible with 9.5 onwards which is *ancient* at this point. Fixes #509
2021-08-09 18:21:24 +07:00
assert staging == p2
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_staging_batch_squash(self, env, repo, users, config):
[ADD] runbot_merge: test for previous commit 2b1cd83b075a99da7ed905b9e62d7e5acb48b253 fixed a bug in PR squashing (introduced when it was mis-rebuilt on top of rebase) which was immediately committed & pushed so we could fix the running mergebot. This adds a test for that issue, it was checked to fail for 2b1cd83b075a99da7ed905b9e62d7e5acb48b253~1 and work as of the current head. Turns out the previous tests checked all the new/complex features to see if they worked correctly, but I completely forgot that the previously working squash had been rebuild.
2018-09-20 15:52:58 +07:00
""" If multiple PRs are ready for the same target at the same point,
they should be staged together
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'a': 'some content'})
repo.make_ref('heads/master', m)
[ADD] runbot_merge: test for previous commit 2b1cd83b075a99da7ed905b9e62d7e5acb48b253 fixed a bug in PR squashing (introduced when it was mis-rebuilt on top of rebase) which was immediately committed & pushed so we could fix the running mergebot. This adds a test for that issue, it was checked to fail for 2b1cd83b075a99da7ed905b9e62d7e5acb48b253~1 and work as of the current head. Turns out the previous tests checked all the new/complex features to see if they worked correctly, but I completely forgot that the previously working squash had been rebuild.
2018-09-20 15:52:58 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
pr1 = self._pr(repo, 'PR1', [{'a': 'AAA'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
pr2 = self._pr(repo, 'PR2', [{'c': 'CCC'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: test for previous commit 2b1cd83b075a99da7ed905b9e62d7e5acb48b253 fixed a bug in PR squashing (introduced when it was mis-rebuilt on top of rebase) which was immediately committed & pushed so we could fix the running mergebot. This adds a test for that issue, it was checked to fail for 2b1cd83b075a99da7ed905b9e62d7e5acb48b253~1 and work as of the current head. Turns out the previous tests checked all the new/complex features to see if they worked correctly, but I completely forgot that the previously working squash had been rebuild.
2018-09-20 15:52:58 +07:00
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
pr1 = to_pr(env, pr1)
[ADD] runbot_merge: test for previous commit 2b1cd83b075a99da7ed905b9e62d7e5acb48b253 fixed a bug in PR squashing (introduced when it was mis-rebuilt on top of rebase) which was immediately committed & pushed so we could fix the running mergebot. This adds a test for that issue, it was checked to fail for 2b1cd83b075a99da7ed905b9e62d7e5acb48b253~1 and work as of the current head. Turns out the previous tests checked all the new/complex features to see if they worked correctly, but I completely forgot that the previously working squash had been rebuild.
2018-09-20 15:52:58 +07:00
assert pr1.staging_id
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
pr2 = to_pr(env, pr2)
[ADD] runbot_merge: test for previous commit 2b1cd83b075a99da7ed905b9e62d7e5acb48b253 fixed a bug in PR squashing (introduced when it was mis-rebuilt on top of rebase) which was immediately committed & pushed so we could fix the running mergebot. This adds a test for that issue, it was checked to fail for 2b1cd83b075a99da7ed905b9e62d7e5acb48b253~1 and work as of the current head. Turns out the previous tests checked all the new/complex features to see if they worked correctly, but I completely forgot that the previously working squash had been rebuild.
2018-09-20 15:52:58 +07:00
assert pr1.staging_id
assert pr2.staging_id
assert pr1.staging_id == pr2.staging_id
log = list(repo.log('heads/staging.master'))
staging = log_to_node(log)
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
reviewer = get_partner(env, users["reviewer"]).formatted_email
[IMP] runbot_merge: remove unnecessary uniquifier dummy commits "Uniquifier" commits were introduced to ensure branches of a staging on which nothing had been staged would still be rebuilt properly. This means technically the branches on which something had been staged never *needed* a uniquifier, strictly speaking. And those lead to extra building, because once the actually staged PRs get pushed from staging to their final destination it's an unknown commit to the runbot, which needs to rebuild it instead of being able to just use the staging it already has. Thus only add the uniquifier where it *might* be necessary: technically the runbot should not manage this use case much better, however there are still issues like an ancillary build working with the same branch tip (e.g. the "current master") and sending a failure result which would fail the entire staging. The uniquifier guards against this issue. Also update rebase semantics to always update the *commit date* of the rebased commits: this ensures the tip commit is always "recent" in the case of a rebase-ff (which is common as that's what single-commit PRs do), as the runbot may skip commits it considers "old". Also update some of the utility methods around repos / commits to be simpler, and avoid assuming the result is JSON-decodable (sometimes it is not). Also update the handling of commit statuses using postgres' ON CONFLICT and jsonb support, hopefully this improves (or even fixes) the serialization errors. Should be compatible with 9.5 onwards which is *ancient* at this point. Fixes #509
2021-08-09 18:21:24 +07:00
expected = node('commit_PR2_00\n\ncloses {}#{}\n\nSigned-off-by: {}'.format(repo.name, pr2.number, reviewer),
node('commit_PR1_00\n\ncloses {}#{}\n\nSigned-off-by: {}'.format(repo.name, pr1.number, reviewer),
node('initial')))
[ADD] runbot_merge: test for previous commit 2b1cd83b075a99da7ed905b9e62d7e5acb48b253 fixed a bug in PR squashing (introduced when it was mis-rebuilt on top of rebase) which was immediately committed & pushed so we could fix the running mergebot. This adds a test for that issue, it was checked to fail for 2b1cd83b075a99da7ed905b9e62d7e5acb48b253~1 and work as of the current head. Turns out the previous tests checked all the new/complex features to see if they worked correctly, but I completely forgot that the previously working squash had been rebuild.
2018-09-20 15:52:58 +07:00
assert staging == expected
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_batching_pressing(self, env, repo, config):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
""" "Pressing" PRs should be selected before normal & batched together
"""
[ADD] *: per-repository webhook secret Currently webhook secrets are configured per *project* which is an issue both because different repositories may have different administrators and thus creates safety concerns, and because multiple repositories can feed into different projects (e.g. on mergebot, odoo-dev/odoo is both an ancillary repository to the main RD project, and the main repository to the minor / legacy master-wowl project). This means it can be necessary to have multiple projects share the same secret as well, this then mandates the secret for more repositories per (1). This is a pain in the ass, so just detach secrets from projects and link them *only* to repositories, it's cleaner and easier to manage and set up progressively. This requires a lot of changes to the tests, as they all need to correctly configure the signaling. For `runbot_merge` there was *some* setup sharing already via the module-level `repo` fixtures`, those were merged into a conftest-level fixture which could handle the signaling setup. A few tests which unnecessarily set up repositories ad-hoc were also moved to the fixture. But for most of the ad-hoc setup in `runbot_merge`, as well as `forwardport` where it's all ad-hoc, events sources setup was just appended as is. This should probably be cleaned up at one point, with the various requirements collected and organised into a small set of fixtures doing the job more uniformly. Fixes #887
2024-06-06 16:07:57 +07:00
# by limiting the batch size to 3 we allow both high-priority PRs, but
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
# a single normal priority one
env['runbot_merge.project'].search([]).batch_limit = 3
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'a': 'some content'})
repo.make_ref('heads/master', m)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
pr21 = self._pr(repo, 'PR1', [{'a': 'AAA'}, {'b': 'BBB'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
pr22 = self._pr(repo, 'PR2', [{'c': 'CCC'}, {'d': 'DDD'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
pr11 = self._pr(repo, 'Pressing1', [{'x': 'x'}, {'y': 'y'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
pr12 = self._pr(repo, 'Pressing2', [{'z': 'z'}, {'zz': 'zz'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
pr11.post_comment('hansen priority', config['role_reviewer']['token'])
pr12.post_comment('hansen priority', config['role_reviewer']['token'])
# necessary to project commit statuses onto PRs
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
pr21, pr22, pr11, pr12 = prs = [to_pr(env, pr) for pr in [pr21, pr22, pr11, pr12]]
assert pr11.priority == pr12.priority == 'priority'
assert pr21.priority == pr22.priority == 'default'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert all(pr.state == 'ready' for pr in prs)
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
staging = ensure_one(env['runbot_merge.stagings'].search([]))
assert staging.pr_ids == pr11 | pr12 | pr21
[IMP] runbot_merge: preserve batch ordering in stagings Batch ordering in stagings is important in order to correctly reconstitute the full project history. In the old mergebot, since batches are created on the fly during staging this information is reified by the batch ids. But since batch ids are now persistent and there is no relationship between the creation of a batch and its merging (especially not relative to other batches) it's an issue as reconstituting sub-staging git history would be impossible. Which is not the worst, but is not great. The solution is to reify the join table between stagings and batches in order for *that* to keep history (simply via the sequential PK), and in converting to the new system carefully generate the new links in an order matching the old batch ids.
2024-05-17 15:51:16 +07:00
assert list(staging.batch_ids) == [
pr11.batch_id,
pr12.batch_id,
pr21.batch_id,
]
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert not pr22.staging_id
[ADD] runbot_merge: help command, and help on error Fixes #898
2024-06-25 03:16:43 +07:00
@pytest.mark.usefixtures("reviewer_admin")
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_batching_urgent(self, env, repo, config):
with repo:
m = repo.make_commit(None, 'initial', None, tree={'a': 'some content'})
repo.make_ref('heads/master', m)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
pr11 = self._pr(repo, 'Pressing1', [{'x': 'x'}, {'y': 'y'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
pr12 = self._pr(repo, 'Pressing2', [{'z': 'z'}, {'zz': 'zz'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
pr11.post_comment('hansen NOW', config['role_reviewer']['token'])
pr12.post_comment('hansen NOW', config['role_reviewer']['token'])
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
# stage current PRs
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
p_11, p_12 = \
[to_pr(env, pr) for pr in [pr11, pr12]]
sm_all = p_11 | p_12
staging_1 = sm_all.staging_id
assert staging_1
assert len(staging_1) == 1
[IMP] runbot_merge: preserve batch ordering in stagings Batch ordering in stagings is important in order to correctly reconstitute the full project history. In the old mergebot, since batches are created on the fly during staging this information is reified by the batch ids. But since batch ids are now persistent and there is no relationship between the creation of a batch and its merging (especially not relative to other batches) it's an issue as reconstituting sub-staging git history would be impossible. Which is not the worst, but is not great. The solution is to reify the join table between stagings and batches in order for *that* to keep history (simply via the sequential PK), and in converting to the new system carefully generate the new links in an order matching the old batch ids.
2024-05-17 15:51:16 +07:00
assert list(staging_1.batch_ids) == [
p_11.batch_id,
p_12.batch_id,
]
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
# no statuses run on PR0s
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
pr01 = self._pr(repo, 'Urgent1', [{'n': 'n'}, {'o': 'o'}], user=config['role_user']['token'], reviewer=None, statuses=[])
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
pr01.post_comment('hansen NOW! rebase-merge', config['role_reviewer']['token'])
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
p_01 = to_pr(env, pr01)
[IMP] runbot_merge: make skipchecks impact PR state It's a bit weird and inconsistent to have a PR being staged while unreviewed or unapproved or w/e. If we compute the state based on skipchecks then everything is consistent. Also remove the implicit override of all statuses when explicitly marking the pr as `ready`, it risks creating difficult to understand states, and it's unnecessary since `skipchecks` gets set. Also as with setting skipchecks, sets the current user as reviewer on all PRs of the batch without a reviewer.
2024-05-24 13:36:19 +07:00
assert p_01.state == 'ready'
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
assert p_01.priority == 'alone'
assert p_01.skipchecks == True
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
# first staging should be cancelled and PR0 should be staged
# regardless of CI (or lack thereof)
[IMP] runbot_merge: stop deleting batches & stagings If we want a dashboard with a history of stagings, maybe not deleting them would be a good idea. A replacement for the headless stagings would probably be a good idea: currently they're created when splitting a failed staging containing more than one batch, but their only purpose is as splits of existing batches to be deactivated/deleted to be re-staged (new batches & stagings are created then as e.g. some of the batches may not be merge-able anymore) and that's a bit weird.
2018-06-18 17:59:57 +07:00
assert not staging_1.active
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
assert not p_11.staging_id and not p_12.staging_id
assert p_01.staging_id
[CHG] runbot_merge: move priority field from PR to batch Simplifies the `ready_prs` query a bit and allows it to be converted to an ORM search, by moving the priority check outside. This also allows the caller to not need to post-process the records list anywhere near the previous state of affairs. `ready_prs` now returns *either* the "alone" batches, or the non-alone batches, rather than mixing both into a single sequence. This requires correctly applying the search filters to not retrieve priority of batches in error or targeting other branches.
2024-02-07 21:05:33 +07:00
assert p_11.state == 'ready'
assert p_12.state == 'ready'
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
# make the staging fail
with repo:
repo.post_status('staging.master', 'failure', 'ci/runbot')
env.run_crons()
[CHG] runbot_merge: move priority field from PR to batch Simplifies the `ready_prs` query a bit and allows it to be converted to an ORM search, by moving the priority check outside. This also allows the caller to not need to post-process the records list anywhere near the previous state of affairs. `ready_prs` now returns *either* the "alone" batches, or the non-alone batches, rather than mixing both into a single sequence. This requires correctly applying the search filters to not retrieve priority of batches in error or targeting other branches.
2024-02-07 21:05:33 +07:00
assert p_01.error
assert p_01.batch_id.blocked
assert p_01.blocked
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
assert p_01.state == 'error'
assert not p_01.staging_id.active
staging_2 = ensure_one(sm_all.staging_id)
assert staging_2 != staging_1
with repo:
pr01.post_comment('hansen retry', config['role_reviewer']['token'])
env.run_crons()
# retry should have re-triggered cancel-staging
assert not staging_2.active
assert p_01.staging_id.active
# make the staging fail again
with repo:
repo.post_status('staging.master', 'failure', 'ci/runbot')
env.run_crons()
assert not p_01.staging_id.active
assert p_01.state == 'error'
staging_3 = ensure_one(sm_all.staging_id)
assert staging_3 != staging_2
# check that updating the PR resets it to ~ready
with repo:
repo.make_commits(
'heads/master',
Commit("urgent+", tree={'y': 'es'}),
ref="heads/Urgent1",
)
env.run_crons()
assert not staging_3.active
[IMP] runbot_merge: make skipchecks impact PR state It's a bit weird and inconsistent to have a PR being staged while unreviewed or unapproved or w/e. If we compute the state based on skipchecks then everything is consistent. Also remove the implicit override of all statuses when explicitly marking the pr as `ready`, it risks creating difficult to understand states, and it's unnecessary since `skipchecks` gets set. Also as with setting skipchecks, sets the current user as reviewer on all PRs of the batch without a reviewer.
2024-05-24 13:36:19 +07:00
assert p_01.state == 'ready'
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
assert p_01.priority == 'alone'
assert p_01.skipchecks == True
assert p_01.staging_id.active
# r- should unstage, re-enable the checks and switch off staging
# cancellation, but leave the priority
with repo:
pr01.post_comment("hansen r-", config['role_reviewer']['token'])
env.run_crons()
staging_4 = ensure_one(sm_all.staging_id)
assert staging_4 != staging_3
assert not p_01.staging_id.active
assert p_01.state == 'opened'
assert p_01.priority == 'alone'
assert p_01.skipchecks == False
[CHG] runbot_merge: don't reset cancel_staging on r- Also send skipchecks removal to the PR being r-'d, as sending it to a random PR of the batch doesn't really make sense?
2024-02-12 14:46:44 +07:00
assert p_01.cancel_staging == True
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
[CHG] runbot_merge: don't reset cancel_staging on r- Also send skipchecks removal to the PR being r-'d, as sending it to a random PR of the batch doesn't really make sense?
2024-02-12 14:46:44 +07:00
assert staging_4.active, "staging should not be disabled"
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
# cause the PR to become ready the normal way
with repo:
pr01.post_comment("hansen r+", config['role_reviewer']['token'])
repo.post_status(p_01.head, 'success', 'legal/cla')
repo.post_status(p_01.head, 'success', 'ci/runbot')
env.run_crons()
# a cancel_staging pr becoming ready should have cancelled the staging,
# and because the PR is `alone` it should... have been restaged alone,
# without the ready non-alone PRs
assert not sm_all.staging_id.active
assert p_01.staging_id.active
assert p_01.state == 'ready'
assert p_01.priority == 'alone'
assert p_01.skipchecks == False
assert p_01.cancel_staging == True
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
[ADD] runbot_merge: help command, and help on error Fixes #898
2024-06-25 03:16:43 +07:00
@pytest.mark.usefixtures("reviewer_admin")
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_batching_urgenter_than_split(self, env, repo, config):
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
""" p=alone PRs should take priority over split stagings (processing
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
of a staging having CI-failed and being split into sub-stagings)
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'a': 'some content'})
repo.make_ref('heads/master', m)
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
pr1 = self._pr(repo, 'PR1', [{'a': 'AAA'}, {'b': 'BBB'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
pr2 = self._pr(repo, 'PR2', [{'a': 'some content', 'c': 'CCC'}, {'d': 'DDD'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] runbot_merge: reorg test Test seems to fail from time to time with one of the PRs getting lost. Tried to move code around trying to investigate, can't repro anymore. Possibly a race condition because the `to_pr` call was performed too early, before the webhook had run (and thus before the PR object had been created on the odoo side). By moving the `to_pr` calls to after the cron run, we really ensure the webhooks will have run. Also update `to_pr` to ensure exactly one PR was retrieved, as currently nothing is checked so we might have gotten none (yet), which should be noticed early and clearly. In theory this also guards against multiple PRs, but PRs should be unique on (repo, number).
2022-08-05 18:59:39 +07:00
p_1 = to_pr(env, pr1)
p_2 = to_pr(env, pr2)
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
st = env['runbot_merge.stagings'].search([])
[IMP] runbot_merge: reorg test Test seems to fail from time to time with one of the PRs getting lost. Tried to move code around trying to investigate, can't repro anymore. Possibly a race condition because the `to_pr` call was performed too early, before the webhook had run (and thus before the PR object had been created on the odoo side). By moving the `to_pr` calls to after the cron run, we really ensure the webhooks will have run. Also update `to_pr` to ensure exactly one PR was retrieved, as currently nothing is checked so we might have gotten none (yet), which should be noticed early and clearly. In theory this also guards against multiple PRs, but PRs should be unique on (repo, number).
2022-08-05 18:59:39 +07:00
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
# both prs should be part of the staging
assert st.mapped('batch_ids.prs') == p_1 | p_2
[IMP] runbot_merge: reorg test Test seems to fail from time to time with one of the PRs getting lost. Tried to move code around trying to investigate, can't repro anymore. Possibly a race condition because the `to_pr` call was performed too early, before the webhook had run (and thus before the PR object had been created on the odoo side). By moving the `to_pr` calls to after the cron run, we really ensure the webhooks will have run. Also update `to_pr` to ensure exactly one PR was retrieved, as currently nothing is checked so we might have gotten none (yet), which should be noticed early and clearly. In theory this also guards against multiple PRs, but PRs should be unique on (repo, number).
2022-08-05 18:59:39 +07:00
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
# add CI failure
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status('heads/staging.master', 'failure', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
env.run_crons()
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
# should have staged the first half
assert p_1.staging_id.heads
assert not p_2.staging_id.heads
# during restaging of pr1, create urgent PR
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
pr0 = self._pr(repo, 'urgent', [{'a': 'a', 'b': 'b'}], user=config['role_user']['token'], reviewer=None, statuses=[])
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
pr0.post_comment('hansen NOW!', config['role_reviewer']['token'])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
assert not p_1.staging_id
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
assert to_pr(env, pr0).staging_id
[IMP] runbot_merge: prioritize p0 more * p0 cancel existing stagings in order to be staged as soon as possible * p0 PRs should be picked over split batches * p0 bypass PR-level CI and review requirements * p0 can be set on any of a batch's PR, matched PRs will be staged alongside even if their priority is the default
2018-03-27 18:33:04 +07:00
[ADD] runbot_merge: help command, and help on error Fixes #898
2024-06-25 03:16:43 +07:00
@pytest.mark.usefixtures("reviewer_admin")
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_urgent_failed(self, env, repo, config):
[FIX] runbot_merge: don't try to stage urgent PRs in error
2018-04-03 21:28:45 +07:00
""" Ensure pr[p=0,state=failed] don't get picked up
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'a': 'some content'})
repo.make_ref('heads/master', m)
[FIX] runbot_merge: don't try to stage urgent PRs in error
2018-04-03 21:28:45 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
pr21 = self._pr(repo, 'PR1', [{'a': 'AAA'}, {'b': 'BBB'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
[FIX] runbot_merge: don't try to stage urgent PRs in error
2018-04-03 21:28:45 +07:00
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
p_21 = to_pr(env, pr21)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[FIX] runbot_merge: don't try to stage urgent PRs in error
2018-04-03 21:28:45 +07:00
# no statuses run on PR0s
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
pr01 = self._pr(repo, 'Urgent1', [{'n': 'n'}, {'o': 'o'}], user=config['role_user']['token'], reviewer=None, statuses=[])
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
pr01.post_comment('hansen NOW!', config['role_reviewer']['token'])
[IMP] *: tag all rebased commits with source PRev Although it's possible to find what PR a commit was part of with a bit of `git log` magic (e.g. `--ancestry-path COMMIT.. --reverse`) it's not the most convenient, and many people don't know about it, leading them to various debatable decisions to try and mitigate the issue, such as tagging every commit in a PR with the PR's identity, which then leads github to spam the PR itself with pingbacks from its own commits. Which is great. Add this information to the commits when rebasing them (and *only* when rebasing them), using a `Part-of:` pseudo-header. Fixes #482
2021-08-09 12:55:38 +07:00
p_01 = to_pr(env, pr01)
[FIX] runbot_merge: leftover direct setting of PR state Setting the PR state directly really doesn't work as it doesn't correctly save (and can get overwritten by any dependency of which there are many). This caused setting odoo/odoo#165777 in error to fail, leading to it being re-staged (and failing) repeatedly, and the PR being spammed with comments. - create a more formal helper for preventing directly setting computed functions (without an actual inverse) - replace direct state setting by setting the corresponding dependency e.g. `error` for error and `skipchecks` to force a PR to ready - add a `skipchecks` inverse to the PR so it can also set itself as reviewed, and is convenient, might be worth also adding stuff to `Batch.write`
2024-06-11 20:31:35 +07:00
p_01.error = True
[FIX] runbot_merge: don't try to stage urgent PRs in error
2018-04-03 21:28:45 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[FIX] runbot_merge: don't try to stage urgent PRs in error
2018-04-03 21:28:45 +07:00
assert not p_01.staging_id, "p_01 should not be picked up as it's failed"
assert p_21.staging_id, "p_21 should have been staged"
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] runbot_merge: fix dual merge of split prioritised PRs Because `alone` (formerly p != 2) is selected before split PRs, if a prioritised PR gets split (or a split PR gets prioritised) it will be staged once as prioritised, and again because split. Improve the selection of ready batches to exclude split batches upstream, such that they don't have to be rechecked over and over, and their priorities don't cause us issues.
2024-02-08 18:02:34 +07:00
def test_urgent_split(self, env, repo, config):
"""Ensure that urgent (alone) PRs which get split don't get
double-merged
"""
with repo:
repo.make_commits(
None,
Commit("initial", tree={'a': '1'}),
ref="heads/master"
)
pr01 = self._pr(
repo, "PR1", [{'b': '1'}],
user=config['role_user']['token'],
reviewer=None,
)
pr01.post_comment('hansen alone r+', config['role_reviewer']['token'])
pr02 = self._pr(
repo, "PR2", [{'c': '1'}],
user=config['role_user']['token'],
reviewer=None,
)
pr02.post_comment('hansen alone r+', config['role_reviewer']['token'])
[IMP] *: rely only on triggers to run statuses propagation The cron had been converted to using mostly triggers in 7cd9afe7f2ff2cbaaabe0ecf6eb364b55aaf8d60 but I forgot to update the *tests* to avoid explicitly triggering it.
2024-07-30 18:42:00 +07:00
env.run_crons(None)
[IMP] runbot_merge: fix dual merge of split prioritised PRs Because `alone` (formerly p != 2) is selected before split PRs, if a prioritised PR gets split (or a split PR gets prioritised) it will be staged once as prioritised, and again because split. Improve the selection of ready batches to exclude split batches upstream, such that they don't have to be rechecked over and over, and their priorities don't cause us issues.
2024-02-08 18:02:34 +07:00
pr01_id = to_pr(env, pr01)
assert pr01_id.blocked is False
pr02_id = to_pr(env, pr02)
assert pr01_id.blocked is False
env.run_crons()
st = pr01_id.staging_id
assert st and pr02_id.staging_id == st
with repo:
repo.post_status('staging.master', 'failure', 'ci/runbot')
env.run_crons()
# should have cancelled the staging, split it, and re-staged the first
# half of the split
assert st.state == 'failure'
assert pr01_id.staging_id and pr01_id.staging_id != st
assert not pr02_id.staging_id
split_prs = env['runbot_merge.split'].search([]).batch_ids.prs
assert split_prs == pr02_id, \
f"only the unstaged PR {pr02_id} should be in a split, found {split_prs}"
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
@pytest.mark.skip(reason="Maybe nothing to do, the PR is just skipped and put in error?")
[IMP] runbot_merge: logins -> user roles Can't really assume we can get the github logins "user" or "reviewer" to run the test suite remotely, so add an indirection and backronym those to *roles* instead. The local test suite has identical roles & logins, but the remote version does not. Also use the "other" role for any random user, and don't create its partner up-front. Also renamed the self-reviewer user to self_reviewer, that's a bit less weird when dealing with e.g. ini files.
2018-06-07 19:53:31 +07:00
def test_batching_merge_failure(self):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
pass
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_staging_ci_failure_batch(self, env, repo, config):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
""" on failure split batch & requeue
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'a': 'some content'})
repo.make_ref('heads/master', m)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
pr1 = self._pr(repo, 'PR1', [{'a': 'AAA'}, {'b': 'BBB'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
pr2 = self._pr(repo, 'PR2', [{'a': 'some content', 'c': 'CCC'}, {'d': 'DDD'}], user=config['role_user']['token'], reviewer=config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
st = env['runbot_merge.stagings'].search([])
# both prs should be part of the staging
assert len(st.mapped('batch_ids.prs')) == 2
# add CI failure
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status('heads/staging.master', 'failure', 'ci/runbot')
repo.post_status('heads/staging.master', 'success', 'legal/cla')
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr1 = to_pr(env, pr1)
pr2 = to_pr(env, pr2)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] runbot_merge: don't create unstaged stagings Previously when splitting staging we'd create two never-staged stagings. In a system where the stagings get deleted once done with (succeeeded or failed) that's not really important, but now that we want to keep stagings around inactive things get problematic as this method gunks up the stagings table, plus the post-split stagings would "steal" the original's batches, losing information (relation between stagings and batches). Replace these empty stagings with dedicated *split* objects. A batch can belong to both a staging and a split, the split is deleted once a new staging has been created from it. Eventually we may want to make batches shared between stagings (so we can track the entire history of a batch) but currently that's only PR-level.
2018-06-18 20:23:23 +07:00
# should have split the existing batch into two, with one of the
# splits having been immediately restaged
st = env['runbot_merge.stagings'].search([])
assert len(st) == 1
assert pr1.staging_id and pr1.staging_id == st
sp = env['runbot_merge.split'].search([])
assert len(sp) == 1
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
# This is the failing PR!
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
repo.post_status('staging.master', 'failure', 'ci/runbot')
repo.post_status('staging.master', 'success', 'legal/cla')
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr1.state == 'error'
[IMP] runbot_merge: don't create unstaged stagings Previously when splitting staging we'd create two never-staged stagings. In a system where the stagings get deleted once done with (succeeeded or failed) that's not really important, but now that we want to keep stagings around inactive things get problematic as this method gunks up the stagings table, plus the post-split stagings would "steal" the original's batches, losing information (relation between stagings and batches). Replace these empty stagings with dedicated *split* objects. A batch can belong to both a staging and a split, the split is deleted once a new staging has been created from it. Eventually we may want to make batches shared between stagings (so we can track the entire history of a batch) but currently that's only PR-level.
2018-06-18 20:23:23 +07:00
assert pr2.staging_id
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[ADD] runbot_merge: support for non-webhook staging validation Add support for the ability to validate *stagings* over RPC rather than via webhook. This may later be expanded to PRs as well. The core motivation for this is to avoid bouncing through github which sometimes drops the ball on statuses, and it's frustrating to have a staging time out because GH fucked up. Implemented via RPC, requiring both the staging itself (by id) and the head commit being affected, as that is necessary to know what CIs are required for that head and correctly report cross branch on the various PRs. Fix #881 (kinda)
2024-06-03 17:59:24 +07:00
repo.post_status('staging.master', 'success', 'ci/runbot')
repo.post_status('staging.master', 'success', 'legal/cla')
[IMP] *: trigger-ify staging cron The staging cron turns out to be pretty reasonable to trigger, as we already have a handler on the transition of a batch to `not blocked`, which is exactly when we want to create a staging (that and the completion of the previous staging). The batch transition is in a compute which is not awesome, but on the flip side we also cancel active stagings in that exact scenario (if it applies), so that matches. The only real finesse is that one of the tests wants to observe the instant between the end of a staging (and creation of splits) and the start of the next one, which because the staging cron is triggered by the failure of the previous staging is now "atomic", requiring disabling the staging cron, which means the trigger is skipped entirely. So this requires triggering the staging cron by hand.
2024-08-01 15:15:32 +07:00
env.run_crons(None)
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
assert pr2.state == 'merged'
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
class TestReviewing:
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_reviewer_rights(self, env, repo, users, config):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
"""Only users with review rights will have their r+ (and other
attributes) taken in account
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
m2 = repo.make_commit(m, 'second', None, tree={'m': 'm', 'm2': 'm2'})
repo.make_ref('heads/master', m2)
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
prx = repo.make_pr(title='title', body='body', target='master', head=c1)
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen r+', config['role_other']['token'])
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
assert to_pr(env, prx).state == 'validated'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r+', config['role_reviewer']['token'])
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
assert to_pr(env, prx).state == 'ready'
[IMP] runbot_merge: warning on re-reviewing a reviewed PR
2018-10-19 16:35:31 +07:00
# second r+ to check warning
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r+', config['role_reviewer']['token'])
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: various feedback messages Send reponse comments when users mis-interact with robodoo e.g. send comments they don't have the right to, or commands which don't make sense in the PR's state, or tentative interactions with robodoo from unmanaged PRs.
2018-10-16 17:40:45 +07:00
assert prx.comments == [
(users['other'], 'hansen r+'),
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
seen(env, prx, users),
[IMP] runbot_merge: extract commit validation to cron Before this, impacting a commit's statuses on the relevant PR or staging would be performed immediatly / inline with its consumption. This, however, is problematic if we want to implement additional processing like #87 (and possibly though probably not #52): webhook handlers should be kept short and fast, feeding back into github would not be acceptable. - flag commits as needing processing instead of processing them immediately, this uses a partial index as it looks like the recommended / proper way to index a boolean column in which one of the values is searched much more than the other (todo: eventually check if that actually does anythnig) - add a new cron for commits processing - alter tests so they use this new cron (mostly by migrating them to `run_crons` though not solely as some still need more detailed management to properly check intermediate steps) Fix an issue with closing a staged PR while at it (the "merging" tag would potentially never be removed).
2019-03-05 14:01:38 +07:00
(users['user'], "I'm sorry, @{}. I'm afraid I can't do that.".format(users['other'])),
[ADD] runbot_merge: various feedback messages Send reponse comments when users mis-interact with robodoo e.g. send comments they don't have the right to, or commands which don't make sense in the PR's state, or tentative interactions with robodoo from unmanaged PRs.
2018-10-16 17:40:45 +07:00
(users['reviewer'], 'hansen r+'),
[IMP] runbot_merge: warning on re-reviewing a reviewed PR
2018-10-19 16:35:31 +07:00
(users['reviewer'], 'hansen r+'),
[IMP] runbot_merge: quality of feedback on errorneous commands - When a redundant approval is sent to a PR, notify but don't ignore the entire command set, there's no actual risk. - Indicate that the entire comment was ignored when finding something which does not parse. Fixes #892, fixes #893
2024-06-21 19:38:47 +07:00
(users['user'], "This PR is already reviewed, reviewing it again is useless.".format(
[IMP] runbot_merge: warning on re-reviewing a reviewed PR
2018-10-19 16:35:31 +07:00
users['reviewer'])),
[ADD] runbot_merge: various feedback messages Send reponse comments when users mis-interact with robodoo e.g. send comments they don't have the right to, or commands which don't make sense in the PR's state, or tentative interactions with robodoo from unmanaged PRs.
2018-10-16 17:40:45 +07:00
]
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_self_review_fail(self, env, repo, users, config):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
""" Normal reviewers can't self-review
"""
[FIX] *: tests not working with github actual Add intermediate forks to a pair of tests, because github now (?) requires being able to write on a branch to create a PR from it, so the non-collaborator reviewers were not able to create a PR from a branch created by user.
2024-01-16 21:07:25 +07:00
reviewer = config['role_reviewer']['token']
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[FIX] *: tests not working with github actual Add intermediate forks to a pair of tests, because github now (?) requires being able to write on a branch to create a PR from it, so the non-collaborator reviewers were not able to create a PR from a branch created by user.
2024-01-16 21:07:25 +07:00
[m, _] = repo.make_commits(None, Commit('initial', tree={'m': 'm'}), Commit('second', tree={'m2': 'm2'}), ref='heads/master')
with repo.fork(token=reviewer) as f:
f.make_commits(m, Commit('first', tree={'m': 'c1'}), ref='heads/change')
prx = repo.make_pr(title='title', body='body', target='master', head=f'{f.owner}:change', token=reviewer)
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
[FIX] *: tests not working with github actual Add intermediate forks to a pair of tests, because github now (?) requires being able to write on a branch to create a PR from it, so the non-collaborator reviewers were not able to create a PR from a branch created by user.
2024-01-16 21:07:25 +07:00
prx.post_comment('hansen r+', reviewer)
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] runbot_merge: logins -> user roles Can't really assume we can get the github logins "user" or "reviewer" to run the test suite remotely, so add an indirection and backronym those to *roles* instead. The local test suite has identical roles & logins, but the remote version does not. Also use the "other" role for any random user, and don't create its partner up-front. Also renamed the self-reviewer user to self_reviewer, that's a bit less weird when dealing with e.g. ini files.
2018-06-07 19:53:31 +07:00
assert prx.user == users['reviewer']
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
assert to_pr(env, prx).state == 'validated'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: various feedback messages Send reponse comments when users mis-interact with robodoo e.g. send comments they don't have the right to, or commands which don't make sense in the PR's state, or tentative interactions with robodoo from unmanaged PRs.
2018-10-16 17:40:45 +07:00
assert prx.comments == [
(users['reviewer'], 'hansen r+'),
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
seen(env, prx, users),
[CHG] runbot_merge: deskill mergebot feedback twas heehee in the moment but it's not really a long term hoohoo haahaa.
2024-08-05 14:09:23 +07:00
(users['user'], "@{} you can't review+.".format(users['reviewer'])),
[ADD] runbot_merge: various feedback messages Send reponse comments when users mis-interact with robodoo e.g. send comments they don't have the right to, or commands which don't make sense in the PR's state, or tentative interactions with robodoo from unmanaged PRs.
2018-10-16 17:40:45 +07:00
]
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_self_review_success(self, env, repo, users, config):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
""" Some users are allowed to self-review
"""
[FIX] *: tests not working with github actual Add intermediate forks to a pair of tests, because github now (?) requires being able to write on a branch to create a PR from it, so the non-collaborator reviewers were not able to create a PR from a branch created by user.
2024-01-16 21:07:25 +07:00
self_reviewer = config['role_self_reviewer']['token']
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[FIX] *: tests not working with github actual Add intermediate forks to a pair of tests, because github now (?) requires being able to write on a branch to create a PR from it, so the non-collaborator reviewers were not able to create a PR from a branch created by user.
2024-01-16 21:07:25 +07:00
[m, _] = repo.make_commits(None, Commit('initial', tree={'m': 'm'}), Commit('second', tree={'m': 'm', 'm2': 'm2'}), ref='heads/master')
with repo.fork(token=self_reviewer) as f:
f.make_commits(m, Commit('first', tree={'m': 'c1'}), ref='heads/change')
prx = repo.make_pr(title='title', body='body', target='master', head=f'{f.owner}:change', token=self_reviewer)
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
[FIX] *: tests not working with github actual Add intermediate forks to a pair of tests, because github now (?) requires being able to write on a branch to create a PR from it, so the non-collaborator reviewers were not able to create a PR from a branch created by user.
2024-01-16 21:07:25 +07:00
prx.post_comment('hansen r+', self_reviewer)
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] runbot_merge: logins -> user roles Can't really assume we can get the github logins "user" or "reviewer" to run the test suite remotely, so add an indirection and backronym those to *roles* instead. The local test suite has identical roles & logins, but the remote version does not. Also use the "other" role for any random user, and don't create its partner up-front. Also renamed the self-reviewer user to self_reviewer, that's a bit less weird when dealing with e.g. ini files.
2018-06-07 19:53:31 +07:00
assert prx.user == users['self_reviewer']
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
assert to_pr(env, prx).state == 'ready'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_delegate_review(self, env, repo, users, config):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
"""Users should be able to delegate review to either the creator of
the PR or an other user without review rights
"""
[IMP] runbot_merge: reject review without email If a reviewer doesn't have an email set, the Signed-Off-By is an `@users.noreply.github.com` address which just looks weird in the final result. Initially the thinking was that emails would be required for users to *be* reviewers or self-reviewers, but since those are now o2ms / m2ms it's a bit of a pain in the ass. Instead, provide an action to easily try and fetch the public email of a user from github. Fixes #531
2021-10-06 18:06:53 +07:00
env['res.partner'].create({
'name': users['user'],
'github_login': users['user'],
'email': users['user'] + '@example.org',
})
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
m2 = repo.make_commit(m, 'second', None, tree={'m': 'm', 'm2': 'm2'})
repo.make_ref('heads/master', m2)
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
prx = repo.make_pr(title='title', body='body', target='master', head=c1)
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen delegate+', config['role_reviewer']['token'])
prx.post_comment('hansen r+', config['role_user']['token'])
env.run_crons()
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] runbot_merge: logins -> user roles Can't really assume we can get the github logins "user" or "reviewer" to run the test suite remotely, so add an indirection and backronym those to *roles* instead. The local test suite has identical roles & logins, but the remote version does not. Also use the "other" role for any random user, and don't create its partner up-front. Also renamed the self-reviewer user to self_reviewer, that's a bit less weird when dealing with e.g. ini files.
2018-06-07 19:53:31 +07:00
assert prx.user == users['user']
[IMP] runbot_merge: reject review without email If a reviewer doesn't have an email set, the Signed-Off-By is an `@users.noreply.github.com` address which just looks weird in the final result. Initially the thinking was that emails would be required for users to *be* reviewers or self-reviewers, but since those are now o2ms / m2ms it's a bit of a pain in the ass. Instead, provide an action to easily try and fetch the public email of a user from github. Fixes #531
2021-10-06 18:06:53 +07:00
assert to_pr(env, prx).state == 'ready'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_delegate_review_thirdparty(self, env, repo, users, config):
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
"""Users should be able to delegate review to either the creator of
the PR or an other user without review rights
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
m2 = repo.make_commit(m, 'second', None, tree={'m': 'm', 'm2': 'm2'})
repo.make_ref('heads/master', m2)
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
prx = repo.make_pr(title='title', body='body', target='master', head=c1)
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
[FIX] runbot_merge: make github_login case insensitive Rather than try to fix up various bits where we search & all and wonder what index we should be using, make the column a CIText. For mergebot the main use case would be properly handling delegate=XXX: currently if XXX is not a case-sensitive match we're going to create a new partner with the new github login and give *them* delegation, and the intended target of the delegation isn't going to work correctly. Also try to install the citext extension if it's not in the database, and run the database-creation process with `check=True` so if that fails we properly bubble up the error and don't try to run tests on a corrupted / broken DB. Fixes #318
2020-02-11 14:46:31 +07:00
# flip case to check that github login is case-insensitive
other = ''.join(c.lower() if c.isupper() else c.upper() for c in users['other'])
prx.post_comment('hansen delegate=%s' % other, config['role_reviewer']['token'])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] runbot_merge: reject review without email If a reviewer doesn't have an email set, the Signed-Off-By is an `@users.noreply.github.com` address which just looks weird in the final result. Initially the thinking was that emails would be required for users to *be* reviewers or self-reviewers, but since those are now o2ms / m2ms it's a bit of a pain in the ass. Instead, provide an action to easily try and fetch the public email of a user from github. Fixes #531
2021-10-06 18:06:53 +07:00
env['res.partner'].search([('github_login', '=', other)]).email = f'{other}@example.org'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[FIX] runbot_merge: make github_login case insensitive Rather than try to fix up various bits where we search & all and wonder what index we should be using, make the column a CIText. For mergebot the main use case would be properly handling delegate=XXX: currently if XXX is not a case-sensitive match we're going to create a new partner with the new github login and give *them* delegation, and the intended target of the delegation isn't going to work correctly. Also try to install the citext extension if it's not in the database, and run the database-creation process with `check=True` so if that fails we properly bubble up the error and don't try to run tests on a corrupted / broken DB. Fixes #318
2020-02-11 14:46:31 +07:00
with repo:
# check this is ignored
prx.post_comment('hansen r+', config['role_user']['token'])
[IMP] runbot_merge: logins -> user roles Can't really assume we can get the github logins "user" or "reviewer" to run the test suite remotely, so add an indirection and backronym those to *roles* instead. The local test suite has identical roles & logins, but the remote version does not. Also use the "other" role for any random user, and don't create its partner up-front. Also renamed the self-reviewer user to self_reviewer, that's a bit less weird when dealing with e.g. ini files.
2018-06-07 19:53:31 +07:00
assert prx.user == users['user']
[IMP] runbot_merge: reject review without email If a reviewer doesn't have an email set, the Signed-Off-By is an `@users.noreply.github.com` address which just looks weird in the final result. Initially the thinking was that emails would be required for users to *be* reviewers or self-reviewers, but since those are now o2ms / m2ms it's a bit of a pain in the ass. Instead, provide an action to easily try and fetch the public email of a user from github. Fixes #531
2021-10-06 18:06:53 +07:00
prx_id = to_pr(env, prx)
assert prx_id.state == 'validated'
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[FIX] runbot_merge: make github_login case insensitive Rather than try to fix up various bits where we search & all and wonder what index we should be using, make the column a CIText. For mergebot the main use case would be properly handling delegate=XXX: currently if XXX is not a case-sensitive match we're going to create a new partner with the new github login and give *them* delegation, and the intended target of the delegation isn't going to work correctly. Also try to install the citext extension if it's not in the database, and run the database-creation process with `check=True` so if that fails we properly bubble up the error and don't try to run tests on a corrupted / broken DB. Fixes #318
2020-02-11 14:46:31 +07:00
# check this works
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
prx.post_comment('hansen r+', config['role_other']['token'])
[IMP] runbot_merge: reject review without email If a reviewer doesn't have an email set, the Signed-Off-By is an `@users.noreply.github.com` address which just looks weird in the final result. Initially the thinking was that emails would be required for users to *be* reviewers or self-reviewers, but since those are now o2ms / m2ms it's a bit of a pain in the ass. Instead, provide an action to easily try and fetch the public email of a user from github. Fixes #531
2021-10-06 18:06:53 +07:00
assert prx_id.state == 'ready'
[ADD] runbot_merge: reviews support Reviews are interpreted like comments and can contain any number of commands, with the difference that APPROVED and REQUEST_CHANGES are interpreted as (respectively) r+ and r- prefixes.
2018-03-27 21:39:29 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_delegate_prefixes(self, env, repo, config):
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
[IMP] runbot_merge: support @ and # prefixes to delegate= logins
2018-09-25 21:42:56 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c = repo.make_commit(m, 'first', None, tree={'m': 'c'})
prx = repo.make_pr(title='title', body=None, target='master', head=c)
prx.post_comment('hansen delegate=foo,@bar,#baz', config['role_reviewer']['token'])
[IMP] runbot_merge: support @ and # prefixes to delegate= logins
2018-09-25 21:42:56 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[IMP] runbot_merge: support @ and # prefixes to delegate= logins
2018-09-25 21:42:56 +07:00
assert {d.github_login for d in pr.delegates} == {'foo', 'bar', 'baz'}
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_actual_review(self, env, repo, config):
[CHG] runbot_merge: treat github reviews as regular comments Treating them specially turns out to be inconvenient: it becomes harder/riskier to ask for informal reviews (for which GH reviews are useful).
2018-09-25 19:05:41 +07:00
""" treat github reviews as regular comments
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
m2 = repo.make_commit(m, 'second', None, tree={'m': 'm', 'm2': 'm2'})
repo.make_ref('heads/master', m2)
[ADD] runbot_merge: reviews support Reviews are interpreted like comments and can contain any number of commands, with the difference that APPROVED and REQUEST_CHANGES are interpreted as (respectively) r+ and r- prefixes.
2018-03-27 21:39:29 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
prx = repo.make_pr(title='title', body='body', target='master', head=c1)
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[ADD] runbot_merge: reviews support Reviews are interpreted like comments and can contain any number of commands, with the difference that APPROVED and REQUEST_CHANGES are interpreted as (respectively) r+ and r- prefixes.
2018-03-27 21:39:29 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
prx.post_review('COMMENT', "hansen priority", config['role_reviewer']['token'])
assert pr.priority == 'priority'
[ADD] runbot_merge: reviews support Reviews are interpreted like comments and can contain any number of commands, with the difference that APPROVED and REQUEST_CHANGES are interpreted as (respectively) r+ and r- prefixes.
2018-03-27 21:39:29 +07:00
assert pr.state == 'opened'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
prx.post_review('APPROVE', "hansen default", config['role_reviewer']['token'])
assert pr.priority == 'default'
[CHG] runbot_merge: treat github reviews as regular comments Treating them specially turns out to be inconvenient: it becomes harder/riskier to ask for informal reviews (for which GH reviews are useful).
2018-09-25 19:05:41 +07:00
assert pr.state == 'opened'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
prx.post_review('REQUEST_CHANGES', 'hansen priority', config['role_reviewer']['token'])
assert pr.priority == 'priority'
[CHG] runbot_merge: treat github reviews as regular comments Treating them specially turns out to be inconvenient: it becomes harder/riskier to ask for informal reviews (for which GH reviews are useful).
2018-09-25 19:05:41 +07:00
assert pr.state == 'opened'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_review('COMMENT', 'hansen r+', config['role_reviewer']['token'])
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
assert pr.priority == 'priority'
[ADD] runbot_merge: reviews support Reviews are interpreted like comments and can contain any number of commands, with the difference that APPROVED and REQUEST_CHANGES are interpreted as (respectively) r+ and r- prefixes.
2018-03-27 21:39:29 +07:00
assert pr.state == 'approved'
[IMP] runbot_merge: remove "sync PRs", fetch unknown PRs The old "sync pr" thing is turning out to be a bust, while it originally worked fine these days it's a catastrophe as the v4 API performances seem to have significantly degraded, to the point that fetching all 15k PRs by pages of 100 simply blows up after a few hundreds/thousands. Instead, add a table of PRs to sync: if we get notified of a "compatible" PR (enabled repo & target) which we don't know of, create an entry in a "fetch jobs" table, then a cron will handle fetching the PR then fetching/applying all relevant metadata (statuses, review-comments and reviews). Also change indexation of Commit(sha) and PR(head) to hash, as btree indexes are not really sensible for such content (the ordering is unhelpful and the index locality is awful by design/definition).
2018-06-21 14:55:14 +07:00
[IMP] runbot_merge: reject review without email If a reviewer doesn't have an email set, the Signed-Off-By is an `@users.noreply.github.com` address which just looks weird in the final result. Initially the thinking was that emails would be required for users to *be* reviewers or self-reviewers, but since those are now o2ms / m2ms it's a bit of a pain in the ass. Instead, provide an action to easily try and fetch the public email of a user from github. Fixes #531
2021-10-06 18:06:53 +07:00
def test_no_email(self, env, repo, users, config, partners):
"""A review should be rejected if the reviewer doesn't have an email
configured, otherwise the email address will show up
@users.noreply.github.com which is *weird*.
"""
with repo:
[m] = repo.make_commits(
None,
Commit('initial', tree={'m': '1'}),
ref='heads/master'
)
[c] = repo.make_commits(m, Commit('first', tree={'m': '2'}))
pr = repo.make_pr(target='master', head=c)
env.run_crons()
with repo:
pr.post_comment('hansen delegate+', config['role_reviewer']['token'])
pr.post_comment('hansen r+', config['role_user']['token'])
env.run_crons()
user_partner = env['res.partner'].search([('github_login', '=', users['user'])])
assert user_partner.email is False
assert pr.comments == [
seen(env, pr, users),
(users['reviewer'], 'hansen delegate+'),
(users['user'], 'hansen r+'),
[CHG] runbot_merge, forwardbot: merge commands parser - move all commands parsing to runbot_merge as part of the long-term unification effort (#789) - set up an actual parser-ish structure to parse the commands to something approaching a sum type (fixes #507) - this is mostly prep for reworking the commands set (#673), although *strict command parsing* has been implemented (cf update to `test_unknown_commands`)
2023-10-16 15:46:29 +07:00
(users['user'], f"@{users['user']} I must know your email before you can review PRs. Please contact an administrator."),
[IMP] runbot_merge: reject review without email If a reviewer doesn't have an email set, the Signed-Off-By is an `@users.noreply.github.com` address which just looks weird in the final result. Initially the thinking was that emails would be required for users to *be* reviewers or self-reviewers, but since those are now o2ms / m2ms it's a bit of a pain in the ass. Instead, provide an action to easily try and fetch the public email of a user from github. Fixes #531
2021-10-06 18:06:53 +07:00
]
user_partner.fetch_github_email()
assert user_partner.email
with repo:
pr.post_comment('hansen r+', config['role_user']['token'])
env.run_crons()
assert to_pr(env, pr).state == 'approved'
[ADD] runbot_merge: help command, and help on error Fixes #898
2024-06-25 03:16:43 +07:00
@pytest.mark.usefixtures("reviewer_admin")
[CHG] *: rewrite commands set, rework status management This commit revisits the commands set in order to make it more regular, and limit inconsistent command-sets, although it includes pseudo-command aliases for common tasks now removed from the core set. Hard Errors =========== The previous iteration of the commands set would ignore any non-command term in a command line. This has been changed to hard error (and ignoring the entire thing) if any command is unknown or invalid. This fixes inconsistent / unexpected interpretations where a user sends a command, then writes a novel on the same line some words of which happen to *also* be commands, leading to merge states they did not expect. They should now be told to fuck off. Priority Restructuring ---------------------- The numerical priority system was pretty messy in that it confused "staging priority" (in ways which were not entirely straightforward) with overrides to other concerns. This has now being split along all the axis, with separate command subsets for: - staging prioritisation, now separated between `default`, `priority`, and `alone`, - `default` means PRs are picked by an unspecified order when creating a staging, if nothing better is available - `priority` means PRs are picked first when staging, however if `priority` PRs don't fill the staging the rest will be filled with `default`, this mode did not previously exist - `alone` means the PRs are picked first, before splits, and only `alone` PRs can be part of the staging (which usually matches the modename) - `skipchecks` overrides both statuses and approval checks, for the batch, something previously implied in `p=0`, but now independent. Setting `skipchecks` basically makes the entire batch `ready`. For consistency this also sets the reviewer implicitly: since skipchecks overrides both statuses *and approval*, whoever enables this mode is essentially the reviewer. - `cancel` cancels any ongoing staging when the marked PR becomes ready again, previously this was also implied (in a more restricted form) by setting `p=0` FWBot removal ============= While the "forwardport bot" still exists as an API level (to segregate access rights between tokens) it has been removed as an interaction point, as part of the modules merge plan. As a result, fwbot stops responding ---------------------- Feedback messages are now always sent by the mergebot, the forward-porting bot should not send any message or notification anymore. commands moved to the merge bot ------------------------------- - `ignore`/`up to` simply changes bot - `close` as well - `skipci` is now a choice / flag of an `fw` command, which denotes the forward-port policy, - `fw=default` is the old `ci` and resets the policy to default, that is wait for the PR to be merged to create forward ports, and for the required statuses on each forward port to be received before creating the next - `fw=skipci` is the old `skipci`, it waits for the merge of the base PR but then creates all the forward ports immediately (unless it gets a conflict) - `fw=skipmerge` immediately creates all the forward ports, without even waiting for the PR to be merged This is a completely new mode, and may be rather broken as until now the 'bot has always assumed the source PR had been merged. approval rework --------------- Because of the previous section, there is no distinguishing feature between `mergebot r+` = "merge this PR" and `forwardbot r+` = "merge this PR and all its parent with different access rights". As a result, the two have been merged under a single `mergebot r+` with heuristics attempting to provide the best experience: - if approving a non-forward port, the behavior does not change - else, with review rights on the source, all ancestors are approved - else, as author of the original, approves all ancestors which descend from a merged PR - else, approves all ancestors up to and including the oldest ancestor to which we have review rights Most notably, the source's author is not delegated on the source or any of its descendants anymore. This might need to be revisited if it provides too restrictive. For the very specialized need of approving a forward-port *and none of its ancestors*, `review=` can now take a comma (`,`) separated list of pull request numbers (github numbers, not mergebot ids). Computed State ============== The `state` field of pull requests is now computed. Hopefully this makes the status more consistent and predictable in the long run, and importantly makes status management more reliable (because reference datum get updated naturally flowing to the state). For now however it makes things more complicated as some of the states have to be separately signaled or updated: - `closed` and `error` are now separate flags - `merge_date` is pulled down from forwardport and becomes the transition signal for ready -> merged - `reviewed_by` becomes the transition signal for approval (might be a good idea to rename it...) - `status` is computed from the head's statuses and overrides, and *that* becomes the validation state Ideally, batch-level flags like `skipchecks` should be on, well, the batch, and `state` should have a dependency on the batch. However currently the batch is not a durable / permanent member of the system, so it's a PR-level flag and a messy pile. On notable change is that *forcing* the state to `ready` now does that but also sets the reviewer, `skipchecks`, and overrides to ensure the API-mediated readying does not get rolled back by e.g. the runbot sending a status. This is useful for a few types of automated / programmatic PRs e.g. translation exports, where we set the state programmatically to limit noise. recursive dependency hack ------------------------- Given a sequence of PRs with an override of the source, if one of the PRs is updated its descendants should not have the override anymore. However if the updated PR gets overridden, its descendants should have *that* override. This requires some unholy manipulations via an override of `modified`, as the ORM supports recursive fields but not recursive dependencies (on a different field). unconditional followup scheduling --------------------------------- Previously scheduling forward-port followup was contigent on the FW policy, but it's not actually correct if the new PR is *immediately* validated (which can happen now that the field is computed, if there are no required statuses *or* all of the required statuses are overridden by an ancestor) as nothing will trigger the state change and thus scheduling of the fp followup. The followup function checks all the properties of the batch to port, so this should not result on incorrect ports. Although it's a bit more expensive, and will lead to more spam. Previously this would not happen because on creation of a PR the validation task (commit -> PR) would still have to execute. Misc Changes ============ - If a PR is marked as overriding / canceling stagings, it now does so on retry not just when setting initially. This was not handled at all previously, so a PR in P0 going into error due to e.g. a non-deterministic bug would be retried and still p=0, but a current staging would not get cancelled. Same when a PR in p=0 goes into error because something was failed, then is updated with a fix. - Add tracking to a bunch of relevant PR fields. Post-mortem analysis currently generally requires going through the text logs to see what happened, which is annoying. There is a nondeterminism / inconsistency in the tracking which sometimes leads the admin user to trigger tracking before the bot does, leading to the staging tracking being attributed to them during tests, shove under the carpet by ignoring the user to whom that tracking is attributed. When multiple users update tracked fields in the same transaction all the changes are attributed to the first one having triggered tracking (?), I couldn't find why the admin sometimes takes over. - added and leveraged support for enum-backed selection fields - moved variuous fields from forwardport to runbot_merge - fix a migration which had never worked and which never run (because I forgot to bump the version on the module) - remove some unnecessary intermediate de/serialisation fixes #673, fixes #309, fixes #792, fixes #846 (probably)
2023-10-31 13:42:07 +07:00
def test_skipchecks(self, env, repo, users, config):
"""Skipcheck makes the PR immediately ready (if it's not in error or
something)
"""
with repo:
[m, _] = repo.make_commits(
None,
Commit("initial", tree={'m': 'm'}),
Commit("second", tree={"m2": "m2"}),
ref="heads/master"
)
[c1] = repo.make_commits(m, Commit('first', tree={'m': 'c1'}))
pr = repo.make_pr(title='title', target='master', head=c1)
pr.post_comment('hansen skipchecks', config['role_reviewer']['token'])
env.run_crons()
pr_id = to_pr(env, pr)
# assert pr_id.state == 'ready'
assert not pr_id.blocked
# since the pr is not blocked it should have been staged by the relevant cron
assert pr_id.staging_id
[IMP] runbot_merge: reject review without email If a reviewer doesn't have an email set, the Signed-Off-By is an `@users.noreply.github.com` address which just looks weird in the final result. Initially the thinking was that emails would be required for users to *be* reviewers or self-reviewers, but since those are now o2ms / m2ms it's a bit of a pain in the ass. Instead, provide an action to easily try and fetch the public email of a user from github. Fixes #531
2021-10-06 18:06:53 +07:00
[IMP] runbot_merge: remove "sync PRs", fetch unknown PRs The old "sync pr" thing is turning out to be a bust, while it originally worked fine these days it's a catastrophe as the v4 API performances seem to have significantly degraded, to the point that fetching all 15k PRs by pages of 100 simply blows up after a few hundreds/thousands. Instead, add a table of PRs to sync: if we get notified of a "compatible" PR (enabled repo & target) which we don't know of, create an entry in a "fetch jobs" table, then a cron will handle fetching the PR then fetching/applying all relevant metadata (statuses, review-comments and reviews). Also change indexation of Commit(sha) and PR(head) to hash, as btree indexes are not really sensible for such content (the ordering is unhelpful and the index locality is awful by design/definition).
2018-06-21 14:55:14 +07:00
class TestUnknownPR:
""" Sync PRs initially looked excellent but aside from the v4 API not
being stable yet, it seems to have greatly regressed in performances to
the extent that it's almost impossible to sync odoo/odoo today: trying to
fetch more than 2 PRs per query will fail semi-randomly at one point, so
fetching all 15000 PRs takes hours
=> instead, create PRs on the fly when getting notifications related to
valid but unknown PRs
"""
[FIX] runbot_merge: cancel approval (r+) when fetching PRs When retrieving unknown PRs, the process would apply all comments, thereby applying eventual r+ without taking in account their relationship to a force push. This means it was possible for a mergebot-unknown PR to be r+'d, updated, retargeted, and the mergetbot would consider it good to go. The possible damage would be somewhat limited but still, not great. Sadly Github simply doesn't provide access to the entire event stream of the PR, so there is no way to even know whether the PR was updated, let alone when in relation to comments. Therefore just resync the PR after having applied comments: we still want to apply the merge method & al, we just want to reset back to un-approved. An other minor fix (for something we never actually hit but could): reviews are treated more or less as comments, but separate at github's level. The job would apply all comments then all reviews, so the relative order of comments and reviews would be wrong. Combine and order comments and reviews so they are applied in (hopefully) the correct order of their creation / submission. Closes #416
2020-11-10 22:13:08 +07:00
def test_rplus_unknown(self, repo, env, config, users):
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
m2 = repo.make_commit(m, 'second', None, tree={'m': 'm', 'm2': 'm2'})
repo.make_ref('heads/master', m2)
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
prx = repo.make_pr(title='title', body='body', target='master', head=c1)
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot', target_url="http://example.org/wheee")
env.run_crons()
[IMP] runbot_merge: link to failed runbot builds a0063f9df091ef901cfb055b002e9cf4107688bc slightly improved the error message on non-PR ci failure (e.g. a community PR makes enterprise break) by adding the failed commit, but that's still not exactly clear, even for technical users (plus it requires having access to all the repos which is not the case for everyone). This commit further improves the situation by storing the target_url and description fields of the commit statuses, and printing out the target_url on failure if it's present. That way the PR comment denoting build failure should now have a link to the relevant failed build on runbot, as that's the target_url it provides. The change is nontrivial as it tries to be compatible with both old and new statuses storage format, such that there is no migration to perform.
2018-09-17 16:04:31 +07:00
[IMP] runbot_merge: remove "sync PRs", fetch unknown PRs The old "sync pr" thing is turning out to be a bust, while it originally worked fine these days it's a catastrophe as the v4 API performances seem to have significantly degraded, to the point that fetching all 15k PRs by pages of 100 simply blows up after a few hundreds/thousands. Instead, add a table of PRs to sync: if we get notified of a "compatible" PR (enabled repo & target) which we don't know of, create an entry in a "fetch jobs" table, then a cron will handle fetching the PR then fetching/applying all relevant metadata (statuses, review-comments and reviews). Also change indexation of Commit(sha) and PR(head) to hash, as btree indexes are not really sensible for such content (the ordering is unhelpful and the index locality is awful by design/definition).
2018-06-21 14:55:14 +07:00
# assume an unknown but ready PR: we don't know the PR or its head commit
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
to_pr(env, prx).unlink()
[IMP] runbot_merge: remove "sync PRs", fetch unknown PRs The old "sync pr" thing is turning out to be a bust, while it originally worked fine these days it's a catastrophe as the v4 API performances seem to have significantly degraded, to the point that fetching all 15k PRs by pages of 100 simply blows up after a few hundreds/thousands. Instead, add a table of PRs to sync: if we get notified of a "compatible" PR (enabled repo & target) which we don't know of, create an entry in a "fetch jobs" table, then a cron will handle fetching the PR then fetching/applying all relevant metadata (statuses, review-comments and reviews). Also change indexation of Commit(sha) and PR(head) to hash, as btree indexes are not really sensible for such content (the ordering is unhelpful and the index locality is awful by design/definition).
2018-06-21 14:55:14 +07:00
env['runbot_merge.commit'].search([('sha', '=', prx.head)]).unlink()
# reviewer reviewers
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r+', config['role_reviewer']['token'])
[FIX] runbot_merge: cancel approval (r+) when fetching PRs When retrieving unknown PRs, the process would apply all comments, thereby applying eventual r+ without taking in account their relationship to a force push. This means it was possible for a mergebot-unknown PR to be r+'d, updated, retargeted, and the mergetbot would consider it good to go. The possible damage would be somewhat limited but still, not great. Sadly Github simply doesn't provide access to the entire event stream of the PR, so there is no way to even know whether the PR was updated, let alone when in relation to comments. Therefore just resync the PR after having applied comments: we still want to apply the merge method & al, we just want to reset back to un-approved. An other minor fix (for something we never actually hit but could): reviews are treated more or less as comments, but separate at github's level. The job would apply all comments then all reviews, so the relative order of comments and reviews would be wrong. Combine and order comments and reviews so they are applied in (hopefully) the correct order of their creation / submission. Closes #416
2020-11-10 22:13:08 +07:00
with repo:
prx.post_review('REQUEST_CHANGES', 'hansen r-', config['role_reviewer']['token'])
with repo:
prx.post_comment('hansen r+', config['role_reviewer']['token'])
[IMP] runbot_merge: remove "sync PRs", fetch unknown PRs The old "sync pr" thing is turning out to be a bust, while it originally worked fine these days it's a catastrophe as the v4 API performances seem to have significantly degraded, to the point that fetching all 15k PRs by pages of 100 simply blows up after a few hundreds/thousands. Instead, add a table of PRs to sync: if we get notified of a "compatible" PR (enabled repo & target) which we don't know of, create an entry in a "fetch jobs" table, then a cron will handle fetching the PR then fetching/applying all relevant metadata (statuses, review-comments and reviews). Also change indexation of Commit(sha) and PR(head) to hash, as btree indexes are not really sensible for such content (the ordering is unhelpful and the index locality is awful by design/definition).
2018-06-21 14:55:14 +07:00
Fetch = env['runbot_merge.fetch_job']
[FIX] runbot_merge: cancel approval (r+) when fetching PRs When retrieving unknown PRs, the process would apply all comments, thereby applying eventual r+ without taking in account their relationship to a force push. This means it was possible for a mergebot-unknown PR to be r+'d, updated, retargeted, and the mergetbot would consider it good to go. The possible damage would be somewhat limited but still, not great. Sadly Github simply doesn't provide access to the entire event stream of the PR, so there is no way to even know whether the PR was updated, let alone when in relation to comments. Therefore just resync the PR after having applied comments: we still want to apply the merge method & al, we just want to reset back to un-approved. An other minor fix (for something we never actually hit but could): reviews are treated more or less as comments, but separate at github's level. The job would apply all comments then all reviews, so the relative order of comments and reviews would be wrong. Combine and order comments and reviews so they are applied in (hopefully) the correct order of their creation / submission. Closes #416
2020-11-10 22:13:08 +07:00
fetches = Fetch.search([('repository', '=', repo.name), ('number', '=', prx.number)])
assert len(fetches) == 1, f"expected one fetch for {prx.number}, found {len(fetches)}"
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons('runbot_merge.fetch_prs_cron')
env.run_crons()
[IMP] runbot_merge: remove "sync PRs", fetch unknown PRs The old "sync pr" thing is turning out to be a bust, while it originally worked fine these days it's a catastrophe as the v4 API performances seem to have significantly degraded, to the point that fetching all 15k PRs by pages of 100 simply blows up after a few hundreds/thousands. Instead, add a table of PRs to sync: if we get notified of a "compatible" PR (enabled repo & target) which we don't know of, create an entry in a "fetch jobs" table, then a cron will handle fetching the PR then fetching/applying all relevant metadata (statuses, review-comments and reviews). Also change indexation of Commit(sha) and PR(head) to hash, as btree indexes are not really sensible for such content (the ordering is unhelpful and the index locality is awful by design/definition).
2018-06-21 14:55:14 +07:00
assert not Fetch.search([('repository', '=', repo.name), ('number', '=', prx.number)])
[IMP] runbot_merge: link to failed runbot builds a0063f9df091ef901cfb055b002e9cf4107688bc slightly improved the error message on non-PR ci failure (e.g. a community PR makes enterprise break) by adding the failed commit, but that's still not exactly clear, even for technical users (plus it requires having access to all the repos which is not the case for everyone). This commit further improves the situation by storing the target_url and description fields of the commit statuses, and printing out the target_url on failure if it's present. That way the PR comment denoting build failure should now have a link to the relevant failed build on runbot, as that's the target_url it provides. The change is nontrivial as it tries to be compatible with both old and new statuses storage format, such that there is no migration to perform.
2018-09-17 16:04:31 +07:00
c = env['runbot_merge.commit'].search([('sha', '=', prx.head)])
assert json.loads(c.statuses) == {
[FIX] runbot_merge: don't over-bump timeout By updating the staging timeout every time we run `_compute_state` and still have a `pending` status, we'd actually bump the timeout *on every success CI* except for the last one. Which was never the intention and can add an hour or two to the mergebot-side timeout. Instead, add an `updated_at` attribute to statuses (name taken from the webhook payload even though we don't use that), read it when we see `pending` required statuses, and update the staging timeout based on that if necessary. That way as long as we don't get *new* pending statuses, the timeout doesn't get updated. Fixes #952
2024-09-20 17:17:17 +07:00
'legal/cla': {'state': 'success', 'target_url': None, 'description': None, 'updated_at': matches("$$")},
'ci/runbot': {'state': 'success', 'target_url': 'http://example.org/wheee', 'description': None, 'updated_at': matches("$$")}
[IMP] runbot_merge: link to failed runbot builds a0063f9df091ef901cfb055b002e9cf4107688bc slightly improved the error message on non-PR ci failure (e.g. a community PR makes enterprise break) by adding the failed commit, but that's still not exactly clear, even for technical users (plus it requires having access to all the repos which is not the case for everyone). This commit further improves the situation by storing the target_url and description fields of the commit statuses, and printing out the target_url on failure if it's present. That way the PR comment denoting build failure should now have a link to the relevant failed build on runbot, as that's the target_url it provides. The change is nontrivial as it tries to be compatible with both old and new statuses storage format, such that there is no migration to perform.
2018-09-17 16:04:31 +07:00
}
[FIX] runbot_merge: cancel approval (r+) when fetching PRs When retrieving unknown PRs, the process would apply all comments, thereby applying eventual r+ without taking in account their relationship to a force push. This means it was possible for a mergebot-unknown PR to be r+'d, updated, retargeted, and the mergetbot would consider it good to go. The possible damage would be somewhat limited but still, not great. Sadly Github simply doesn't provide access to the entire event stream of the PR, so there is no way to even know whether the PR was updated, let alone when in relation to comments. Therefore just resync the PR after having applied comments: we still want to apply the merge method & al, we just want to reset back to un-approved. An other minor fix (for something we never actually hit but could): reviews are treated more or less as comments, but separate at github's level. The job would apply all comments then all reviews, so the relative order of comments and reviews would be wrong. Combine and order comments and reviews so they are applied in (hopefully) the correct order of their creation / submission. Closes #416
2020-11-10 22:13:08 +07:00
assert prx.comments == [
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
seen(env, prx, users),
[FIX] runbot_merge: cancel approval (r+) when fetching PRs When retrieving unknown PRs, the process would apply all comments, thereby applying eventual r+ without taking in account their relationship to a force push. This means it was possible for a mergebot-unknown PR to be r+'d, updated, retargeted, and the mergetbot would consider it good to go. The possible damage would be somewhat limited but still, not great. Sadly Github simply doesn't provide access to the entire event stream of the PR, so there is no way to even know whether the PR was updated, let alone when in relation to comments. Therefore just resync the PR after having applied comments: we still want to apply the merge method & al, we just want to reset back to un-approved. An other minor fix (for something we never actually hit but could): reviews are treated more or less as comments, but separate at github's level. The job would apply all comments then all reviews, so the relative order of comments and reviews would be wrong. Combine and order comments and reviews so they are applied in (hopefully) the correct order of their creation / submission. Closes #416
2020-11-10 22:13:08 +07:00
(users['reviewer'], 'hansen r+'),
(users['reviewer'], 'hansen r+'),
[REF] *: move most feedback messages to pseudo-templates Current system makes it hard to iterate feedback messages and make them clearer, this should improve things a touch. Use a bespoke model to avoid concerns with qweb rendering complexity (we just want GFM output and should not need logic). Also update fwbot test setup to always configure an fwbot name, in order to avoid ping messages closing the PRs they're talking about, that took a while to debug, and given the old message I assume I'd already hit it and just been too lazy to fix. This requires updating a bunch of tests as fwbot ping are sent *to* `fp_github_name`, but sent *from* the reference user (because that's the key we set). Note: noupdate on CSV files doesn't seem to work anymore, which isn't great. But instead set tracking on the template's templates, it's not quite as good but should be sufficient. Fixes #769
2023-06-12 19:41:42 +07:00
seen(env, prx, users),
[IMP] runbot_merge: ping commenter when fetching PR due to comment If a comment causes an unknown PR to be fetched, it's a bit odd to ping the author (and possibly reviewer) anyway as they're not super concerned (and technically we could be ignoring the purported / attempted reviewer). So if a fetch job was created because of a comment, remember the comment author and ping *them* instead of using the default ping policy. Fixes #981
2024-11-18 19:52:27 +07:00
(users['user'], f"@{users['reviewer']} I didn't know about this PR and had to "
[FIX] runbot_merge: cancel approval (r+) when fetching PRs When retrieving unknown PRs, the process would apply all comments, thereby applying eventual r+ without taking in account their relationship to a force push. This means it was possible for a mergebot-unknown PR to be r+'d, updated, retargeted, and the mergetbot would consider it good to go. The possible damage would be somewhat limited but still, not great. Sadly Github simply doesn't provide access to the entire event stream of the PR, so there is no way to even know whether the PR was updated, let alone when in relation to comments. Therefore just resync the PR after having applied comments: we still want to apply the merge method & al, we just want to reset back to un-approved. An other minor fix (for something we never actually hit but could): reviews are treated more or less as comments, but separate at github's level. The job would apply all comments then all reviews, so the relative order of comments and reviews would be wrong. Combine and order comments and reviews so they are applied in (hopefully) the correct order of their creation / submission. Closes #416
2020-11-10 22:13:08 +07:00
"retrieve its information, you may have to "
[IMP] *: review mergebot & forwardbot messages for pinging Old messages were quite inconsistent in their pinging of the PR author and reviewer. Reviewed messages (probably missed some but...) and try to more consistently ping when the feedback requires some sort of action in order to proceed. Fixes #592
2022-06-23 19:25:07 +07:00
"re-approve it as I didn't see previous commands."),
[FIX] runbot_merge: cancel approval (r+) when fetching PRs When retrieving unknown PRs, the process would apply all comments, thereby applying eventual r+ without taking in account their relationship to a force push. This means it was possible for a mergebot-unknown PR to be r+'d, updated, retargeted, and the mergetbot would consider it good to go. The possible damage would be somewhat limited but still, not great. Sadly Github simply doesn't provide access to the entire event stream of the PR, so there is no way to even know whether the PR was updated, let alone when in relation to comments. Therefore just resync the PR after having applied comments: we still want to apply the merge method & al, we just want to reset back to un-approved. An other minor fix (for something we never actually hit but could): reviews are treated more or less as comments, but separate at github's level. The job would apply all comments then all reviews, so the relative order of comments and reviews would be wrong. Combine and order comments and reviews so they are applied in (hopefully) the correct order of their creation / submission. Closes #416
2020-11-10 22:13:08 +07:00
]
[IMP] runbot_merge: link to failed runbot builds a0063f9df091ef901cfb055b002e9cf4107688bc slightly improved the error message on non-PR ci failure (e.g. a community PR makes enterprise break) by adding the failed commit, but that's still not exactly clear, even for technical users (plus it requires having access to all the repos which is not the case for everyone). This commit further improves the situation by storing the target_url and description fields of the commit statuses, and printing out the target_url on failure if it's present. That way the PR comment denoting build failure should now have a link to the relevant failed build on runbot, as that's the target_url it provides. The change is nontrivial as it tries to be compatible with both old and new statuses storage format, such that there is no migration to perform.
2018-09-17 16:04:31 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[FIX] runbot_merge: cancel approval (r+) when fetching PRs When retrieving unknown PRs, the process would apply all comments, thereby applying eventual r+ without taking in account their relationship to a force push. This means it was possible for a mergebot-unknown PR to be r+'d, updated, retargeted, and the mergetbot would consider it good to go. The possible damage would be somewhat limited but still, not great. Sadly Github simply doesn't provide access to the entire event stream of the PR, so there is no way to even know whether the PR was updated, let alone when in relation to comments. Therefore just resync the PR after having applied comments: we still want to apply the merge method & al, we just want to reset back to un-approved. An other minor fix (for something we never actually hit but could): reviews are treated more or less as comments, but separate at github's level. The job would apply all comments then all reviews, so the relative order of comments and reviews would be wrong. Combine and order comments and reviews so they are applied in (hopefully) the correct order of their creation / submission. Closes #416
2020-11-10 22:13:08 +07:00
assert pr.state == 'validated'
[IMP] runbot_merge: remove "sync PRs", fetch unknown PRs The old "sync pr" thing is turning out to be a bust, while it originally worked fine these days it's a catastrophe as the v4 API performances seem to have significantly degraded, to the point that fetching all 15k PRs by pages of 100 simply blows up after a few hundreds/thousands. Instead, add a table of PRs to sync: if we get notified of a "compatible" PR (enabled repo & target) which we don't know of, create an entry in a "fetch jobs" table, then a cron will handle fetching the PR then fetching/applying all relevant metadata (statuses, review-comments and reviews). Also change indexation of Commit(sha) and PR(head) to hash, as btree indexes are not really sensible for such content (the ordering is unhelpful and the index locality is awful by design/definition).
2018-06-21 14:55:14 +07:00
[FIX] runbot_merge: cancel approval (r+) when fetching PRs When retrieving unknown PRs, the process would apply all comments, thereby applying eventual r+ without taking in account their relationship to a force push. This means it was possible for a mergebot-unknown PR to be r+'d, updated, retargeted, and the mergetbot would consider it good to go. The possible damage would be somewhat limited but still, not great. Sadly Github simply doesn't provide access to the entire event stream of the PR, so there is no way to even know whether the PR was updated, let alone when in relation to comments. Therefore just resync the PR after having applied comments: we still want to apply the merge method & al, we just want to reset back to un-approved. An other minor fix (for something we never actually hit but could): reviews are treated more or less as comments, but separate at github's level. The job would apply all comments then all reviews, so the relative order of comments and reviews would be wrong. Combine and order comments and reviews so they are applied in (hopefully) the correct order of their creation / submission. Closes #416
2020-11-10 22:13:08 +07:00
with repo:
prx.post_comment('hansen r+', config['role_reviewer']['token'])
assert pr.state == 'ready'
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
[FIX] runbot_merge: when fetching a PR, sync closed state If a PR is closed on github and unknown by the mergebot, when fetched it should be properly sync'd as "closed" in the backend, otherwise the PR can get in a weird state and cause issues. Also move the "I fetched the thing" comment before the actual creation of the PR for workflow clarity, otherwise the reader has the impression that the 'bot knew about the PR then fetched it anyway. And improve savepoint management around the fetching: savepoints should be released in all cases. Closes #488.
2021-07-30 14:20:57 +07:00
def test_fetch_closed(self, env, repo, users, config):
""" If an "unknown PR" is fetched while closed, it should be saved as
closed
"""
with repo:
m, _ = repo.make_commits(
None,
Commit('initial', tree={'m': 'm'}),
Commit('second', tree={'m2': 'm2'}),
ref='heads/master')
[c1] = repo.make_commits(m, Commit('first', tree={'m': 'c1'}))
pr = repo.make_pr(title='title', body='body', target='master', head=c1)
env.run_crons()
with repo:
pr.close()
# assume an unknown but ready PR: we don't know the PR or its head commit
to_pr(env, pr).unlink()
env['runbot_merge.commit'].search([('sha', '=', pr.head)]).unlink()
# reviewer reviewers
with repo:
pr.post_comment('hansen r+', config['role_reviewer']['token'])
Fetch = env['runbot_merge.fetch_job']
fetches = Fetch.search([('repository', '=', repo.name), ('number', '=', pr.number)])
assert len(fetches) == 1, f"expected one fetch for {pr.number}, found {len(fetches)}"
env.run_crons('runbot_merge.fetch_prs_cron')
env.run_crons()
assert not Fetch.search([('repository', '=', repo.name), ('number', '=', pr.number)])
assert to_pr(env, pr).state == 'closed'
assert pr.comments == [
seen(env, pr, users),
(users['reviewer'], 'hansen r+'),
[REF] *: move most feedback messages to pseudo-templates Current system makes it hard to iterate feedback messages and make them clearer, this should improve things a touch. Use a bespoke model to avoid concerns with qweb rendering complexity (we just want GFM output and should not need logic). Also update fwbot test setup to always configure an fwbot name, in order to avoid ping messages closing the PRs they're talking about, that took a while to debug, and given the old message I assume I'd already hit it and just been too lazy to fix. This requires updating a bunch of tests as fwbot ping are sent *to* `fp_github_name`, but sent *from* the reference user (because that's the key we set). Note: noupdate on CSV files doesn't seem to work anymore, which isn't great. But instead set tracking on the template's templates, it's not quite as good but should be sufficient. Fixes #769
2023-06-12 19:41:42 +07:00
seen(env, pr, users),
# reviewer is set because fetch replays all the comments (thus
# setting r+ and reviewer) but then syncs the head commit thus
# unsetting r+ but leaving the reviewer
[IMP] runbot_merge: ping commenter when fetching PR due to comment If a comment causes an unknown PR to be fetched, it's a bit odd to ping the author (and possibly reviewer) anyway as they're not super concerned (and technically we could be ignoring the purported / attempted reviewer). So if a fetch job was created because of a comment, remember the comment author and ping *them* instead of using the default ping policy. Fixes #981
2024-11-18 19:52:27 +07:00
(users['user'], f"@{users['reviewer']} I didn't know about this PR and had to retrieve "
[IMP] *: review mergebot & forwardbot messages for pinging Old messages were quite inconsistent in their pinging of the PR author and reviewer. Reviewed messages (probably missed some but...) and try to more consistently ping when the feedback requires some sort of action in order to proceed. Fixes #592
2022-06-23 19:25:07 +07:00
"its information, you may have to re-approve it "
"as I didn't see previous commands."),
[FIX] runbot_merge: when fetching a PR, sync closed state If a PR is closed on github and unknown by the mergebot, when fetched it should be properly sync'd as "closed" in the backend, otherwise the PR can get in a weird state and cause issues. Also move the "I fetched the thing" comment before the actual creation of the PR for workflow clarity, otherwise the reader has the impression that the 'bot knew about the PR then fetched it anyway. And improve savepoint management around the fetching: savepoints should be released in all cases. Closes #488.
2021-07-30 14:20:57 +07:00
]
[FIX] runbot_merge: don't notify on closing unknown PRs If an untracked PR is closed, especially on an inactive or untracked branch, the closer (or author) almost certainly don't care to receive 3 different notifications on the subject. The fix requires a schema change in order to track that we're fetching the PR due to a `closed` event, as in other cases we may still want to notify the user that we received the request (and it just happened to resolve to a closed PR). Fixes #857
2024-03-12 18:17:30 +07:00
def test_close_unknown_unmanaged(self, env, repo, users, config):
"""If an "unknown PR" is *closed*, it should be saved as closed but not
commented on, because that's unnecessary spam.
"""
with repo:
m, _ = repo.make_commits(
None,
Commit('initial', tree={'m': 'm'}),
Commit('second', tree={'m2': 'm2'}),
ref='heads/master')
[c1] = repo.make_commits(m, Commit('first', tree={'m': 'c1'}))
pr = repo.make_pr(title='title', body='body', target='master', head=c1)
env.run_crons()
assert pr.comments == [seen(env, pr, users)]
to_pr(env, pr).unlink()
env['runbot_merge.commit'].search([('sha', '=', pr.head)]).unlink()
with repo:
pr.close()
Fetch = env['runbot_merge.fetch_job']
fetches = Fetch.search([('repository', '=', repo.name), ('number', '=', pr.number)])
assert len(fetches) == 1, f"expected one fetch for {pr.number}, found {len(fetches)}"
env.run_crons('runbot_merge.fetch_prs_cron')
env.run_crons()
assert not Fetch.search([('repository', '=', repo.name), ('number', '=', pr.number)])
assert to_pr(env, pr).state == 'closed'
assert pr.comments == [seen(env, pr, users)]
def test_close_unknown_disabled(self, env, repo, users, config):
"""If an "unknown PR" on an disabled branch is *closed*, it should be
saved as closed but not commented on, because that's unnecessary spam.
"""
with repo:
m, _ = repo.make_commits(
None,
Commit('initial', tree={'m': 'm'}),
Commit('second', tree={'m2': 'm2'}),
ref='heads/master')
[c1] = repo.make_commits(m, Commit('first', tree={'m': 'c1'}))
pr = repo.make_pr(title='title', body='body', target='master', head=c1)
env.run_crons()
assert pr.comments == [seen(env, pr, users)]
to_pr(env, pr).unlink()
env['runbot_merge.commit'].search([('sha', '=', pr.head)]).unlink()
env['runbot_merge.branch'].search([('name', '=', 'master')]).active = False
with repo:
pr.close()
Fetch = env['runbot_merge.fetch_job']
fetches = Fetch.search([('repository', '=', repo.name), ('number', '=', pr.number)])
assert len(fetches) == 1, f"expected one fetch for {pr.number}, found {len(fetches)}"
env.run_crons('runbot_merge.fetch_prs_cron')
env.run_crons()
assert not Fetch.search([('repository', '=', repo.name), ('number', '=', pr.number)])
assert to_pr(env, pr).state == 'closed'
assert pr.comments == [seen(env, pr, users)]
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_rplus_unmanaged(self, env, repo, users, config):
[ADD] runbot_merge: various feedback messages Send reponse comments when users mis-interact with robodoo e.g. send comments they don't have the right to, or commands which don't make sense in the PR's state, or tentative interactions with robodoo from unmanaged PRs.
2018-10-16 17:40:45 +07:00
""" r+ on an unmanaged target should notify about
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
m2 = repo.make_commit(m, 'second', None, tree={'m': 'm', 'm2': 'm2'})
repo.make_ref('heads/branch', m2)
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
prx = repo.make_pr(title='title', body='body', target='branch', head=c1)
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons(
'runbot_merge.fetch_prs_cron',
)
[ADD] runbot_merge: various feedback messages Send reponse comments when users mis-interact with robodoo e.g. send comments they don't have the right to, or commands which don't make sense in the PR's state, or tentative interactions with robodoo from unmanaged PRs.
2018-10-16 17:40:45 +07:00
assert prx.comments == [
(users['reviewer'], 'hansen r+'),
[IMP] runbot_merge: automation around branch deactivation Currently deactivating a branch kinda leaves users in the dark, with little way to know what has happened aside from inferring it from the branch having disappeared from the main dashboard. - surface the state of the branch in the PR dashboard (also surface the target branch at all so users can see if their PR is targeted as they expect as far as the mergebot is concerned) - close & notify every PR to a branch being deactivated - cancel any current staging to the branch (as a consequence of the above) Closes #632
2022-07-29 17:37:23 +07:00
(users['user'], "This PR targets the un-managed branch %s:branch, it needs to be retargeted before it can be merged." % repo.name),
[IMP] *: review mergebot & forwardbot messages for pinging Old messages were quite inconsistent in their pinging of the PR author and reviewer. Reviewed messages (probably missed some but...) and try to more consistently ping when the feedback requires some sort of action in order to proceed. Fixes #592
2022-06-23 19:25:07 +07:00
(users['user'], "Branch `branch` is not within my remit, imma just ignore it."),
[ADD] runbot_merge: various feedback messages Send reponse comments when users mis-interact with robodoo e.g. send comments they don't have the right to, or commands which don't make sense in the PR's state, or tentative interactions with robodoo from unmanaged PRs.
2018-10-16 17:40:45 +07:00
]
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_rplus_review_unmanaged(self, env, repo, users, config):
[ADD] runbot_merge: various feedback messages Send reponse comments when users mis-interact with robodoo e.g. send comments they don't have the right to, or commands which don't make sense in the PR's state, or tentative interactions with robodoo from unmanaged PRs.
2018-10-16 17:40:45 +07:00
""" r+ reviews can take a different path than comments
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
m2 = repo.make_commit(m, 'second', None, tree={'m': 'm', 'm2': 'm2'})
repo.make_ref('heads/branch', m2)
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
prx = repo.make_pr(title='title', body='body', target='branch', head=c1)
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_review('APPROVE', 'hansen r+', config['role_reviewer']['token'])
env.run_crons(
'runbot_merge.fetch_prs_cron',
)
[ADD] runbot_merge: various feedback messages Send reponse comments when users mis-interact with robodoo e.g. send comments they don't have the right to, or commands which don't make sense in the PR's state, or tentative interactions with robodoo from unmanaged PRs.
2018-10-16 17:40:45 +07:00
# FIXME: either split out reviews in local or merge reviews & comments in remote
assert prx.comments[-1:] == [
(users['user'], "I'm sorry. Branch `branch` is not within my remit."),
]
[FIX] runbot_merge: less restrictive commands matching Fixes #167 ignores casing when matching bot name Fixes #168 ignores leading whitespace when matching commands lines
2019-08-26 18:41:33 +07:00
class TestRecognizeCommands:
@pytest.mark.parametrize('botname', ['hansen', 'Hansen', 'HANSEN', 'HanSen', 'hAnSeN'])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_botname_casing(self, repo, env, botname, config):
[FIX] runbot_merge: less restrictive commands matching Fixes #167 ignores casing when matching bot name Fixes #168 ignores leading whitespace when matching commands lines
2019-08-26 18:41:33 +07:00
""" Test that the botname is case-insensitive as people might write
bot names capitalised or titlecased or uppercased or whatever
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
[FIX] runbot_merge: less restrictive commands matching Fixes #167 ignores casing when matching bot name Fixes #168 ignores leading whitespace when matching commands lines
2019-08-26 18:41:33 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c = repo.make_commit(m, 'first', None, tree={'m': 'c'})
prx = repo.make_pr(title='title', body=None, target='master', head=c)
[FIX] runbot_merge: less restrictive commands matching Fixes #167 ignores casing when matching bot name Fixes #168 ignores leading whitespace when matching commands lines
2019-08-26 18:41:33 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[FIX] runbot_merge: less restrictive commands matching Fixes #167 ignores casing when matching bot name Fixes #168 ignores leading whitespace when matching commands lines
2019-08-26 18:41:33 +07:00
assert pr.state == 'opened'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('%s r+' % botname, config['role_reviewer']['token'])
[FIX] runbot_merge: less restrictive commands matching Fixes #167 ignores casing when matching bot name Fixes #168 ignores leading whitespace when matching commands lines
2019-08-26 18:41:33 +07:00
assert pr.state == 'approved'
@pytest.mark.parametrize('indent', ['', '\N{SPACE}', '\N{SPACE}'*4, '\N{TAB}'])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_botname_indented(self, repo, env, indent, config):
[FIX] runbot_merge: less restrictive commands matching Fixes #167 ignores casing when matching bot name Fixes #168 ignores leading whitespace when matching commands lines
2019-08-26 18:41:33 +07:00
""" matching botname should ignore leading whitespaces
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
m, c = repo.make_commits(
None,
Commit('initial', tree={'m': 'm'}),
Commit('first', tree={'m': 'c'}),
)
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
repo.make_ref('heads/master', m)
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
prx = repo.make_pr(title='title', target='master', head=c)
[FIX] runbot_merge: less restrictive commands matching Fixes #167 ignores casing when matching bot name Fixes #168 ignores leading whitespace when matching commands lines
2019-08-26 18:41:33 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[FIX] runbot_merge: less restrictive commands matching Fixes #167 ignores casing when matching bot name Fixes #168 ignores leading whitespace when matching commands lines
2019-08-26 18:41:33 +07:00
assert pr.state == 'opened'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
prx.post_comment(f'{indent}hansen r+', config['role_reviewer']['token'])
[FIX] runbot_merge: less restrictive commands matching Fixes #167 ignores casing when matching bot name Fixes #168 ignores leading whitespace when matching commands lines
2019-08-26 18:41:33 +07:00
assert pr.state == 'approved'
[FIX] runbot_merge: don't warn on unrecognized commands This is a regression due to the implementation details of odoo/runbot#376: previously _parse_command would only yield the commands it had specifically recognised (from a whitelist). 22e18e752b948a0ef2160d584b24fcd77a7a3e3a simplified the implementation and (for convenience when adding new commands) now passes through any command to the executor instead of skipping the unknown one. But I forgot to update the executor to ignore unknown commands, so it treats them as *failed* (since the success flag doesn't get set) and assumes it's an ACL issue, so notifies the user that they can't do the thing they never really asked for. Add an end-case which skips the feedback bit for unrecognized commands, which restores the old behavior. Fixes #390
2020-07-22 16:56:33 +07:00
def test_unknown_commands(self, repo, env, config, users):
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
c = repo.make_commit(m, 'first', None, tree={'m': 'c'})
pr = repo.make_pr(title='title', body=None, target='master', head=c)
pr.post_comment("hansen do the thing", config['role_reviewer']['token'])
pr.post_comment('hansen @bobby-b r+ :+1:', config['role_reviewer']['token'])
env.run_crons()
assert pr.comments == [
(users['reviewer'], "hansen do the thing"),
(users['reviewer'], "hansen @bobby-b r+ :+1:"),
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
seen(env, pr, users),
[ADD] runbot_merge: help command, and help on error Fixes #898
2024-06-25 03:16:43 +07:00
(users['user'], """\
@{reviewer} unknown command 'do'.
For your own safety I've ignored *everything in your entire comment*.
Currently available commands:
|command||
|-|-|
|`help`|displays this help|
|`r(eview)+`|approves the PR, if it's a forwardport also approves all non-detached parents|
|`r(eview)=<number>`|only approves the specified parents|
|`fw=no`|does not forward-port this PR|
|`fw=default`|forward-ports this PR normally|
|`fw=skipci`|does not wait for a forward-port's statuses to succeed before creating the next one|
|`up to <branch>`|only ports this PR forward to the specified branch (included)|
|`merge`|integrate the PR with a simple merge commit, using the PR description as message|
|`rebase-merge`|rebases the PR on top of the target branch the integrates with a merge commit, using the PR description as message|
|`rebase-ff`|rebases the PR on top of the target branch, then fast-forwards|
|`squash`|squashes the PR as a single commit on the target branch, using the PR description as message|
|`delegate+`|grants approval rights to the PR author|
|`delegate=<...>`|grants approval rights on this PR to the specified github users|
|`default`|stages the PR normally|
|`priority`|tries to stage this PR first, then adds `default` PRs if the staging has room|
|`alone`|stages this PR only with other PRs of the same priority|
|`cancel=staging`|automatically cancels the current staging when this PR becomes ready|
|`check`|fetches or refreshes PR metadata, resets mergebot state|
Note: this help text is dynamic and will change with the state of the PR.
""".format_map(users)),
(users['user'], """\
@{reviewer} unknown command '@bobby-b'.
For your own safety I've ignored *everything in your entire comment*.
Currently available commands:
|command||
|-|-|
|`help`|displays this help|
|`r(eview)+`|approves the PR, if it's a forwardport also approves all non-detached parents|
|`r(eview)=<number>`|only approves the specified parents|
|`fw=no`|does not forward-port this PR|
|`fw=default`|forward-ports this PR normally|
|`fw=skipci`|does not wait for a forward-port's statuses to succeed before creating the next one|
|`up to <branch>`|only ports this PR forward to the specified branch (included)|
|`merge`|integrate the PR with a simple merge commit, using the PR description as message|
|`rebase-merge`|rebases the PR on top of the target branch the integrates with a merge commit, using the PR description as message|
|`rebase-ff`|rebases the PR on top of the target branch, then fast-forwards|
|`squash`|squashes the PR as a single commit on the target branch, using the PR description as message|
|`delegate+`|grants approval rights to the PR author|
|`delegate=<...>`|grants approval rights on this PR to the specified github users|
|`default`|stages the PR normally|
|`priority`|tries to stage this PR first, then adds `default` PRs if the staging has room|
|`alone`|stages this PR only with other PRs of the same priority|
|`cancel=staging`|automatically cancels the current staging when this PR becomes ready|
|`check`|fetches or refreshes PR metadata, resets mergebot state|
Note: this help text is dynamic and will change with the state of the PR.
""".format_map(users)),
[FIX] runbot_merge: don't warn on unrecognized commands This is a regression due to the implementation details of odoo/runbot#376: previously _parse_command would only yield the commands it had specifically recognised (from a whitelist). 22e18e752b948a0ef2160d584b24fcd77a7a3e3a simplified the implementation and (for convenience when adding new commands) now passes through any command to the executor instead of skipping the unknown one. But I forgot to update the executor to ignore unknown commands, so it treats them as *failed* (since the success flag doesn't get set) and assumes it's an ACL issue, so notifies the user that they can't do the thing they never really asked for. Add an end-case which skips the feedback bit for unrecognized commands, which restores the old behavior. Fixes #390
2020-07-22 16:56:33 +07:00
]
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
class TestRMinus:
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_rminus_approved(self, repo, env, config):
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
""" approved -> r- -> opened
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c = repo.make_commit(m, 'first', None, tree={'m': 'c'})
prx = repo.make_pr(title='title', body=None, target='master', head=c)
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert pr.state == 'opened'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r+', config['role_reviewer']['token'])
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert pr.state == 'approved'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r-', config['role_user']['token'])
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert pr.state == 'opened'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r+', config['role_reviewer']['token'])
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert pr.state == 'approved'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r-', config['role_other']['token'])
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert pr.state == 'approved'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r-', config['role_reviewer']['token'])
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert pr.state == 'opened'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_rminus_ready(self, repo, env, config):
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
""" ready -> r- -> validated
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c = repo.make_commit(m, 'first', None, tree={'m': 'c'})
prx = repo.make_pr(title='title', body=None, target='master', head=c)
repo.post_status(prx.head, 'success', 'ci/runbot')
repo.post_status(prx.head, 'success', 'legal/cla')
env.run_crons()
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert pr.state == 'validated'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r+', config['role_reviewer']['token'])
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert pr.state == 'ready'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r-', config['role_user']['token'])
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert pr.state == 'validated'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r+', config['role_reviewer']['token'])
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert pr.state == 'ready'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r-', config['role_other']['token'])
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert pr.state == 'ready'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r-', config['role_reviewer']['token'])
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert pr.state == 'validated'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_rminus_staged(self, repo, env, config):
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
""" staged -> r- -> validated
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c = repo.make_commit(m, 'first', None, tree={'m': 'c'})
prx = repo.make_pr(title='title', body=None, target='master', head=c)
repo.post_status(prx.head, 'success', 'ci/runbot')
repo.post_status(prx.head, 'success', 'legal/cla')
env.run_crons()
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
# if reviewer unreviews, cancel staging & unreview
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
st = pr.staging_id
assert st
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r-', config['role_reviewer']['token'])
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert not st.active
assert not pr.staging_id
assert pr.state == 'validated'
# if author unreviews, cancel staging & unreview
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
st = pr.staging_id
assert st
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r-', config['role_user']['token'])
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert not st.active
assert not pr.staging_id
assert pr.state == 'validated'
# if rando unreviews, ignore
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
st = pr.staging_id
assert st
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r-', config['role_other']['token'])
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
assert pr.staging_id == st
assert pr.state == 'ready'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_split(self, env, repo, config):
[FIX] runbot_merge: PR splits should be updated on PR state change On a PR being updated, closed or unreviewed, if it is part of an active staging that staging would get cancelled (yay). However, if the PR was part of a pending *split*, then the split would *not* get cancelled / updated (to remove the PR from it), and the PR could go on to get staged as if everything were right in the world which is an issue. It doesn't look like it actually happened (at least I got no echo of it), but it almost did at least once. fixes #160
2019-07-31 14:20:02 +07:00
""" Should remove the PR from its split, and possibly delete the split
entirely.
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
c = repo.make_commit(m, 'first', None, tree={'m': 'm', '1': '1'})
repo.make_ref('heads/p1', c)
prx1 = repo.make_pr(title='t1', body='b1', target='master', head='p1')
repo.post_status(prx1.head, 'success', 'legal/cla')
repo.post_status(prx1.head, 'success', 'ci/runbot')
prx1.post_comment('hansen r+', config['role_reviewer']['token'])
c = repo.make_commit(m, 'first', None, tree={'m': 'm', '2': '2'})
repo.make_ref('heads/p2', c)
prx2 = repo.make_pr(title='t2', body='b2', target='master', head='p2')
repo.post_status(prx2.head, 'success', 'legal/cla')
repo.post_status(prx2.head, 'success', 'ci/runbot')
prx2.post_comment('hansen r+', config['role_reviewer']['token'])
env.run_crons()
[FIX] runbot_merge: PR splits should be updated on PR state change On a PR being updated, closed or unreviewed, if it is part of an active staging that staging would get cancelled (yay). However, if the PR was part of a pending *split*, then the split would *not* get cancelled / updated (to remove the PR from it), and the PR could go on to get staged as if everything were right in the world which is an issue. It doesn't look like it actually happened (at least I got no echo of it), but it almost did at least once. fixes #160
2019-07-31 14:20:02 +07:00
pr1, pr2 = env['runbot_merge.pull_requests'].search([], order='number')
assert pr1.number == prx1.number
assert pr2.number == prx2.number
assert pr1.staging_id == pr2.staging_id
s0 = pr1.staging_id
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status('heads/staging.master', 'failure', 'ci/runbot')
env.run_crons()
[FIX] runbot_merge: PR splits should be updated on PR state change On a PR being updated, closed or unreviewed, if it is part of an active staging that staging would get cancelled (yay). However, if the PR was part of a pending *split*, then the split would *not* get cancelled / updated (to remove the PR from it), and the PR could go on to get staged as if everything were right in the world which is an issue. It doesn't look like it actually happened (at least I got no echo of it), but it almost did at least once. fixes #160
2019-07-31 14:20:02 +07:00
assert pr1.staging_id and pr1.staging_id != s0, "pr1 should have been re-staged"
assert not pr2.staging_id, "pr2 should not"
# TODO: remote doesn't currently handle env context so can't mess
# around using active_test=False
assert env['runbot_merge.split'].search([])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
# prx2 was actually a terrible idea!
prx2.post_comment('hansen r-', config['role_reviewer']['token'])
[FIX] runbot_merge: PR splits should be updated on PR state change On a PR being updated, closed or unreviewed, if it is part of an active staging that staging would get cancelled (yay). However, if the PR was part of a pending *split*, then the split would *not* get cancelled / updated (to remove the PR from it), and the PR could go on to get staged as if everything were right in the world which is an issue. It doesn't look like it actually happened (at least I got no echo of it), but it almost did at least once. fixes #160
2019-07-31 14:20:02 +07:00
# probably not necessary ATM but...
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[FIX] runbot_merge: PR splits should be updated on PR state change On a PR being updated, closed or unreviewed, if it is part of an active staging that staging would get cancelled (yay). However, if the PR was part of a pending *split*, then the split would *not* get cancelled / updated (to remove the PR from it), and the PR could go on to get staged as if everything were right in the world which is an issue. It doesn't look like it actually happened (at least I got no echo of it), but it almost did at least once. fixes #160
2019-07-31 14:20:02 +07:00
assert pr2.state == 'validated', "state should have been reset"
assert not env['runbot_merge.split'].search([]), "there should be no split left"
[ADD] runbot_merge: support for r- on approved & ready PRs Can be used by the PR author or a reviewer. Removes reviewed state of PR, and cancels the staging if the PR is already staged.
2018-09-25 20:04:31 +07:00
[IMP] runbot_merge: allow invoking bot as @bot and #bot Before this, the bot would only acknowledge commands of the form <botname>: <commands> but since the bot is an actual user, people regularly use `@<botname>` as it seems like it should work *and* provides for autocompletion. Support that, as well as the octothorpe in case users want to pound robodoo. Related to odoo/runbot#38
2018-09-21 15:27:07 +07:00
class TestComments:
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_address_method(self, repo, env, config):
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
[IMP] runbot_merge: allow invoking bot as @bot and #bot Before this, the bot would only acknowledge commands of the form <botname>: <commands> but since the bot is an actual user, people regularly use `@<botname>` as it seems like it should work *and* provides for autocompletion. Support that, as well as the octothorpe in case users want to pound robodoo. Related to odoo/runbot#38
2018-09-21 15:27:07 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
prx = repo.make_pr(title='title', body='body', target='master', head=c1)
[IMP] runbot_merge: allow invoking bot as @bot and #bot Before this, the bot would only acknowledge commands of the form <botname>: <commands> but since the bot is an actual user, people regularly use `@<botname>` as it seems like it should work *and* provides for autocompletion. Support that, as well as the octothorpe in case users want to pound robodoo. Related to odoo/runbot#38
2018-09-21 15:27:07 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
repo.post_status(prx.head, 'success', 'legal/cla')
repo.post_status(prx.head, 'success', 'ci/runbot')
prx.post_comment('hansen delegate=foo', config['role_reviewer']['token'])
prx.post_comment('@hansen delegate=bar', config['role_reviewer']['token'])
prx.post_comment('#hansen delegate=baz', config['role_reviewer']['token'])
[IMP] runbot_merge: allow invoking bot as @bot and #bot Before this, the bot would only acknowledge commands of the form <botname>: <commands> but since the bot is an actual user, people regularly use `@<botname>` as it seems like it should work *and* provides for autocompletion. Support that, as well as the octothorpe in case users want to pound robodoo. Related to odoo/runbot#38
2018-09-21 15:27:07 +07:00
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[IMP] runbot_merge: allow invoking bot as @bot and #bot Before this, the bot would only acknowledge commands of the form <botname>: <commands> but since the bot is an actual user, people regularly use `@<botname>` as it seems like it should work *and* provides for autocompletion. Support that, as well as the octothorpe in case users want to pound robodoo. Related to odoo/runbot#38
2018-09-21 15:27:07 +07:00
assert {p.github_login for p in pr.delegates} \
== {'foo', 'bar', 'baz'}
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_delete(self, repo, env, config):
[FIX] runbot_merge: ignore comment edition & deletion As well as review edition & dismissal. Closes #53
2018-11-26 16:28:27 +07:00
""" Comments being deleted should be ignored
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
[FIX] runbot_merge: ignore comment edition & deletion As well as review edition & dismissal. Closes #53
2018-11-26 16:28:27 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
prx = repo.make_pr(title='title', body='body', target='master', head=c1)
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[FIX] runbot_merge: ignore comment edition & deletion As well as review edition & dismissal. Closes #53
2018-11-26 16:28:27 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
cid = prx.post_comment('hansen r+', config['role_reviewer']['token'])
# unreview by pushing a new commit
repo.update_ref(prx.ref, repo.make_commit(c1, 'second', None, tree={'m': 'c2'}), force=True)
[FIX] runbot_merge: ignore comment edition & deletion As well as review edition & dismissal. Closes #53
2018-11-26 16:28:27 +07:00
assert pr.state == 'opened'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.delete_comment(cid, config['role_reviewer']['token'])
[FIX] runbot_merge: ignore comment edition & deletion As well as review edition & dismissal. Closes #53
2018-11-26 16:28:27 +07:00
# check that PR is still unreviewed
assert pr.state == 'opened'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_edit(self, repo, env, config):
[FIX] runbot_merge: ignore comment edition & deletion As well as review edition & dismissal. Closes #53
2018-11-26 16:28:27 +07:00
""" Comments being edited should be ignored
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
[FIX] runbot_merge: ignore comment edition & deletion As well as review edition & dismissal. Closes #53
2018-11-26 16:28:27 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
prx = repo.make_pr(title='title', body='body', target='master', head=c1)
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[FIX] runbot_merge: ignore comment edition & deletion As well as review edition & dismissal. Closes #53
2018-11-26 16:28:27 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
cid = prx.post_comment('hansen r+', config['role_reviewer']['token'])
# unreview by pushing a new commit
repo.update_ref(prx.ref, repo.make_commit(c1, 'second', None, tree={'m': 'c2'}), force=True)
[FIX] runbot_merge: ignore comment edition & deletion As well as review edition & dismissal. Closes #53
2018-11-26 16:28:27 +07:00
assert pr.state == 'opened'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.edit_comment(cid, 'hansen r+ edited', config['role_reviewer']['token'])
[FIX] runbot_merge: ignore comment edition & deletion As well as review edition & dismissal. Closes #53
2018-11-26 16:28:27 +07:00
# check that PR is still unreviewed
assert pr.state == 'opened'
[IMP] runbot_merge: send feedback when approving PR which failed CI Also add test for it & feedback of an approved PR failing CI, and fix corner case with it (might not send a warning immediately on CI failure depending on status requirement ordering). Fixes #158
2019-07-31 14:19:50 +07:00
class TestFeedback:
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
def test_ci_approved(self, repo, env, users, config):
[IMP] runbot_merge: send feedback when approving PR which failed CI Also add test for it & feedback of an approved PR failing CI, and fix corner case with it (might not send a warning immediately on CI failure depending on status requirement ordering). Fixes #158
2019-07-31 14:19:50 +07:00
"""CI failing on an r+'d PR sends feedback"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
[FIX] *: re-enable notification on status failure If a PR gets approved *then* fails CI, there should be a notification warning the author & reviewer since 48e08b657b23760e6d45f397cf59e7710bc7f89a, it even has a test, which passes (in fact it has *two*, one of which is redundant, so merge `test_ci_failure_after_review` into the later `test_ci_approved`). *However* this is in runbot_merge, turns out in fafa7ef437d75d72e34be91af72e16c52135b7fa some refactoring was done in order to override the notification and customise it for *forward ports* with a failed status... except that override never called its `super()`, so as soon as forwardport is installed the base notification stops working, and that's been that since October 2019 (had been added in March that year, ignoring deployment lag). This can be revealed by adding the corresponding check in the *forwardport* tests, revealing the failure. This was a pain to track down, thankfully it reproduced relatively easily locally. While this could be resolved in the override, might as well fold it into the base method in furtherance of #789: the mergebot is only used by odoo, and only with both modules combined, so splitting them is not useful. And furthermore it things should work fine with the forwardport installed but unused. Fixes #894
2024-06-21 15:27:01 +07:00
[m] = repo.make_commits(None, Commit('initial', tree={'m': 'm'}), ref="heads/master")
[IMP] runbot_merge: send feedback when approving PR which failed CI Also add test for it & feedback of an approved PR failing CI, and fix corner case with it (might not send a warning immediately on CI failure depending on status requirement ordering). Fixes #158
2019-07-31 14:19:50 +07:00
[FIX] *: re-enable notification on status failure If a PR gets approved *then* fails CI, there should be a notification warning the author & reviewer since 48e08b657b23760e6d45f397cf59e7710bc7f89a, it even has a test, which passes (in fact it has *two*, one of which is redundant, so merge `test_ci_failure_after_review` into the later `test_ci_approved`). *However* this is in runbot_merge, turns out in fafa7ef437d75d72e34be91af72e16c52135b7fa some refactoring was done in order to override the notification and customise it for *forward ports* with a failed status... except that override never called its `super()`, so as soon as forwardport is installed the base notification stops working, and that's been that since October 2019 (had been added in March that year, ignoring deployment lag). This can be revealed by adding the corresponding check in the *forwardport* tests, revealing the failure. This was a pain to track down, thankfully it reproduced relatively easily locally. While this could be resolved in the override, might as well fold it into the base method in furtherance of #789: the mergebot is only used by odoo, and only with both modules combined, so splitting them is not useful. And furthermore it things should work fine with the forwardport installed but unused. Fixes #894
2024-06-21 15:27:01 +07:00
[c1] = repo.make_commits(m, Commit('first', tree={'m': 'c1'}))
pr = repo.make_pr(title='title', body='body', target='master', head=c1)
pr.post_comment('hansen r+', config['role_reviewer']['token'])
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] runbot_merge: send feedback when approving PR which failed CI Also add test for it & feedback of an approved PR failing CI, and fix corner case with it (might not send a warning immediately on CI failure depending on status requirement ordering). Fixes #158
2019-07-31 14:19:50 +07:00
[FIX] *: re-enable notification on status failure If a PR gets approved *then* fails CI, there should be a notification warning the author & reviewer since 48e08b657b23760e6d45f397cf59e7710bc7f89a, it even has a test, which passes (in fact it has *two*, one of which is redundant, so merge `test_ci_failure_after_review` into the later `test_ci_approved`). *However* this is in runbot_merge, turns out in fafa7ef437d75d72e34be91af72e16c52135b7fa some refactoring was done in order to override the notification and customise it for *forward ports* with a failed status... except that override never called its `super()`, so as soon as forwardport is installed the base notification stops working, and that's been that since October 2019 (had been added in March that year, ignoring deployment lag). This can be revealed by adding the corresponding check in the *forwardport* tests, revealing the failure. This was a pain to track down, thankfully it reproduced relatively easily locally. While this could be resolved in the override, might as well fold it into the base method in furtherance of #789: the mergebot is only used by odoo, and only with both modules combined, so splitting them is not useful. And furthermore it things should work fine with the forwardport installed but unused. Fixes #894
2024-06-21 15:27:01 +07:00
pr_id = to_pr(env, pr)
assert pr_id.state == 'approved'
for ctx, url in [
('ci/runbot', 'https://a'),
('ci/runbot', 'https://a'),
('legal/cla', 'https://b'),
('foo/bar', 'https://c'),
('ci/runbot', 'https://a'),
('legal/cla', 'https://d'), # url changes so different from the previous
]:
with repo:
repo.post_status(pr_id.head, 'failure', ctx, target_url=url)
env.run_crons()
assert pr.comments == [
[IMP] runbot_merge: send feedback when approving PR which failed CI Also add test for it & feedback of an approved PR failing CI, and fix corner case with it (might not send a warning immediately on CI failure depending on status requirement ordering). Fixes #158
2019-07-31 14:19:50 +07:00
(users['reviewer'], 'hansen r+'),
[FIX] *: re-enable notification on status failure If a PR gets approved *then* fails CI, there should be a notification warning the author & reviewer since 48e08b657b23760e6d45f397cf59e7710bc7f89a, it even has a test, which passes (in fact it has *two*, one of which is redundant, so merge `test_ci_failure_after_review` into the later `test_ci_approved`). *However* this is in runbot_merge, turns out in fafa7ef437d75d72e34be91af72e16c52135b7fa some refactoring was done in order to override the notification and customise it for *forward ports* with a failed status... except that override never called its `super()`, so as soon as forwardport is installed the base notification stops working, and that's been that since October 2019 (had been added in March that year, ignoring deployment lag). This can be revealed by adding the corresponding check in the *forwardport* tests, revealing the failure. This was a pain to track down, thankfully it reproduced relatively easily locally. While this could be resolved in the override, might as well fold it into the base method in furtherance of #789: the mergebot is only used by odoo, and only with both modules combined, so splitting them is not useful. And furthermore it things should work fine with the forwardport installed but unused. Fixes #894
2024-06-21 15:27:01 +07:00
seen(env, pr, users),
(users['user'], "@{user} @{reviewer} 'ci/runbot' failed on this reviewed PR.".format_map(users)),
(users['user'], "@{user} @{reviewer} 'legal/cla' failed on this reviewed PR.".format_map(users)),
(users['user'], "@{user} @{reviewer} 'legal/cla' failed on this reviewed PR.".format_map(users)),
[IMP] runbot_merge: send feedback when approving PR which failed CI Also add test for it & feedback of an approved PR failing CI, and fix corner case with it (might not send a warning immediately on CI failure depending on status requirement ordering). Fixes #158
2019-07-31 14:19:50 +07:00
]
[IMP] fwbot: warning on r+ for failed PR approving a PR which failed CI should trigger a feedback message since 6cb58a322de0fa600f80eee62b0c4eda43113810 (#158), the code has not been removed and the tests still pass. However fwbot r+ would go through its own process for r+ which would explain why that feedback is sometimes gone / lost (cf #327 and #336). * make fwbot r+ delegate to mergebot r+ * add dedicated logging for this operation to better analyze post-mortem * automatically ping the reviewer to specifically tell them they're idiots * move the feedback item out of the state change bit, send it even if it's a useless r+ (because it's already r+'d) * add a test for forward-ports Closes #327, closes #336
2020-03-05 19:31:23 +07:00
def test_review_failed(self, repo, env, users, config):
[IMP] runbot_merge: send feedback when approving PR which failed CI Also add test for it & feedback of an approved PR failing CI, and fix corner case with it (might not send a warning immediately on CI failure depending on status requirement ordering). Fixes #158
2019-07-31 14:19:50 +07:00
"""r+-ing a PR with failed CI sends feedback"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m = repo.make_commit(None, 'initial', None, tree={'m': 'm'})
repo.make_ref('heads/master', m)
[IMP] runbot_merge: send feedback when approving PR which failed CI Also add test for it & feedback of an approved PR failing CI, and fix corner case with it (might not send a warning immediately on CI failure depending on status requirement ordering). Fixes #158
2019-07-31 14:19:50 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
c1 = repo.make_commit(m, 'first', None, tree={'m': 'c1'})
prx = repo.make_pr(title='title', body='body', target='master', head=c1)
[IMP] *: modernise tests via `to_pr` The `to_pr` helper was added a *while* ago to replace the pretty verbose process of looking a PR with the right number in the right repository after a `make_pr`. However while I did some ad-hoc replacement of existing `search` calls as I had to work with existing tests I never did a full search and replace to try and excise searches from the test suite. This is now done. I've undoubtedly missed a few, but a hundred-odd lines of codes have been simplified.
2024-12-02 20:17:28 +07:00
pr = to_pr(env, prx)
[IMP] runbot_merge: send feedback when approving PR which failed CI Also add test for it & feedback of an approved PR failing CI, and fix corner case with it (might not send a warning immediately on CI failure depending on status requirement ordering). Fixes #158
2019-07-31 14:19:50 +07:00
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
repo.post_status(prx.head, 'failure', 'ci/runbot')
env.run_crons()
[IMP] runbot_merge: send feedback when approving PR which failed CI Also add test for it & feedback of an approved PR failing CI, and fix corner case with it (might not send a warning immediately on CI failure depending on status requirement ordering). Fixes #158
2019-07-31 14:19:50 +07:00
assert pr.state == 'opened'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
prx.post_comment('hansen r+', config['role_reviewer']['token'])
[IMP] runbot_merge: send feedback when approving PR which failed CI Also add test for it & feedback of an approved PR failing CI, and fix corner case with it (might not send a warning immediately on CI failure depending on status requirement ordering). Fixes #158
2019-07-31 14:19:50 +07:00
assert pr.state == 'approved'
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
env.run_crons()
[IMP] runbot_merge: send feedback when approving PR which failed CI Also add test for it & feedback of an approved PR failing CI, and fix corner case with it (might not send a warning immediately on CI failure depending on status requirement ordering). Fixes #158
2019-07-31 14:19:50 +07:00
assert prx.comments == [
[CHG] runbot_merge, forwardport: remove labelling Because github materialises every labels change in the timeline (interspersed with comments), the increasing labels churn contributes to PRs being difficult to read and review. This change removes the update of labels on PRs, instead the mergebot will automatically send a comment to created PRs serving as a notification that the PR was noticed & providing a link to the mergebot's dashboard for that PR where users should be able to see the PR state in detail in case they wonder what's what. Lots of tests had to be edited to: - remove any check on the labels of the PR - add checks on the PR dashboard (to ensure that they're at least on the correct "view") - add a helper to handle the comment now added to every PR by the 'bot - since that helper is needed by both mergebot and forwardbot, the utils modules were unified and moved out of the odoo modules Probably relevant note: no test was added for the dashboard ACL, though since I had to explicitly unset the group on the repo used for tests for things to work it looks to me like it at least excludes people just fine. Fixes #419
2020-11-17 21:21:21 +07:00
seen(env, prx, users),
[IMP] runbot_merge: send feedback when approving PR which failed CI Also add test for it & feedback of an approved PR failing CI, and fix corner case with it (might not send a warning immediately on CI failure depending on status requirement ordering). Fixes #158
2019-07-31 14:19:50 +07:00
(users['reviewer'], 'hansen r+'),
[IMP] *: review mergebot & forwardbot messages for pinging Old messages were quite inconsistent in their pinging of the PR author and reviewer. Reviewed messages (probably missed some but...) and try to more consistently ping when the feedback requires some sort of action in order to proceed. Fixes #592
2022-06-23 19:25:07 +07:00
(users['user'], "@%s you may want to rebuild or fix this PR as it has failed CI." % users['reviewer'])
[IMP] runbot_merge: send feedback when approving PR which failed CI Also add test for it & feedback of an approved PR failing CI, and fix corner case with it (might not send a warning immediately on CI failure depending on status requirement ordering). Fixes #158
2019-07-31 14:19:50 +07:00
]
[IMP] *: review mergebot & forwardbot messages for pinging Old messages were quite inconsistent in their pinging of the PR author and reviewer. Reviewed messages (probably missed some but...) and try to more consistently ping when the feedback requires some sort of action in order to proceed. Fixes #592
2022-06-23 19:25:07 +07:00
[FIX] runbot_merge: better handle targets being branch-protected If a staging covers multiple repositories and there's a fast-forward issue on any but the first repo/target, runbot_merge attempted to revert the commits it had fast-forwarded on the previous repos. This doesn't work when branch-protection is active, unless runbot_merge is a repository administrator (and branch protection is not configured to apply to those): reverting is done by push-forcing the original head back onto the ref, which branch-protection unconditionally precludes. This commit does not entirely fix the race condition (it does not look like github provides any way to do that), but it should significantly reduce the race-condition window as it performs a semi-wet run of the fast-forward process on the tmp branches before actually updating the targets. That way the only remaining breakage should be when somebody pushes on repositories 1.. between the test-FF on tmp branches and the actual fast forward. While at it, updated the github API thing to *always* dump the JSON body on an error response, if the content-type is json.
2018-10-10 15:48:42 +07:00
class TestInfrastructure:
[IMP] *: freeze wizard v3, freezer and wizarder Stop *staging* release PRs: they are normally fairly simple and should not fail their staging outside of unreliable tests (or possibly a few edge cases e.g. forgot one version change thing), however staging them creates the possibility of a "version hole" on the release branch which is undesirable. Instead, immediately and unconditionally push the release commits onto the newly created branches, if there are things which don't work they can be fixed afterwards (and the process refined, maybe). Also add the same feature for *bump* PRs, with the difference that the bump PRs are not created / requested by default (they have to be opted in individually). For convenience, add a feature which automatically finds the PRs via inputting the label (not really tested yet). Closes #603
2022-07-11 13:17:04 +07:00
@pytest.mark.skip(reason="Don't want to implement")
[FIX] runbot_merge: better handle targets being branch-protected If a staging covers multiple repositories and there's a fast-forward issue on any but the first repo/target, runbot_merge attempted to revert the commits it had fast-forwarded on the previous repos. This doesn't work when branch-protection is active, unless runbot_merge is a repository administrator (and branch protection is not configured to apply to those): reverting is done by push-forcing the original head back onto the ref, which branch-protection unconditionally precludes. This commit does not entirely fix the race condition (it does not look like github provides any way to do that), but it should significantly reduce the race-condition window as it performs a semi-wet run of the fast-forward process on the tmp branches before actually updating the targets. That way the only remaining breakage should be when somebody pushes on repositories 1.. between the test-FF on tmp branches and the actual fast forward. While at it, updated the github API thing to *always* dump the JSON body on an error response, if the content-type is json.
2018-10-10 15:48:42 +07:00
def test_protection(self, repo):
""" force-pushing on a protected ref should fail
"""
[IMP] *: unify gh test API between runbot and fw-bot The fw-bot testing API should improve the perfs of mergebot tests somewhat (less waiting around for instance). The code has been updated to the bare minimum (context-managing repos, change to PRs and replacing rolenames by explicit token provisions) but extra facilities were used to avoid changing *everything* e.g. make_commit (singular), automatic generation of PR refs, ... The tests should eventually be updated to remove these. Also remove the local fake / mock. Being so much faster is a huge draw, but I don't really want to spend more time updating it, especially when fwbot doesn't get to take advantage. A local / lightweight fake github (as an external service over http) might eventually be a good idea though, and more applicable (including to third-parties).
2019-10-10 14:22:12 +07:00
with repo:
m0 = repo.make_commit(None, 'initial', None, tree={'m': 'm0'})
m1 = repo.make_commit(m0, 'first', None, tree={'m': 'm1'})
repo.make_ref('heads/master', m1)
repo.protect('master')
c1 = repo.make_commit(m0, 'other', None, tree={'m': 'c1'})
with pytest.raises(AssertionError):
repo.update_ref('heads/master', c1, force=True)
[FIX] runbot_merge: better handle targets being branch-protected If a staging covers multiple repositories and there's a fast-forward issue on any but the first repo/target, runbot_merge attempted to revert the commits it had fast-forwarded on the previous repos. This doesn't work when branch-protection is active, unless runbot_merge is a repository administrator (and branch protection is not configured to apply to those): reverting is done by push-forcing the original head back onto the ref, which branch-protection unconditionally precludes. This commit does not entirely fix the race condition (it does not look like github provides any way to do that), but it should significantly reduce the race-condition window as it performs a semi-wet run of the fast-forward process on the tmp branches before actually updating the targets. That way the only remaining breakage should be when somebody pushes on repositories 1.. between the test-FF on tmp branches and the actual fast forward. While at it, updated the github API thing to *always* dump the JSON body on an error response, if the content-type is json.
2018-10-10 15:48:42 +07:00
assert repo.get_ref('heads/master') == m1
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
def node(name, *children):
[REF] forwardport: update re_matches to not use a regex Using a regex as the pattern is quite frustrating due to all the escaping necessary, which in this refactoring I found out I'd missed, multiple times. Convert the pattern to something bespoke but not too complicated, we may want to add anchoring support and a bit more finesse and the future but for now straightforward "holes" seem to work well. I've added support for capturing and even named groups even if this as yet unnecessary and unused. Fixes #861 [^1]: https://docs.pytest.org/en/stable/reference.html#pytest.hookspec.pytest_assertrepr_compare
2024-06-04 17:15:29 +07:00
assert type(name) in (str, matches)
[ADD] runbot_merge: flag to disable rebase before merge rebase-and-merge (or squash-merge if pr.commits == 1) remains default, but there are use cases like forward ports (merge branch X into branch X+1 so that fixes to X are available in X+1) where we really really don't want to rebase the source. This commits implements two alternative merge methods: If the PR and its target are ~disjoint, perform a straight merge (same as old default mode). However if the head of the PR has two parents *and* one of these parents is a commit of the target, assume this is a merge commit to fix a conflict (common during forward ports as X+1 will have changed independently from and incompatibly with X in some ways). In that case, merge by copying the PR's head atop the target (basically rebase just that commit, only updating the link to the parent which is part of target so that it points to the head of target instead of whatever it was previously).
2018-08-29 21:51:53 +07:00
return name, frozenset(children)
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
def log_to_node(log):
log = list(log)
nodes = {}
[ADD] runbot_merge: add tests to try and expose the mystery of staging 13 Staging 13 tried merging 3 PRs (27085, 27083 and 27071) and supposedly succeeded *but* only merged one of the 3 PRs despite marking all three as merged. I tried building a few tests constructing multi-PR graphs and checking them, but the only thing they exposed was the local github implementation not correctly updating merge targets. So fixed that, which is good. Doesn't tell me why the staging didn't work right though.
2018-09-19 22:33:25 +07:00
# check that all parents are present
ids = {c['sha'] for c in log}
parents = {p['sha'] for c in log for p in c['parents']}
missing = parents - ids
assert parents, "Didn't find %s in log" % missing
# github doesn't necessarily log topologically maybe?
todo = list(reversed(log))
while todo:
c = todo.pop(0)
if all(p['sha'] in nodes for p in c['parents']):
nodes[c['sha']] = (c['commit']['message'], frozenset(
nodes[p['sha']]
for p in c['parents']
))
else:
todo.append(c)
[CHG] runbot_merge: toggle default merge method to rebase-and-merge After discussion with al & rco, conclusion was default PR merging method should be rebase-and-merge for cleaner history. Add test for that scenario (w/ test for final DAG) and implement this change.
2018-08-28 20:42:28 +07:00
return nodes[log[0]['sha']]
[ADD] runbot_merge: sign off commits by reviewer closes #50 closes #54
2018-11-22 00:43:05 +07:00
class TestEmailFormatting:
def test_simple(self, env):
p1 = env['res.partner'].create({
'name': 'Bob',
'email': 'bob@example.com',
})
assert p1.formatted_email == 'Bob <bob@example.com>'
def test_noemail(self, env):
p1 = env['res.partner'].create({
'name': 'Shultz',
'github_login': 'Osmose99',
})
assert p1.formatted_email == 'Shultz <Osmose99@users.noreply.github.com>'
Reference in New Issue Copy Permalink