Fri, Apr 30
Wed, Apr 21
Tue, Apr 20
Picking this back up in the context of MW-on-K8s work. Basically we want the ability to build an image in one PipelineLib stage and use that as a base image in a subsequent stage. The unconditional attempt to create users for each subsequent use of a Blubber built image as a base currently makes this impossible.
Apr 13 2021
Apr 8 2021
Looks similar to T273101: Accessing WikiPage that cannot exist as a page: w:Help:Books/Book creator text. [Called from WikiPage::exists] though that was from WikiPage::exists and extensions/Collection. This is from VisualEditor/API and Article::newPage.
Apr 7 2021
I've updated the job on releases-jenkins. I guess we'll see if it works next week.
Marking UBN as I plan on blocking until this is resolved.
Not quite UBN for now and I haven't rolled back on account of it, but this needs more eyeballs.
Thanks for that, @Ladsgroup!
Apr 6 2021
If we're auto +2'ing, does the branch cut change still need to go through review? I ask because branch.py already has a --no-review option which could skip that process entirely.
Apr 5 2021
Mar 31 2021
Reviving this as a Yak Shaving task involving 2-3 people over the course of a full day. Implementation idea:
Mar 30 2021
Mar 25 2021
The existing .pipeline/config.yaml was extended to patch the production image before publishing to the restricted repo. See T271274: Security patch workflow for MediaWiki on k8s and associated patchsets for implementation details.
Mar 23 2021
Mar 18 2021
Mar 15 2021
Mar 12 2021
Success! I was able to build and push an image via docker-pusher on releases1002 to the restricted path (docker-registry.wikimedia.org/restricted/mediawiki-multiversion:2021-03-11-213947-production). Thanks for your hard work on this, @Legoktm
Mar 11 2021
We hadn't yet merged a patchset to integration/config that was thought to be independent. However, the yaml and groovy job definition in integration/config is what defines the global whitelist which includes SONAR_API_KEY.
Another option might just be to set an http_proxy environment variable in mediawiki-config's .pipeline/config.yaml. It seems apt-get will respect that for all of its http transfers. @Legoktm does that seem reasonable?
Notes from #mw-on-k8s for one possible solution.
Mar 10 2021
Yes! Thanks so much for the fix.
From @Marostegui in IRC: "To be honest, I would do it in different steps, set db06, make sure all is fine and the slave replicates just fine. And once that is fully ok, then proceed with marxarelli's plan"
Forgot the UNLOCK TABLES on db07 :)
Thanks for the help, everyone. I would still like to get off of db06 if possible at the end of this process since we have to finish the buster upgrade at some point anyhow. If we can get both db07 and db08 to reach the same point in the binlog from db06, can we simply:
The current status of this is:
Mar 9 2021
Mar 5 2021
Can you elaborate on your use case a bit? Blubber doesn't have any git-specific features currently (though you can run any ad hoc builder command you like). It sort of assumes the same context as does a docker build command, namely that you have some filesystem hierarchy already prepared locally and wish to copy files in and run commands against them to build artifacts and configure stuff.
Mar 1 2021
In other words, override the value of this secret for releases hosts with the new credentials.
Feb 25 2021
Feb 23 2021
Feb 19 2021
Reopening and categorizing as logspam since we're still seeing this albeit infrequently.