Change Details

With the onset of #mw-on-k8s, running a user script takes much longer. This isn't a huge problem since you can run these scripts sequentially, but with the EmailAuth reset flow that T&S runs, it means a new job is created for every reset, which can be quite a lot of resets at one time. Example logs to show the issue: ``` ⏳ Starting resetUserEmail.php on Kubernetes as job mw-script.codfw.f00b4r ... 👋 Refreshing the local Helm cache... 🚀 Job is running. 📜 Streaming logs: Done! ⏳ Starting resetUserEmail.php on Kubernetes as job mw-script.codfw.f00b4z ... 👋 Refreshing the local Helm cache... 🚀 Job is running. 📜 Streaming logs: Done! [and repeat 50+ times] ``` Moving to a script that allows multiple resets should allow for fewer k8s jobs to be created (and thus less noise in the logs) as well as saving some time for support staff working on these resets.

With the onset of #mw-on-k8s, running a user script takes much longer. This isn't a huge problem since you can run these scripts sequentially, but with the EmailAuth reset flow that T&S runs, it means a new job is created for every reset, which can be quite a lot of resets at one time. Example logs to show the issue (the scripts we run look like: `mwscript-k8s -f -- resetUserEmail.php --wiki enwiki 'Foobar' example@example.com --email-password`) ``` ⏳ Starting resetUserEmail.php on Kubernetes as job mw-script.codfw.f00b4r ... 👋 Refreshing the local Helm cache... 🚀 Job is running. 📜 Streaming logs: Done! ⏳ Starting resetUserEmail.php on Kubernetes as job mw-script.codfw.f00b4z ... 👋 Refreshing the local Helm cache... 🚀 Job is running. 📜 Streaming logs: Done! [and repeat 50+ times] ``` Moving to a script that allows multiple resets should allow for fewer k8s jobs to be created (and thus less noise in the logs) as well as saving some time for support staff working on these resets.

With the onset of #mw-on-k8s, running a user script takes much longer. This isn't a huge problem since you can run these scripts sequentially, but with the EmailAuth reset flow that T&S runs, it means a new job is created for every reset, which can be quite a lot of resets at one time. Example logs to show the issue: (the scripts we run look like: `mwscript-k8s -f -- resetUserEmail.php --wiki enwiki 'Foobar' example@example.com --email-password`) ``` ⏳ Starting resetUserEmail.php on Kubernetes as job mw-script.codfw.f00b4r ... 👋 Refreshing the local Helm cache... 🚀 Job is running. 📜 Streaming logs: Done! ⏳ Starting resetUserEmail.php on Kubernetes as job mw-script.codfw.f00b4z ... 👋 Refreshing the local Helm cache... 🚀 Job is running. 📜 Streaming logs: Done! [and repeat 50+ times] ``` Moving to a script that allows multiple resets should allow for fewer k8s jobs to be created (and thus less noise in the logs) as well as saving some time for support staff working on these resets.