Sorry for the above comments from patchdemobot. Please disregard.

We've done a live fix on production to restore the edit page until we are able to deploy again.

Ohh, I didn't see the increased timeout, sorry!!

Thanks for flagging this. I have a MR incoming but unfortunately we can't deploy it until gitlab trusted runners can connect to the docker registry again.

@jnuche I recall that failures were timeouts while streaming logs, not an actual failure to create the environment, but looking over the changes, it seems like we're just attempting to create a new environment. I thought we'd attempt to stream logs one more time, or wait a little longer and check if the environment was running.

What about DonationInterface? Do we need to wait on anything for that?

Can someone confirm this is no longer blocking the train?

Note for debuggers: I was able to get the error message to show up hacking on my local version (not connected to auth), so I suspect there is a case where the error is getting overwritten after the user is logged out.

Hi @Bewfip, we have started performing some new checks on your signed in user account: https://lists.wikimedia.org/hyperkitty/list/patchdemo@lists.wikimedia.org/thread/CQYHTP6ISYJJVYAFGLF5JFLVMQY6ZLW4/

In T432617#12142406, @taavi wrote:

Neither the linked task in Reason nor the parent task really explain to me what you are planning to use these resources for or how you ended up on these specific numbers.

In T426130#12126523, @Danielyepezgarces wrote:

I don't have a specific one in mind right now, but it would be good if it were easy to configure, so that once someone has a feed ready, it can be set up before accepting it into production

@Danielyepezgarces is there a specific feed we should add to the allowlist settings for this?

@neriah this task is waiting on some other work we have yet to complete, but we intend to add this feature.

The purpose of this additional test is to exercise running against a mediawiki deployment using the mw ci chart and not the aw ci chart, right?

Using k8s we can only create egress network policies on the pod level, so any policy we make would also apply to the mediawiki container (https://kubernetes.io/docs/concepts/services-networking/network-policies/). For container only options, we might need to use a service mesh.

In T424411#11863468, @vaughnwalters wrote:

In T424411#11863441, @jeena wrote:

Oh, awesome!! Is there a phab task I can link to this one? Yes please do CC me on the changes when they land on gerrit.

This is the task: T423330
I just uploaded it to gerrit and added you

@jeena do you think this in the AC sounds correct for a next step or way of thinking about this after you update the wikilambda tests in gerrit?
create new file in jjb to run daily visual editor tests (and soon others) against ephemeral catalyst environments

I'm not sure on whether you need a new file or just a new job definition, like in jjb/mediawiki-extensions.yaml?

Yeah, I'm not sure either I was thinking about something like jjb/mediawiki-catalyst-daily.yaml so it's easy to see what runs on catalyst daily as more extensions onboard onto this and it might make following the patterns easier. But adding into mediawiki-extensions.yaml works too, will do whatever you and the catalyst team think is best. I want to add Visual Editor and then shortly after Campaign Events and just watch them for a while.

Oh, awesome!! Is there a phab task I can link to this one? Yes please do CC me on the changes when they land on gerrit.

Create backwards compatible changes to catalyst (deploy_env.py ) to be able to accept other charts besides wikifunctions (currently wikifunctions chart is hardcoded

This is already done! See here. I am in the middle of updating Wikilambda tests to use this. I'll cc you on the changes when I send them to gerrit.

It might be nice to also allow them to see the previous run's logs if available.

This is fixed now:
https://gitlab.wikimedia.org/repos/test-platform/catalyst/catalyst-ci-client/-/jobs/798170