I do think we wind up tweaking runner config more often than I would have expected at first, so this will likely keep coming up.

I imagine it could happen if you copy-paste (or drag-and-drop) the files on one task, then cut-and-paste the {F....} markup into another task.

All I can say definitively at the moment is that this seems to automatically attach files for me when uploaded via the three paths I know about. I can easily imagine that I'm missing something; I'll poke at my dev install and see if I can figure out anywhere this doesn't happen.

A public domain dinosaur test for the copy-and-paste action:

A public domain dinosaur test for the upload button:

Another public domain dinosaur test:

While contint-roots members do now have access to gitlab1003, this doesn't grant access to the runner machines.

I don't have access, so someone else will have to take a closer look.

Currently stable on all wikis.

Per discussion, let's go ahead and soft-block the train on T311119: All Wikimedia projects other than Wikipedia, Test Wikipedia, and Wikinews extremely zoomed out while using Vector Skin on iPad.. It sounds like this should not hold the train too late, but would ideally get fixed before promoting to all wikis. I can roll forward during US working hours if needed.

Check on the mic:

This is another relatively fast update of code and restart of PHP / phd / apache2. Includes no database migrations, etc.

Hand merged separately. I do not know how to Differential.

I am aware of the severity of the issue. We have a fix; I will get it deployed as soon as I can manage.

Tested with copy-and-paste, drag-and-drop, and the upload button. Works as expected.

Re-registered by adding:

It looks to me like I missed adding the results of bin/celerity map when tagging this release. From my CLI history, it did get run:

Good catch! One thought is maybe a bin/celerity run is needed somewhere in the chain here? Will dig into this.

Stable at all wikis for a couple of hours. Optimistically resolving.

• Upstream notes: https://secure.phabricator.com/T13683
  • Upstream [[https://secure.phabricator.com/T13682|T13682 Improve Remarkup file reference attachment behaviors after removal of "attach by default"

Thanks for fix!

From other task:

@sbassett: With that patch merged, this should take effect once runners are re-registered. I can probably get to that after train.

Bit slammed at the moment but this probably dupes T310535: GitLab runners: allowed_images patterns need to be loosened to include subdirectories.

Blocking on T310747.

These continue in 1.39.0-wmf.16.

Noting T310742: Editing tasks results in "You cannot add more than 0 objects to the relationship" error here - if you need to add a blocker task before we get that fix out, please mark it UBN and mention here. I'll track manually.

Well, I think I landed this. It's present on wmf/stable. I do not understand the arc workflow, but per docs it seems like the thing to do now is close this.

Remove bogus .arclint change.

Ok, think I have a patch:

Guessing we inadvertently broke this during recent Phabricator upgrade? Should update docs at wikitech:Phabricator/Deployment if so.

Thanks much all. @Krinkle, that writeup is a thing of beauty and possibly should be taught as a class on debugging cache issues.

Marked as a blocker and cherry-picked https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/805361; sorry, am in meetings so can't deploy for you.

Cloud runner version of above change: https://gitlab.wikimedia.org/repos/releng/gitlab-cloud-runner/-/merge_requests/3

Noting from IRC:

Added everyone on Content Transform I could find a current user account for as owners: MSantos, ihurbain, Jgiannelos. Others will need to first log in to GitLab, and then can be added to the group by one of the existing owners.