fix FIREFOX_153_5_0esr_RELEASE tag in firefox and mozilla-* repos
Categories
(Conduit :: Administration, task, P1)
Tracking
(Not tracked)
People
(Reporter: jcristau, Assigned: shtrom)
References
(Blocks 1 open bug)
Details
Today I had to run the firefox 153.5.0esr ship phase manually to pick up the changes from bug 2046485. The builds however were coming from the FIREFOX_153_5_0esr_BUILD1 revision, from last week, and a number of uplifts landed in between. Due to bug 2081230, git commit f617beaded31d3de1cd5704e47c92811bda116b2 is what ended up being tagged as FIREFOX_153_5_0esr_RELEASE, instead of 223014c6b9299ac9b035b4c50ea481e5c6de282c.
Can we somehow delete the FIREFOX_153_5_0esr_RELEASE tag and re-tag the right revision (223014c6b9299ac9b035b4c50ea481e5c6de282c / FIREFOX_153_5_0esr_BUILD1), and mirror that over to hg?
| Assignee | ||
Updated•22 days ago
|
| Assignee | ||
Comment 1•22 days ago
|
||
I'll preface this by asking if there's any practical way we can move forwards WITHOUT doing this retagging? Could we use a different (new) tag instead?
We probably can, but this is pretty risky stuff, as we don't have a safety net. We've pushed missing tags before https://mozilla-hub.atlassian.net/wiki/spaces/EW/pages/1592754924/Git-Hg-Sync+-+Manually+pushing+a+missing+tag+to+HgMO, but never retagged.
Comment 2•22 days ago
|
||
(In reply to Olivier Mehani [:shtrom] from comment #1)
I'll preface this by asking if there's any practical way we can move forwards WITHOUT doing this retagging? Could we use a different (new) tag instead?
I don't think there's any way we can live with this tag in its current form; there's tools and systems out there that rely on this being accurate. It would be better to have it not exist than to be incorrect IMO.
We might be able to live with it only existing in github seeing as hg is going away in the not too distant future, but even that is likely to cause problems in the near term.
(If it's any consolation, https://bugzilla.mozilla.org/show_bug.cgi?id=2081230 should be fixed very soon and this ought not to happen again...)
| Assignee | ||
Comment 3•22 days ago
•
|
||
Plan:
- Delete tag FIREFOX_153_5_0esr_RELEASE
git tag -d FIREFOX_153_5_0esr_RELEASEand force-push to github - [git-hg-sync worker] delete the (cinnabar) tag
FIREFOX_153_5_0esr_RELEASE, and push to hgmo - Push the correct tag with lando-cli
lando-cli push-tag --lando-repo firefox-esr153 --tag-name FIREFOX_153_5_0esr_RELEASE --tag-sha 223014c6b9299ac9b035b4c50ea481e5c6de282c
The Hg equivalent should be 3806652efdaccfd958d04803eddd3fdf131cd0cd https://hg-edge.mozilla.org/releases/mozilla-esr153/rev/FIREFOX_153_5_0esr_BUILD1
| Assignee | ||
Updated•22 days ago
|
| Assignee | ||
Comment 4•22 days ago
|
||
Will test on infra-testing first, after a sync as per bug 2016626.
| Assignee | ||
Comment 5•22 days ago
|
||
Synced infra-testing, now pushing tags (including incorrect) with
$ git fetch --tags firefox
$ lando push-tag --lando-repo infra-testing-main
| Assignee | ||
Comment 6•22 days ago
|
||
Problem: we don't have the ESR153 tags in infra-testing. Let's create test tags instead.
$ lando push-tag --lando-repo infra-testing-main --tag-name BUG_2081250_CORRECT --tag-sha $(git rev-parse main)
Working on Lando repo infra-testing-main (https://github.com/mozilla-firefox/infra-testing.git)
About to push 1 tags:
- Tag BUG_2081250_CORRECT -> 2623d48083126c0f34255130c7107fd9292982ef
[...]
$ lando push-tag --lando-repo infra-testing-main --tag-name BUG_2081250_INCORRECT_FOR_REAL --tag-sha $(git rev-parse autoland^)
Working on Lando repo infra-testing-main (https://github.com/mozilla-firefox/infra-testing.git)
About to push 1 tags:
- Tag BUG_2081250_INCORRECT_FOR_REAL -> d9b64d74c6037a1fbd997ff800a6dd7d0546b843
Comment 7•22 days ago
|
||
FYI, I'm primarily worried about downstreams building off the wrong revision, which becomes more likely the longer this problem exists. Can we please get this fixed ASAP?
| Assignee | ||
Comment 8•21 days ago
•
|
||
From :zeid
We should be ready to do all the steps on DELETE_ME_3 (delete from hgmo, then GitHub, then git-hg-sync on-disk) and then re-push the same tag with this command:
lando push-tag --lando-repo infra-testing-autoland --tag-name DELETE_ME_3 --tag-sha 416e49d66aacd49d5c51619e1b6d314e3961c8d7
This will move the tag to the prior commit of what it is now. If the above does not cause any issues with git-hg-sync, we can apply those same steps to FIREFOX_153_5_0esr_RELEASE.
| Assignee | ||
Comment 9•21 days ago
|
||
delete from hgmo, then GitHub, then git-hg-sync on-disk
I'd take a slightly different approach: delete in git-hg-sync on disk, and push to HgMO from there.
| Assignee | ||
Comment 10•21 days ago
|
||
Git
[11:03:22] ~/work/tests/infra-testing$ git rev-parse DELETE_ME DELETE_ME_2 DELETE_ME_3
2623d48083126c0f34255130c7107fd9292982ef
2623d48083126c0f34255130c7107fd9292982ef
698f335ff82469ff3b9fb43e30c3288a27c47ad7
[11:03:29] ~/work/tests/infra-testing$ git tag -d DELETE_ME_3
Deleted tag 'DELETE_ME_3' (was 698f335ff8246)
[11:03:37] ~/work/tests/infra-testing$ git push origin :DELETE_ME_3
git-hg-sync-worker
Loosely based on tagging instructions at https://mozilla-hub.atlassian.net/wiki/spaces/EW/pages/1592754924/Git-Hg-Sync+-+Manually+pushing+a+missing+tag+to+HgMO
app@git-hg-sync-worker-0:/clones/infra-testing$ export GIT_AUTHOR_NAME="Olivier Mehani"
app@git-hg-sync-worker-0:/clones/infra-testing$ export GIT_AUTHOR_EMAIL=omehani@mozilla.com
app@git-hg-sync-worker-0:/clones/infra-testing$ export TAGS_BRANCH=tags-testing
app@git-hg-sync-worker-0:/clones/infra-testing$ export HG_REPO=ssh://hg.mozilla.org/conduit-testing/infra-testing
app@git-hg-sync-worker-0:/clones/infra-testing$ git cinnabar tag -d DELETE_ME_3 --onto refs/heads/${TAGS_BRANCH} -m 'Bug 2081250 - delete incorrect tag a=tagging CLOSED TREE DONTBUILD'
app@git-hg-sync-worker-0:/clones/infra-testing$ /entrypoint.sh bash
[...]
app@git-hg-sync-worker-0:/clones/infra-testing$ git push hg::${HG_REPO} ${TAGS_BRANCH}:refs/heads/branches/${TAGS_BRANCH}/tip
At this point, the DELETE_ME_3 tag is no longer present in either the Git or Hg repo.
| Assignee | ||
Comment 11•21 days ago
•
|
||
Retagging
Note that previous test tags failed to sync because they were on main, which is not synced to infra-testing on HgMO (only autoland). This means the commits were non existent, and cinnabar/Hg just silently did not tag them. This led to a fail loop, as “nothing changed” is considered an error when syncing.
[11:59:21] ~/work/tests/infra-testing$ git tag DELETE_ME_3 416e49d66aacd49d5c51619e1b6d314e3961c8d7 # This commit is `autoland^`
[12:01:36] ~/work/tests/infra-testing$ lando push-tag --lando-repo infra-testing-autoland --tag-name DELETE_ME_3 --tag-sha 416e49d66aacd49d5c51619e1b6d314e3961c8d7
Re-tagging fails because the tag already exists in the worker's work repo; this needs to be cleaned-up, too.
Lando workers
- automationworkergit
- landingworkergit
- upliftworkergit
For all relevant repos-branch:
app@lando-automationworkergit-0:/files/repos$ for REPO in infra-testing-*; do git -C $REPO fetch --prune --prune-tags; done
| Assignee | ||
Comment 12•21 days ago
|
||
Re-retagging
Tagging worked and was pushed successfully to the git repo.
BUT the pushlog record choked on a duplicated tag
Failed to record push log due to: duplicate key value violates unique constraint "pushlog_tag_repo_id_name_4564df3a_uniq"
DETAIL: Key (repo_id, name)=(32, DELETE_ME_3) already exists.
So,
- Git is in the desired state, but
- The PushLog only has an entry for the old, undesirable state
We need the Pushlog entry to be in the correct state (i.e., have the tag point to the correct commit) to be able to trigger a sync based on the message.
We'll have to alter the pushlog...
| Assignee | ||
Comment 13•21 days ago
•
|
||
Altering the PushLog
The admin UI purposefully forbids any pushlog modification. Because we should never have to alter it... Right? RIGHT?
$ lando shell
>>> t = Tag.objects.get(repo__name='infra-testing-autoland', name='DELETE_ME_3')
>>> t
Tag(repo=<Repo: infra-testing-autoland@autoland (git)>, name=DELETE_ME_3, commit=Commit 698f335ff82469ff3b9fb43e30c3288a27c47ad7 in infra-testing-autoland@autoland (git))
c = Commit.objects.get(repo__name='infra-testing-autoland', hash='416e49d66aacd49d5c51619e1b6d314e3961c8d7')
>>> c
Commit(repo=<Repo: infra-testing-autoland@autoland (git)>, hash=416e49d66aacd49d5c51619e1b6d314e3961c8d7)
>>> t.commit=c
>>> t
Tag(repo=<Repo: infra-testing-autoland@autoland (git)>, name=DELETE_ME_3, commit=Commit 416e49d66aacd49d5c51619e1b6d314e3961c8d7 in infra-testing-autoland@autoland (git))
>>> t.save()
>>> t.push_set.all()
<QuerySet [Push(push_id=42, repo=infra-testing-autoland@autoland (git))]>
>>> ^D
now exiting InteractiveConsole...
app@lando-web-69469dd95-htgrb:/code$ lando pulse_notify -r infra-testing-autoland -p 42 --force-renotify
That synced correctly!
And the DELETE_ME_3 tag correctly points to the Hg commit that replicate 416e from git https://hg-edge.mozilla.org/conduit-testing/infra-testing/rev/b83b5f2c40a95b699fffd9a0b53995557ae1de46
| Comment hidden (hide) |
| Assignee | ||
Comment 15•21 days ago
•
|
||
Plan
- Tag: FIREFOX_153_5_0esr_RELEASE
- Correct SHA: 223014c6b9299ac9b035b4c50ea481e5c6de282c (git) / 3806652efdaccfd958d04803eddd3fdf131cd0cd (hg)
- Repo: We'll fix the tag on
firefox-esr153/releases/mozilla-esr153. The Git-Hg-sync worker has a sharedtags-unifiedbranch which it updates, and pushes to all repos as new tags target them. By fixing the tag on this branch and rolling forwards, we'll ensure that all repos eventually get the updated tag without conflict.
- [GitHub] Delete incorrect Git Tag:
FIREFOX_153_5_0esr_RELEASEin https://github.com/mozilla-firefox/firefox/tags - [Lando] Clean Lando workers (
landingworkergit,automationworkergit,upliftworkergit):$ cd /files/repos; for REPO in firefox-*; do echo ${REPO}; git -C ${REPO} fetch --prune --prune-tags; done - [Git-Hg-Sync] Delete tag from the
tags-unifiedbranch on thesyncworker-firefoxand push to HgMO
$ cd /clones/firefox
$ export GIT_AUTHOR_NAME="Olivier Mehani"
$ export GIT_AUTHOR_EMAIL=omehani@mozilla.com
$ export TAG=FIREFOX_153_5_0esr_RELEASE
$ export TAGS_BRANCH=tags-unified
$ export HG_REPO=ssh://hg.mozilla.org/releases/mozilla-esr153
$ git cinnabar tag -d ${TAG} --onto refs/heads/${TAGS_BRANCH} -m "Bug 2081250 - delete incorrect tag ${FIREFOX_153_5_0esr_RELEASE} a=tagging CLOSED TREE DONTBUILD"
$ /entrypoint.sh bash
$ git push hg::${HG_REPO} ${TAGS_BRANCH}:refs/heads/branches/${TAGS_BRANCH}/tip
- [Lando] Update lando pushlog: Rename the incorrect entry to avoid unicity conflicts with the updated tag.
$ lando shell
>>> repo_name='firefox-esr153'
>>> tag_name='FIREFOX_153_5_0esr_RELEASE'
>>> t = Tag.objects.get(repo__name=repo_name, name=tag_name)
>>> t.name = t.name + '_BUG_2081250'
>>> t.save()
- [Local] Push correct Git Tag:
lando-cli push-tag --lando-repo firefox-esr153 --tag-name FIREFOX_153_5_0esr_RELEASE --tag-sha 223014c6b9299ac9b035b4c50ea481e5c6de282c.
| Assignee | ||
Comment 16•21 days ago
|
||
Tag deleted from GitHub.
| Assignee | ||
Comment 17•21 days ago
•
|
||
Uplift worker tag deletion done; took ~2 min.
app@lando-upliftworkergit-0:/files/repos$ for REPO in firefox-*; do echo $REPO; git -C $REPO tag | grep FIREFOX_153_5_0esr_RELEASE; done
firefox-beta
firefox-esr115
firefox-esr128
firefox-esr140
firefox-esr153
firefox-release
| Assignee | ||
Comment 18•21 days ago
|
||
Rest of lando workers
Landing worker done:
app@lando-landingworkergit-0:/files/repos$ for REPO in firefox-*; do echo $REPO; git -C $REPO tag | grep FIREFOX_153_5_0esr_RELEASE; done
firefox-autoland
firefox-beta
firefox-esr115
firefox-esr128
firefox-esr140
firefox-esr153
firefox-release
Automation worker done:
$ for REPO in firefox-*; do echo $REPO; git -C $REPO tag | grep FIREFOX_153_5_0esr_RELEASE; done
firefox-autoland
firefox-beta
firefox-esr115
firefox-esr128
firefox-esr140
firefox-esr153
firefox-main
firefox-release
Comment 19•21 days ago
|
||
| uplift | ||
| Assignee | ||
Comment 20•21 days ago
|
||
Tag deleted from esr153 in HgMO https://hg-edge.mozilla.org/releases/mozilla-esr153/rev/4e1820d597eb40c7df578430dd86c2b470f2f7d8
(and I botched the commit message because ${FIREFOX_153_5_0esr_RELEASE} is not ${TAG}, the real variable containing FIREFOX_153_5_0esr_RELEASE. Oh well...
| Assignee | ||
Comment 21•21 days ago
|
||
Pushlog updated
>>> repo_name='firefox-esr153'
>>> tag_name='FIREFOX_153_5_0esr_RELEASE'
>>> t = Tag.objects.get(repo__name=repo_name, name=tag_name)
>>> t
Tag(repo=<Repo: firefox-esr153@esr153 (git)>, name=FIREFOX_153_5_0esr_RELEASE, commit=Commit f617beaded31d3de1cd5704e47c92811bda116b2 in firefox-esr153@esr153 (git))
>>> t.name = t.name + '_BUG_2081250'
>>> t
Tag(repo=<Repo: firefox-esr153@esr153 (git)>, name=FIREFOX_153_5_0esr_RELEASE_BUG_2081250, commit=Commit f617beaded31d3de1cd5704e47c92811bda116b2 in firefox-esr153@esr153 (git))
>>> t.save()
| Assignee | ||
Comment 22•21 days ago
•
|
||
Tag pushed via lando with help from :abutkovits.
It landed correctly on GitHub https://github.com/mozilla-firefox/firefox/tree/FIREFOX_153_5_0esr_RELEASE
However, it did not sync to HgMO:
Tag FIREFOX_153_5_0esr_RELEASE already exists in Cinnabar, skipping for ssh://hg.mozilla.org/releases/mozilla-esr153/...
-> Need to update the cinnabar metadata, then replay the message.
| Assignee | ||
Comment 23•21 days ago
|
||
Hum, no. It went through despite the warnings. This is because the warnings are shown when pushing to more than one branch: the tag is correctly created for the first branch to push, then subsequent branch processing skip creating the tag, as it's already present, but push it nonetheless.
The tag was synced to
- esr153 https://hg-edge.mozilla.org/releases/mozilla-esr153/rev/f6e36402d1c56cc342f0c100d2b79e3859bb7c29
- release https://hg-edge.mozilla.org/releases/mozilla-release/rev/f6e36402d1c56cc342f0c100d2b79e3859bb7c29
- central https://hg-edge.mozilla.org/mozilla-central/rev/f6e36402d1c56cc342f0c100d2b79e3859bb7c29
- beta https://hg-edge.mozilla.org/releases/mozilla-beta/rev/f6e36402d1c56cc342f0c100d2b79e3859bb7c29
and made its way to mozilla-unified https://hg-edge.mozilla.org/mozilla-unified/rev/f6e36402d1c56cc342f0c100d2b79e3859bb7c29
Description
•