Relation chains not being maintained through REST API created cherry-picks
54 views
Skip to first unread message
Dan Smith (Qt)
Dec 16, 2024, 5:21:41 AM12/16/24
to Repo and Gerrit Discussion
Hi everyone,
The Qt Project uses a fork [1] of Gerrit 3.8.8 for our code review, and we have a process by which a bot cherry-picks merged changes to other branches. The bot attempts to maintain the relation chain of the original change by setting "base" to the sha of the target parent on the target branch (unmerged in the relevant case). This generally works perfectly well, but I've found that the relation chain is (only sometimes, and inconsistently) not correctly maintained when creating these picks.
Some notes about the Qt workflow:
- We have a plugin which introduces an additional two states: Staged and Integrating, to gate changes for our CI.
- When a change moves from Integrating to Merged, having passed CI, our automation plugin creates a new patchset with the merged (cherry-picked to branch) sha.
- The Cherry-picking bot operates off-server and interacts fully with webhooks and the REST API. When change-merged events are received, the bot does some picking logic to find the correct parent, wait for it on the target branch, and then perform the pick with the target parent's sha on the target branch.
- The pick bot pulls /changes/{changeId}/revisions/{current-1}/related to get the relation chain as it was when the change passed integration (n-1 is required, as the final internal cherry-pick step of moving from integrating -> merged can damage the relation chain).
Our branch and cherry-picking structure looks like:
- dev is the active development branch where new changes are made.
- Numeric branches receive picks in descending order as indicated by a commit message footer on the original change. (F.ex 6.9 -> 6.8 -> 6.5-lts)
- Each cherry-pick to a lower branch is created from the previously picked branch to smooth out the process of backporting changes which hit merge conflicts at any point.
So then, the problem appears when the dev branch's /related query looks correct, and the correct parents ('base') are set for the picks to 6.9. But even though the parenting is pointing to other unmerged changes in the chain using the 'base' parameter, the cherry-picks' /related endpoint on 6.9 returns an empty list. This in turn, means that further picking 6.9 -> 6.8 for example will not have the relation chain data, so each change appears to the bot as being possible to pick with the parent as unspecified/head.
Any ideas on this? I don't see any errors or comments in error_log about the relevant source or target changes. I can't find any correlation between changes which fail to show a relation chain, and I don't see any correlations between problem changes and server performance or anything along those lines.
Best regards,
-Daniel
[1] https://codereview.qt-project.org/c/qtqa/gerrit/+/586035/-1..1
The Qt Project uses a fork [1] of Gerrit 3.8.8 for our code review, and we have a process by which a bot cherry-picks merged changes to other branches. The bot attempts to maintain the relation chain of the original change by setting "base" to the sha of the target parent on the target branch (unmerged in the relevant case). This generally works perfectly well, but I've found that the relation chain is (only sometimes, and inconsistently) not correctly maintained when creating these picks.
Some notes about the Qt workflow:
- We have a plugin which introduces an additional two states: Staged and Integrating, to gate changes for our CI.
- When a change moves from Integrating to Merged, having passed CI, our automation plugin creates a new patchset with the merged (cherry-picked to branch) sha.
- The Cherry-picking bot operates off-server and interacts fully with webhooks and the REST API. When change-merged events are received, the bot does some picking logic to find the correct parent, wait for it on the target branch, and then perform the pick with the target parent's sha on the target branch.
- The pick bot pulls /changes/{changeId}/revisions/{current-1}/related to get the relation chain as it was when the change passed integration (n-1 is required, as the final internal cherry-pick step of moving from integrating -> merged can damage the relation chain).
Our branch and cherry-picking structure looks like:
- dev is the active development branch where new changes are made.
- Numeric branches receive picks in descending order as indicated by a commit message footer on the original change. (F.ex 6.9 -> 6.8 -> 6.5-lts)
- Each cherry-pick to a lower branch is created from the previously picked branch to smooth out the process of backporting changes which hit merge conflicts at any point.
So then, the problem appears when the dev branch's /related query looks correct, and the correct parents ('base') are set for the picks to 6.9. But even though the parenting is pointing to other unmerged changes in the chain using the 'base' parameter, the cherry-picks' /related endpoint on 6.9 returns an empty list. This in turn, means that further picking 6.9 -> 6.8 for example will not have the relation chain data, so each change appears to the bot as being possible to pick with the parent as unspecified/head.
Any ideas on this? I don't see any errors or comments in error_log about the relevant source or target changes. I can't find any correlation between changes which fail to show a relation chain, and I don't see any correlations between problem changes and server performance or anything along those lines.
Best regards,
-Daniel
[1] https://codereview.qt-project.org/c/qtqa/gerrit/+/586035/-1..1
Reply all
Reply to author
Forward
0 new messages