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

I've added the api token to the ultraviolet repo

In T419188#11729689, @Sportzpikachu wrote:

Just had a quick look at function-orchestrator, and wondering if this is correct:

• add the include: component: ...
• add catalyst-deploy and catalyst-cleanup to stages:
• if we add a depends: catalyst-deploy to our test stage, we can use $MW_SERVER_URL (?)
  • how will we get the username/pass, or is this static per chart?
• we add a depends: vitest to catalyst-cleanup so it tears down automatically

Thanks very much!

I found the helm values for catalyst-api still had the old default and were overwriting the changes I made to the schedule in catalyst-api

The cleanup job should be running hourly, though, so those environments should have been cleaned up. We should look into that.

The environment which got cleaned up, 4943, was from the previous failed job in that pipeline. 4945 was created when the job was retried. After the first job failure, catalyst-cleanup ran and deleted 4943. When the job was retried, 4945 was created, but since catalyst-cleaup already passed once, it didn't run again. I looked into possibly getting it to run again after retry of the deploy job, but I haven't found any gitlab-ci configuration to do this. There might be a hack around this if we really want the subsequent jobs to run again. In any case, I did a test and a manual rerun of catalyst-cleanup would have deleted 4945.

Thank you @Zabe!

Will backporting https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1248011 unblock the train? I can do that now if it's ready. I see it has a +1.

Yes, that's correct. I remember having a conversation about it so when I saw this task I thought there must be another task for it, but I don't see one.

The timeout period is 2 minutes, which seems generous to me.

It looks like the environments for wikilambda ci that aren't getting cleaned up are those that did not get a response from catalyst in the appropriate amount of time. When the request to catalyst create times out, then we don't get an environment ID back from catalyst, so even though the post build script has been running, it can't delete the environment.

related: https://phabricator.wikimedia.org/T416391

I have archived the documentation page so now we can remove the chart.

I would like to remove the chart from the repo. I'm wondering if the tutorial needs updating or archiving?

@Catrope, I updated our install image to use node 22 and was able to create a demo with a codex patch. Can you confirm the issue is resolved?

Resolving since we used your suggestion when implementing wikifarms in Patch Demo. Thanks!

Since the empty space on the end is taken up during deployment, maybe it would be better like this:

Here is one idea:

CloudPirates mariadb helm chart:
According to https://www.cloudpirates.io/en/about they have been around since 2021. The helm chart was created in August and updated 3 days ago. The CloudPirates helm charts project has 18 contrubutors.

• Mariab offers a kubernetes CRD (https://github.com/mariadb-operator/mariadb-operator), which can be used to define a mariadb instance. It was created in 2022 and is an active project with 66 contributors and the latest release on Aug. 8. Since it’s supported by mariadb itself I think we can put our confidence in its continued maintenance and stability. Releases are well documented with regards to upgrading for breaking changes, which has happened a few times in the past year.