In T360550#9883176, @hashar wrote:

I have tried it live (waiting for the result of a postmerge to complete) and clicking RELOAD fixed it. Additionally the new code is slightly easier/nicer since it does not rely on crawling the DOM to trigger the event from the ChangeView, but instead triggers it directly from document.

I am leaving the task open pending confirmation by another party 🎉

In T360550#9877575, @dancy wrote:

In T360550#9875461, @hashar wrote:

I think that one is fixed now that we have upgraded to Gerrit 3.9.5 and RELOAD does reload the change view!

Hi @hashar. I wasn't able to confirm this for myself. I'm testing with https://gerrit.wikimedia.org/r/c/operations/puppet/+/1041230. I get the "CI has completed checks. Reload the change view? RELOAD/DISMISS" notice, I click RELOAD, and nothing happens.

In T360550#9875461, @hashar wrote:

I think that one is fixed now that we have upgraded to Gerrit 3.9.5 and RELOAD does reload the change view!

Fixed in Reggie v1.12.0.

Resolved as of scap 4.87.0 (deployed today).

Resolved as of scap 4.87.0 (deployed today).

In T366217#9844449, @dancy wrote:

In T366217#9844430, @taavi wrote:

Why does scap not use the same user here it uses to +2 any approved backports?

This is certainly a possibility and would require no additional setup for users. The only downside is that the name of the account (TrainBranchBot) wouldn't match its use for this case.

fix-staging-perms has been fixed. The umask issue is resolved in scap 4.87.0 (deployed today).

@hashar Sorry about the bug. I will fix or revert right away.

In T366217#9864824, @Aklapper wrote:

I guess I also ran into this. I was about to roll back the train for group0 (not using scap backport --revert as that would have also reverted on test servers within group 0 in my understanding), thus following steps on https://wikitech.wikimedia.org/wiki/Backport_windows/Deployers#Reverting .
Last step listed on the page is git push origin HEAD:refs/for/[BRANCH]%topic=revert-[SHA1] which told me that I lack an SSH key

scap 4.85.0 has been deployed with the improvement.

In T366480#9855244, @Tgr wrote:

There is also the possibility of someone trying to use scap on the deploy host of the inactive DC (which does have a git repo at /srv/mediawiki-staging), which should also be prevented. (Maybe it already is, I never tried. But at least in theory, it seems like the more damaging case for using a wrong host.)

Thanks for the report @TheDJ .

In T344730#9846800, @Snwachukwu wrote:

Thanks for the reminder @tchin . Is there some restriction on the gitlab trusted runners repo. I an unable to push to the repo. @tchin @dancy

In T366217#9844430, @taavi wrote:

Why does scap not use the same user here it uses to +2 any approved backports?

It seems like scap backport --revert currently relies on the user having something like the following in their .gitconfig file:

[url "ssh://<username>@gerrit.wikimedia.org:29418/"]
    pushInsteadOf = https://gerrit.wikimedia.org/r/p/
    pushInsteadOf = https://gerrit.wikimedia.org/r/

All is well.

I saw a burst of these today, shortly after rolling the 1.43.0-wmf.7 train to group0. Looks like they come in batches of 6 per request. Each has a different line number in the range 556-578.

@Michael Thanks for investigating!

In T362518#9834634, @Clement_Goubert wrote:

Just to be completely sure before deleting

In T362518#9805179, @dancy wrote:

In T362518#9803705, @Clement_Goubert wrote:

Still left to either remove or rebuild:

• base images

docker-registry.wikimedia.org/docker-gc:1.0.0-20230402              [FAIL]

OK to delete. 1.2.0 is current.

This is replaced by docker-registry.wikimedia.org/repos/releng/docker-gc/docker-gc and I can remove the image that is not in the releng namespace completely?

Regarding

• (main branch) Remove cmd/blubber and cmd/blubberoid interfaces from Blubber

In T346226#9177127, @santhosh wrote:

I did a temporary fix in the repository to unblock CI issue so that we are not blocked by issue https://gerrit.wikimedia.org/r/c/mediawiki/services/machinetranslation/+/958599 - directly call pytest instead of calling via tox.
but black, and ruff checks are not present in it.

docker-registry.discovery.wmnet/repos/releng/blubber/buildkit:v0.23.0 has been published with the changes.

Closing optimistically.

In T289712#9818381, @bd808 wrote:

https://docs.gitlab.com/ee/api/merge_requests.html#unsubscribe-from-a-merge-request

POST /projects/:id/merge_requests/:merge_request_iid/unsubscribe might be the needed magic after adding a note to drop notifications for the bot itself.

I just added a note to https://phabricator.wikimedia.org/T289712#9818356 that may be relevant here:

There's a problem with the method that is used to add mentions to a merge request. When the gitlab-mentions-bot mentions someone in a note, the bot account itself becomes subscribed to the MR and it receives update notifications. That's no good.

There's a problem with the method that is used to add mentions to a merge request. When the gitlab-mentions-bot mentions someone in a note, the bot account itself becomes subscribed to the MR and it receives update notifications. That's no good.

In T327949#9815526, @Jelto wrote:

Sorry for reopening this old task. But it seems during the refactoring of the runner registration (T344951) runner-1030 was converted back to a group runner. So all WMCS runners are group runners for /repos again (see admin menu).

@dancy should we make runner-1030 (or more?) instance-wide again?