In T292094#7443050, @brennen wrote:

My current understanding is that only users with Developer-level access to the project are allowed to run jobs:

https://docs.gitlab.com/ee/user/permissions.html#job-permissions

I think, however, I need to build a working example of exactly what happens here. I'll call that out as a next step here.

It looks like the ffmpeg arguments are wrong for the requested screen size - 1280x1024 is taller than 1366x768 so it can't capture a 1024 pixel height.

@Sj I am one of the founding members of the forge project and I've been nominally working with them upstream, though I haven't put a lot of time into it yet.

Thanks for the confirmation!

Can anyone confirm if this is still happening?

The revert seems to have resolved this issue.

Indeed it's blocked but getting unblocked soon I hope?

This is a straightforward and simple bugfix.

Thanks for the fix!

More than a year too late but...

the link is missing the project phid.. Example the 5 weeks link should look like:

So one thing I think that we need is the equivalent to the "gerrit patches" table that shows up in phabricator for any gerrit patches tagged with Bug: Tnnn I suppose we could use the exact same convention, we just need a way to query gitlab for matching MRs...

So the containers will be running in a VM environment, no? And we can ensure that they restore to a snapshot or known-good baseline before testing a new patch? If we limit the absolute resource usage of the virtual machine and ensure a clean wipe/reset after each run then I think that root escape would have minimal real impact? Am I missing something?

If there’s an error or the request times out, the pipeline is accepted.

In T263166#7389233, @daniel wrote:

I plan to submit a more detailed proposal to the Tech Decision Forum shortly.

Mark all new users as "External" and have a process for unchecking the box. In some ways this may be simplest, but don't really like it - it's just a bad user experience, as you can't create new projects even under your own user when marked external, and last I tried this it wasn't at all obvious why.

This might be a good candidate for early adoption / migration to gitlab?

I think that many of the upstream docker images should be fine, for instance, images maintained by trustworthy organizations / open source projects. I don't know if there is a way to allow a list of blessed images / orgs with some kind of allow-list but that would also require extra maintenance work.

In T263166#7370542, @Legoktm wrote:

Broadly:

• SRE-level stuff, like server hostnames should be in etcd for ease of automation
• releng-level stuff, like which wiki is in which group or which wiki is on which release, which extensions are loaded: probably Git, so it goes through CI and can be diffed and blamed
• basic wiki configuration tasks, currently by sysadmins or trusted users but really should and can be managed through on-wiki interfaces and stored in MySQL.

I think we should also try to move away from loading all configuration during initialization, and defer stuff that's needed only for specific features or endpoints until it's actually needed.

In T291593#7382666, @Aklapper wrote:

Will there be a pop-up what these symbols mean when hovering with a mouse? (I'd like to reduce the amount of potential confusion / support questions.)

build is now green: https://gitlab.wikimedia.org/releng/ddd/-/pipelines

@Jpita: It's not deployed yet.

I can't make much sense of what that specific event would trigger an @mention but there are other @mentions in the thread, perhaps it's just an off-by-one error?

Hmm, perhaps it's hitting a memory limit or something? The limit shouldn't be a problem with such a small file though (unless it's doing something incredibly inefficient.)

Deployed https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/721312

I can attest to seeing a huge spike in errors.

In T288956#7355968, @DannyS712 wrote:

Maybe we should notify wikitech-l about this? I would tag as user-notice but this isn't for tech news

I've disabled the herald rule.

hmmm, well needs triage is the highest possible priority besides unbreak now. Medium is the same as "no prioritization" in my mind, but maybe others think of it differently.

@DannyS712: sure, I'll write a quick notice to the list.

In T285232#7355412, @Joe wrote:

at the end of the day it seems to me that we only have these symlinks for historical reasons and we don't really want people to use them anymore.

I don't think it makes sense that in-progress tasks would "need triage." therefore I added the above herald rule: If setting a task to in progress without setting the priority, it'll get set to medium priority automatically. Should that be high priority or is that a bad idea to have the herald rule prioritize it?