Based in Nantes, France CET/CEST (UTC+1, UTC+2)
Main IRC channel is #wikimedia-releng
html: leave for now, it's not obsolete but nor do I have time to fix anything in there if it's broken, which I expect it is.
html/deploy: skip for now etc.
Nodepool will be phased out eventually over the next 6 months or so. So maybe we can recycle labnodepool1002.eqiad.wmnet? I am not sure it is worth the time to setup a spare for a service that is going to be decommissioned?
In Gerrit, I have granted CI permission to submit patches on operations/dumps and its child.
$ flake8 <(echo "__version__= '$VERSION'") /dev/fd/63:1:12: E225 missing whitespace around operator
The R one due to the compilation.
operations-puppet when doing chown -R nobody /srv/workspace/.cache on labs / docker with overlay FS T178620
The build.py script also build them serially when they could be done in parallel had we had a proper graph of the dependencies.
If operations/software/varnish/libvmod-header is obsolete and you are never going to change it later: we can mark it read-only in Gerrit and add a dummy job in CI to prevent future changes. That is what we do for obsolete MediaWiki extensions.
Really we have better use of our time don't we?
There is at least one that is problematic:
Verified on Popups change https://gerrit.wikimedia.org/r/#/c/145330/
hhvm is not upgraded because the package has origin=Wikimedia and it is not taken in account by unattended-upgrade default configuration.
That is not going to happen. bootstrap-vz does not offer the same liberty plain shell script do.
We can probably get some ideas from https://github.com/mark-adams/docker-chromium-xvfb
I wanted to keep the pseudo TTY allocation, at least to get python/ruby etc to do line based buffering instead of some X KBytes block. That is a little more interactive and get us more accurate time stamps in the Jenkins console.
docker CLI source code is at https://github.com/docker/cli
So maybe we can end up with:
exec docker run --rm -a stdout -a stderr --sig-proxy=true --init
I gave --init a try, aborting the job once it started npm:
15:38:30 + npm install --no-progress 15:38:43 Build was aborted 15:38:43 Aborted by hashar 15:38:43 Archiving artifacts 15:38:43 /tmp/jenkins5713062245415401858.sh: line 10: 4809 Terminated docker run --init --rm --tty --volume "$(pwd)"/log:/log --volume "$(pwd)"/cache:/cache --volume "$(pwd)"/src:/src wmfreleng/npm-test:v2017.11.09.15.15
So I have found an example :)
Lets see how it behaves Monday.
Looks like you have created the instance wikidata-ldf.wikidata-ldf.eqiad.wmflabs. It is apparently mounting the instance extended disk space on /mnt and I would like to get it normalized to use /srv. That is due to the puppet class role::labs::lvm::mnt being applied to it. This task has some instructions to do the migration, but you would also need to adjust any code/settings that refers to /mnt.
So eventually we had a change ending up in Gerrit:
The npm container is based on Jessie. I thought of having npm-browser to extend it, however Chromium is no more updated in Jessie (T170032).
So probably we want npm to be switched to stretch first.
Yes, it's only on group0 wikis for now. https://gerrit.wikimedia.org/r/#/c/386387/ switches the dots to arrows, but it didn't make the train.
+1 +1. So yeah I guess we can switch to wiping the workspace and using a shallow clone. There might be a defaults for that in JJB already :)]
Sounds like that job clones the whole repo and with submodule processing. Which takes a bunch of space for a mediawiki/core patches @ some wmf branch?
Fixed!!! Thanks @Umherirrender
@phuedx yes that might be enough for chromium-render
The snapshot automatically get regenerated at 14:14 UTC. It failed though due to an unrelated issue:
Error: Execution of '/usr/bin/gem install --no-rdoc --no-ri jsduck' returned 1: ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) bad response first byte timeout 503 (https://api.rubygems.org/api/v1/dependencies?gems=jsduck)
Jan and I had a chat yesterday about it.
Solved :) thank you!
Patch https://gerrit.wikimedia.org/r/#/c/389512/ looks good and gets zip installed.
Based on docker ps --no-trunc, there are containers still running for the images:
Looks like gpg --quick-set-expire 1DE8155880C174349E6511971F648D4855B8CF0E 1y only updates the master key but skips sub keys:
$ gpg --list-key --verbose --with-subkey-fingerprint 1DE8155880C174349E6511971F648D4855B8CF0E gpg: using pgp trust model gpg: Note: signature key 22456830196B6FED expired jeu. 19 oct. 2017 21:32:59 CEST pub rsa4096 2016-10-19 [SC] [expires: 2018-11-06] 1DE8155880C174349E6511971F648D4855B8CF0E uid [ unknown] Željko Filipin <email@example.com> uid [ unknown] Željko Filipin <firstname.lastname@example.org> uid [ unknown] [jpeg image of size 5098] sub rsa4096 2016-10-19 [E] [expired: 2017-10-19] C6F65FBE9674DEB336E60B72CEF584C57DF9FBAF sub rsa4096 2016-10-19 [S] [expired: 2017-10-19] 740FF2D9B377A220A68DAD0522456830196B6FED
Php 5.5 is not available on Jessie and CI uses custom packages. The zip extension is available at least:
$ apt-cache policy php5.5-zip php5.5-zip: Installed: (none) Candidate: 5.5.38-4+wmf1+jessie Version table: 5.5.38-4+wmf1+jessie 0 1001 http://apt.wikimedia.org/wikimedia/ jessie-wikimedia/component/ci amd64 Packages
They are already albeit not pinned to a specific version. So whenever rebuilding the package, dh_virtualenv ends up including whatever latest version is available. That might break things.
We haven't reached to each other this week. Jan has set up a checkin for Monday 11/6.
apt-get build-dep hhvm is for the jobs that build the PHP extensions with HHVM. They indeed require a few of hhvm lib**-dev. So we can probably make that a specific container which would be the sole using deb-src?
And for a given image/tag:
It has been upgraded:
docker-registry.wikimedia.org/wikimedia-jessie latest a81cc7ec7998 2 weeks ago 80.4MB docker-registry.wikimedia.org/wikimedia-jessie <none> 6463bc7ce973 12 months ago 79.8MB
Fixed by adding libmysqlclient-dev https://gerrit.wikimedia.org/r/#/c/387728/
Cache is now hold in the Docker container.
I have used a different job to handle the tags.
I have triggered the job against the last merged change https://gerrit.wikimedia.org/r/#/c/388261/
Something got generated at https://doc.wikimedia.org/cumin/master/
Ditto for data-values/value-view https://gerrit.wikimedia.org/r/#/c/388185/
Lets just move it out of mediawiki/extensions namespace. That is T178226
I did the clone with:
Stop forcing php5 in mwscript (https://gerrit.wikimedia.org/r/#/c/358896/). Well we just have to do the switch and see what happens I guess, it is probably just going to work and most probably nobody cared enough to actually do it. But lets stick to T146285
I am fine with https://gerrit.wikimedia.org/r/#/c/358896/ would want to schedule it and have a few people around when it is deployed.