Page MenuHomePhabricator

scap backport check prevents using it to fix an about-to-be-live branch
Closed, ResolvedPublic

Description

Scenario: After rolling a new train branch 1.40.0-wmf.1 to testwikis, errors were seen that resulted in rollback to 1.39.0-wmf.28. A fix was eventually prepared for 1.40.0-wmf.1 and I tried to use scap backport to merge, pull, and (effectively no-op) deploy it.

dancy@deploy1002:~$ scap backport https://gerrit.wikimedia.org/r/c/mediawiki/core/+/831985
18:09:32 Checking whether changes are in a branch and version deployed to production...
18:09:32 Change '831985' branch '1.40.0-wmf.1' not valid for any deployed wikiversion. Deployed wikiversions: ['1.39.0-wmf.28']

If a change's target branch is checked out but not live, scap backport should print a warning and ask the operator if they want to proceed anyway.

Details

TitleReferenceAuthorSource BranchDest Branch
Add test case for backporting to checked-out but non-live branchrepos/releng/scap!214dancymaster-Ied68b1f040c96b7716273898d9a2c1d3941207b2master
deploy/scripts/scap-prep-mw-branches: Create old-version filerepos/releng/train-dev!34dancyreview/dancy/create-old-versions-filemain
scap backport: Enhance handling of checked-out but not live branchesrepos/releng/scap!208sandeepsmaster-I708f0ebceef31af43208ad3f9a4f6305c5fb2149master
Customize query in GitLab

Event Timeline

what about having it do everything except sync if it's not deployed anywhere?

what about having it do everything except sync if it's not deployed anywhere?

Yeah, that sounds good (after some interactive prompt asking the operator if that is what they want).

thcipriani renamed this task from scap backport sanity check prevents using it to fix an about-to-be-live branch to scap backport check prevents using it to fix an about-to-be-live branch.Jun 9 2023, 9:11 PM

Just tested this and as it works currently, It will continue to merge and deploy as directed by the user, but will fail with an error if the branch is not staged.

Just tested this and as it works currently, It will continue to merge and deploy as directed by the user, but will fail with an error if the branch is not staged.

oh, so this one is done?

No, I think it should skip the sync step instead of fail if the branch is not staged.

Sandeeps changed the task status from Open to In Progress.Jan 9 2024, 8:56 PM

I ran this scenario in train-dev today and the behavior has changed since this ticket was filed:

debian@deploy:~$ scap backport 101
18:48:51 Checking whether requested changes are in a branch deployed to production and their dependencies valid...
18:48:51 Change '101', project 'mediawiki/core', branches '['wmf/1.41.0-wmf.5']' not found in any deployed wikiversion. Deployed wikiversions: ['1.41.0-wmf.4']
Continue with Backport? (y/n): y
18:49:11 Change '101' validated for backport
The following changes are scheduled for backport:
+-----+---------+------------------+-------------------------+
|   # | Project |      Branch      | Subject                 |
+-----+---------+------------------+-------------------------+
| 101 |   core  | wmf/1.41.0-wmf.5 | test commit for T317795 |
+-----+---------+------------------+-------------------------+
Backport the changes? (y/n): y
18:49:13 Voting on 1 change(s)
18:49:13 Change 101 approved
18:49:13 Waiting for changes to be merged. This may take some time if there are long running tests.
18:49:19 awaiting-backport-merges: 100% (ok: 1; fail: 0; left: 0)
18:49:19 All changes have been merged
18:49:19 Collecting commits to deploy...
18:49:19 Fetching new changes...
remote: Counting objects: 5, done
remote: Finding sources: 100% (3/3)
remote: Total 3 (delta 2), reused 3 (delta 2)
Unpacking objects: 100% (3/3), done.
From http://gerrit.traindev:8080/mediawiki/core
   7efb584961..151432896f  wmf/1.41.0-wmf.5 -> origin/wmf/1.41.0-wmf.5
18:49:19 Collecting commit for Ic7864c95521b8582052b7692b266dcc7d62c96a0...
18:49:20 Unhandled error:
Traceback (most recent call last):
  File "/workspace/scap/scap/cli.py", line 542, in run
    exit_status = app.main(app.extra_arguments)
  File "/workspace/scap/scap/plugins/backport.py", line 314, in main
    self._do_backport()
  File "/workspace/scap/scap/plugins/backport.py", line 353, in _do_backport
    self._confirm_commits_to_sync()
  File "/workspace/scap/scap/plugins/backport.py", line 981, in _confirm_commits_to_sync
    repo_commits = self._collect_commit_fingerprints()
  File "/workspace/scap/scap/plugins/backport.py", line 950, in _collect_commit_fingerprints
    repo_commits[repo_location].add(commit)
KeyError: '/srv/mediawiki-staging/php-1.41.0-wmf.5'
18:49:20 backport failed: <KeyError> '/srv/mediawiki-staging/php-1.41.0-wmf.5'

dancy updated https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/214

Add test case for backporting to checked-out but non-live branch

sandeeps merged https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/208

scap backport: Enhance handling of checked-out but not live branches

dancy closed https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/214

Add test case for backporting to checked-out but non-live branch