Page MenuHomePhabricator

scap backport: Multiple changes found for Ifb0316256bdec5008acc48544ddd3e2bf71b6d41
Closed, ResolvedPublic

Description

When trying to backport a few patches at once, an error was triggered:

[urbanecm@deploy1002 ~]$ scap backport 858313 858308 858309 858310 858311 858312
14:30:02 Checking whether changes are in a branch and version deployed to production...
14:30:02 Checking for relation chains and Depends-Ons...
14:30:02 Change '858313' validated for backport
14:30:02 Checking for relation chains and Depends-Ons...
14:30:02 Change '858308' validated for backport
14:30:02 Checking for relation chains and Depends-Ons...
14:30:02 Change '858309' validated for backport
14:30:02 Checking for relation chains and Depends-Ons...
14:30:03 Status: 404
14:30:03 Multiple changes found for Ifb0316256bdec5008acc48544ddd3e2bf71b6d41

14:30:03 Unhandled error:
Traceback (most recent call last):
  File "/var/lib/scap/scap/lib/python3.7/site-packages/scap/cli.py", line 522, in run
    exit_status = app.main(app.extra_arguments)
  File "/var/lib/scap/scap/lib/python3.7/site-packages/scap/plugins/backport.py", line 110, in main
    self._do_backport(change_numbers, change_details)
  File "/var/lib/scap/scap/lib/python3.7/site-packages/scap/plugins/backport.py", line 129, in _do_backport
    self._validate_backports(change_details, change_numbers)
  File "/var/lib/scap/scap/lib/python3.7/site-packages/scap/plugins/backport.py", line 411, in _validate_backports
    self._validate_dependencies(detail, change_numbers)
  File "/var/lib/scap/scap/lib/python3.7/site-packages/scap/plugins/backport.py", line 429, in _validate_dependencies
    deps.update(self._get_depends_ons(project_branch_id, change_number))
  File "/var/lib/scap/scap/lib/python3.7/site-packages/scap/plugins/backport.py", line 468, in _get_depends_ons
    deps.update(self._get_depends_ons(dep_change_id, dep_change_number))
  File "/var/lib/scap/scap/lib/python3.7/site-packages/scap/plugins/backport.py", line 456, in _get_depends_ons
    depends_ons = self.gerrit.depends_ons(change_id).get()
  File "/var/lib/scap/scap/lib/python3.7/site-packages/scap/plugins/gerrit.py", line 174, in get
    return self.load(res)
  File "/var/lib/scap/scap/lib/python3.7/site-packages/scap/plugins/gerrit.py", line 192, in load
    "Request Failed: %s %s %s" % (res.url, res.status_code, res.text)
Exception: Request Failed: https://gerrit.wikimedia.org/r/changes/Ifb0316256bdec5008acc48544ddd3e2bf71b6d41/revisions/current/crd 404 Multiple changes found for Ifb0316256bdec5008acc48544ddd3e2bf71b6d41

14:30:03 backport failed: <Exception> Request Failed: https://gerrit.wikimedia.org/r/changes/Ifb0316256bdec5008acc48544ddd3e2bf71b6d41/revisions/current/crd 404 Multiple changes found for Ifb0316256bdec5008acc48544ddd3e2bf71b6d41

[urbanecm@deploy1002 ~]$

Ifb0316256bdec5008acc48544ddd3e2bf71b6d41 is https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/858313/, and I'm not sure which other change scap could confuse it with.

Details

TitleReferenceAuthorSource BranchDest Branch
test-scap-backport shared change_id testsrepos/releng/train-dev!10jhuneidiT323277main
Scap backport: Request dependencies for a specific changerepos/releng/scap!72jhuneidiT323277master
Customize query in GitLab

Event Timeline

FTR, that API URL indeed complains about multiple changes:

[urbanecm@deploy1002 ~]$ curl https://gerrit.wikimedia.org/r/changes/Ifb0316256bdec5008acc48544ddd3e2bf71b6d41/revisions/current/crd
Multiple changes found for Ifb0316256bdec5008acc48544ddd3e2bf71b6d41
[urbanecm@deploy1002 ~]$

It does so for other changes as well, and scap backport 858308 858309 858310 858311 858312 (without the 858313 one) worked fine earlier.

It does so for other changes as well, and scap backport 858308 858309 858310 858311 858312 (without the 858313 one) worked fine earlier.

It definitely did work (see ie. https://sal.toolforge.org/log/k-_whYQB8Fs0LHO5UM5A), but after the sixth patches fixed, re-running the five-patches version didn't work. Resorted to running sync-world manually.

Tgr subscribed.

The patch has a cherry-pick, cherry-picks have the same change ID.

It's not that uncommon for a depndency of a backport to itself have a backport. The script should probably just check that the dependency exists and is merged on the same branch when that is the case. (It should not check the branch when there is only one changeset with that ID, though. It could be a config change etc. with a different branch structure.)

Hi @thcipriani and other Relengers, could this be prioritized please? Currently, this means for some changes, the deployer needs to fallback to an old deployment mode.

Ideally all operations scap performs on a change should be made using the change number (e.g. 858308) only.

Ideally all operations scap performs on a change should be made using the change number (e.g. 858308) only.

Dependencies are specified by change ID, so that can't really be helped. Scap will have to get a list of all changesets with that change ID, check whethe they are in train-deployed repos, and if so, select the one(s) in the same branch(es) as the changeset(s) passed to scap backport.

Or maybe just leave it to the user to backport the dependencies with separate scap backport calls, and ask for manual confirmation that that happened (or check via git but that seems more fragile).

Or maybe just leave it to the user to backport the dependencies with separate scap backport calls, and ask for manual confirmation that that happened (or check via git but that seems more fragile).

AFAIK, once a change has a dependency with a backport, scap backport fails even with a single change specified. I had to fetch said change manually and do a scap sync-world instead.

jeena changed the task status from Open to In Progress.Feb 8 2023, 9:28 PM
jeena claimed this task.

Or maybe just leave it to the user to backport the dependencies with separate scap backport calls, and ask for manual confirmation that that happened (or check via git but that seems more fragile).

AFAIK, once a change has a dependency with a backport, scap backport fails even with a single change specified. I had to fetch said change manually and do a scap sync-world instead.

As it is now, scap backport should work to backport changes with a dependency as long as you specify the dependency, for example: scap backport changeno dependencyno.

MR above modifies the depends_on check to request dependecies for a change_id in a specific project & branch to avoid the multiple changes error. This functionality existed previously but was removed in a refactor (oops), so I added a comment to make sure it doesn't happen again, but maybe best to add a test for this.

Fixes were deployed in scap 4.37.0