I didn't find any instances of the deprecated methods being used except for in code for backwards compatibility. Please re-open if I've misinterpreted this or missed something.

In T248779#7032712, @Addshore wrote:

If it helps I can make a WIP gerrit change with some of the integration tests that I currently use on GIthub Actions for the mwdd stuff that should be easy enough to then run in such an environment?

The current HEAD of my dev branch as 2 integration tests, which run as separate jobs on Github Actions.
They each also need a clone of mediawiki that has been composer installed, and a build mwcli binary.
https://github.com/addshore/mwcli/tree/da49f72fd27af07a86e7dcb56e9b1f2200e6d406/.github/workflows/go-ci-integration
The step they run in can ben seen at https://github.com/addshore/mwcli/blob/da49f72fd27af07a86e7dcb56e9b1f2200e6d406/.github/workflows/go-ci.yml#L112-L156 but there isn't all that much going on it in really, just fetching the needed things and then running the script.

Fix merged and errors have dropped off

@Addshore since this task was filed, we started using Qemu for testing for Quibble's end-to-end tests and for Fresh (see T250808: Decide how to run a test involving docker inside WMF CI). I think we could do that for mwcli and its docker sub-commands. cc @hashar

Hi @Vlad.shapik, your help is welcome!

@Legoktm tagging you since I don't know who maintains the mediawiki image on dockerhub and I see you have recently contributed to it on github. Just in case you have any advice!

Some "errors" restarting php-fpm and depooling services popped up while running the train today and it was suggested to mention it here. Here is the stacktrace:

Done in https://gerrit.wikimedia.org/r/c/integration/pipelinelib/+/668245

In case anyone one else comes across this, the network policy doesn't do anything on minikube unless you start minikube with --network-plugin=cni --cni=the cni you will use and then deploy the cni to minikube.

aaah 😵 of course! Thanks @JMeybohm !

This isn't urgent since we removed the helm test part from our pipeline as the readiness probe is doing a similar check.

reverted due to a bug in the related integration/config patch

I don't see this happening currently

Discussed in the sync-up meeting that we may also add the PrivateSettings files into the production docker image as a second build step.

In T271475#6769055, @akosiaris wrote:

It is barely 36K, it definitely fits (limit is 1MB). So it makes perfect sense to have those 6 files in a Secret and mount them on the mw container. The question that arises from my side though is about the UX of deployers, we 'll need to keep it sane. Probably something like the following in the helm chart (with a question mark regarding absolute paths) would allow a similar experience.

apiVersion: v1
kind: Secret
metadata:
  name: very-secret
type: Opaque
data:
{{ (.Files.Glob "bar/*").AsSecrets | indent 2 }}

/extensions/AbuseFilter/02-T223654-api.patch failed to apply for 1.36.0-wmf.32 (conflict on line 28)
As a result the train is blocked, help! :)

I initially didn't want to clutter up the docker-compose file in core, but then thought if most devs need to use MySQL then having it as the default would be good.
So I think either way is fine as long as we make it easy to set up as @DLynch mentioned.

Yes I agree

It turns out that we are creating the xdebug.ini with UID 1000 in the docker image, and that doesn't match up with the uid that we're passing to the mediawiki container, so it fails to enable xdebug. If you remove the user property from the mediawiki service in docker-compose.yml, you should be able to use xdebug (I think encountering other permissions issues might depend on your version of docker for mac).

I am testing with a clean environment on mac now.

@mewoph Did you set XDEBUG_TRIGGER=1 in your request or as an environment variable? (see the Xdebug section in https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/DEVELOPERS.md)

I may have contributed to your confusion by adding local-charts to the Deployment Pipeline Migration Tutorial. If one needed to use a db like Mariadb while testing their k8s service via helm chart or integrate with other charts, it would be useful, but it isn't necessary to use it to work on your service. I will update the tutorial to express that more directly.

I think this would be worth discussing and reaching some agreement on, because yeah I could see how this point (should the configuration live in lots of different repos or in a single one) result in two different tools making more sense.

execute permissions had been removed from the .git directory due to a giant chain of commits for the crm project. It turns out that they weren't properly restored on contint2001. @thcipriani added them back, so we shouldn't encounter this error now.

Sorry that did not help. I think many people (including myself) are currently on vacation, so you might not get more responses until after the new year.

@Yash4357 Have you tried the re-install directions here? There could be a problem with your LocalSettings file that could cause this.

@hashar gave me some info about this, recommending we avoid using -backports if possible. That's because backports will be phased out before buster hits end of life. So we need to get npm 6.14 onto the image another way, like installing the version needed using blubber, or making a new base image.

We've decided to take multiple steps to restrict credentials usage in Jenkins:

To summarize the rest of our meeting on 11/2/2020, we also briefly talked about how to manage the flink part of the image, which is currently downloaded when building with blubber. My and @dduvall's suggestion was to build flink into separate image to use as a base image, but the downsides were that SRE might not have the resources to maintain that image.

I just tried the -- before adding my flags and it worked. I'll add some documentation to the command.