[15:00:46] * legoktm waves [15:01:13] #startmeeting CI weekly checkin [15:01:15] Meeting started Tue Oct 27 15:01:13 2015 UTC and is due to finish in 60 minutes. The chair is hashar. Information about MeetBot at http://wiki.debian.org/MeetBot. [15:01:15] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [15:01:15] The meeting name has been set to 'ci_weekly_checkin' [15:01:23] zeljkof is not around today [15:01:32] meeting conflicts with browser tests weekly triage [15:01:35] legoktm: good morning :-} [15:01:49] morning! [15:01:50] hashar: I am! [15:02:00] but not feeling good :/ [15:02:08] #link https://www.mediawiki.org/wiki/Continuous_integration_meetings/2015-10-20/Minutes Last week minutes [15:02:40] #link https://www.mediawiki.org/wiki/Continuous_integration_meetings/2015-10-27 Agenda (empty) [15:03:11] #topic meeting time for US ... [15:03:17] legoktm: seems you are around and from sf [15:03:43] yes, because of the DST switches this is an hour later for me [15:03:46] for a few months now I have been wondering a better time for this meeting to get folks from SF to join in [15:03:52] turns out 7am PST is not convenient [15:04:20] do you think we could get some people from SF to join? [15:04:50] if it were an hour later like it is this week (8am), I would join. I don't know how early other people wake up though [15:05:35] on Tuesday that conflict with the releng weekly meeting [15:05:49] and that would end up being 6pm-7pm which is rather annoying for me due to family constraints :/ [15:06:09] the only other slot I have is 9pm-10pm europe, which ends up being noon - 1pm in SF [15:06:12] :-/ [15:06:20] :/ that's pretty late for you [15:06:30] at least kids are sleeping usually by 9pm [15:06:44] another way would be for me to have all my meeting on the same day from 5pm to 10pm [15:06:52] and sacrifice an evening worth of familly time [15:07:09] I guess I need to arrange my personal schedule and figure out a .plan [15:07:33] #action hashar to figure out a better time for the meeting to arrange SF or maybe have two checkins: one for europe, another for US [15:07:41] #topic Nodepool status [15:07:49] the usual nodepool progress [15:08:17] #link https://www.mediawiki.org/wiki/Continuous_integration/Entry_points#Ruby Test entry point for Ruby [15:08:23] zeljkof: ^^^ :-} [15:08:39] we now have an official entry point to run gem/bundle/ruby jobs: rake test [15:08:43] with the job 'rake-jessie' [15:08:48] I have migrated mediawiki-vagrant to it [15:08:56] a few more have to be migrated now [15:09:05] hashar: thanks, saw the commits [15:09:08] looks good [15:09:30] we would need to migrate mediawiki_selenium and mediawiki_api gems to it [15:09:38] as well as the various extensions that have browser tests [15:10:21] #link https://phabricator.wikimedia.org/T112560 Disposable VMs need a cache for package managers [15:10:35] that bug is about caching material downloaded by the various package managers [15:10:42] to save bandwidth and download time [15:11:06] reached out to the QA list on thursday but haven't got any reply :-} I am not sure what is the best strategy [15:12:19] oh, about that [15:12:31] I was working on a packagist mitm proxy based on chris's code [15:12:39] ah [15:12:54] #link https://phabricator.wikimedia.org/T116015 Investigate using a Squid based man in the middle proxy to cache package manager SSL connections [15:12:55] to fix the github ratelimiting issue [15:13:05] I did setup a Squid based man in the middle proxy [15:13:13] hashar: nobody showed up for browser tests meeting, but looks like CI hangout is empty too, the meeting is only here? [15:13:19] #link https://github.com/Stype/packagistproxy chris's MITM packagist proxy [15:13:24] Squid has the ability to terminate HTTPS connection and use a self generated certificate [15:13:35] zeljkof: apparently yeah :} [15:13:48] hashar: ok, will lurk then :) thanks [15:14:14] legoktm: seems chris approach is very similar [15:14:33] the mitm works fine for npm/pip [15:14:53] I have a WIP for it to be more as a caching layer than an attacker on my laptop, I'll try and work on it a bit this weekend [15:15:00] with bundler, I have hit a wall though. Could not figure out how to make it trust the self signed cert [15:15:39] packagistproxy might work, what I am afraid of is having to maintain a specific proxy per package management system [15:16:00] python has 'devpi' which works just fine :-} [15:16:06] #link https://phabricator.wikimedia.org/T114871 Evaluate devpi for caching Pypi python packages [15:16:50] another one I found is angry-caching-proxy which supports several package managers, but ends up using http with upstream [15:16:56] #link https://phabricator.wikimedia.org/T112561 Evaluate angry-caching-proxy as a package managers cache [15:17:43] though maybe we can teach angry-caching-proxy to rewrite the HTTP urls requested by client to HTTPS when interacting with the upstream repository [15:17:56] all around [15:18:21] that is more or less blocking the migration of more jobs to Nodepool instances. Specially the npm jobs [15:18:39] so any clue welcome on the QA list [15:19:41] I am out of topics :} [15:21:35] hashar: hi :) [15:21:45] good morning :} [15:22:10] bundler supports setting a mirror which will override the `source` (usually rubygems.org) [15:22:25] http://bundler.io/man/bundle-config.1.html [15:23:43] I described bundler on the task https://phabricator.wikimedia.org/T116015 [15:23:51] SSL_CERT_FILE=/etc/ssl/localcerts/integration.crt http_proxy=. https_proxy=https://`hostname --fqdn`:8081 bundle install --verbose --path vendor/bundle [15:23:51] Network error while fetching https://rubygems.org/quick/Marshal.4.8/rubocop-0.29.1.gemspec.rz [15:23:55] must have failed something [15:25:13] hitting ruby gems ends up redirecting to a CDN https://rubygems.global.ssl.fastly.net [15:25:34] and some SSL / cert madness occurs [15:26:04] so I am still wondering whether we should got with a mitm proxy and suffer from having to deal with self signed certificates [15:26:36] or when changes are merged save the cache to some central place and reuse it on other builds [15:26:54] that was using an http proxy but what about an explicit mirror? [15:27:16] haven't tried [15:27:26] although, maintaining a rubygems mirror might be a bigger PITA [15:27:32] yeah [15:27:54] but I am sure we can eventually figure it out [15:28:05] I haven't spend much time investigating [15:28:16] regardless my next step is to [15:28:33] implement saving/restoring a cache [15:29:14] based on rsync and tweaking package managers configurations to point their cache to something like /home/jenkins/cache/ [15:30:00] marxarelli: legoktm lets follow up on QA list ? [15:30:19] sounds good to me [15:31:00] marxarelli: from before you joined, we have the ruby entry point 'rake test' now: https://www.mediawiki.org/wiki/Continuous_integration/Entry_points#Ruby [15:31:04] I switched mediawiki/Vagrant to it [15:31:13] also gotta figure out a better time for this meeting [15:31:18] to get SF folks to join [15:32:02] sure [15:32:27] ha I had another one [15:32:50] #topic REL1_26 and extensions.json + test entry points [15:33:22] #link https://phabricator.wikimedia.org/T94758 Convert all skins and extensions bundled with the tarball to use extension registration [15:33:37] if we could get all bundled extensions / skins to have proper extension/skin.json that would be nice [15:33:42] apparently the task is almost done [15:34:07] #link https://phabricator.wikimedia.org/T115392 MediaWiki 1.26 bundled repo should be state of the art [15:34:18] that last task is to get composer/npm test on all of them [15:35:19] beside that nothing else to talk about [15:35:28] zeljkof: legoktm marxarelli any topic you wanna bring up? [15:35:57] hashar: sorry, sick for days, brain at 1% [15:36:39] I wanted to talk to whitelisting a little bit [15:36:42] talk about* [15:36:54] Are the new isolated jobs running for all users now? [15:38:39] #topic Zuul whitelisting and Nodepool [15:38:52] legoktm: no. The jobs are still triggered by test: pipeline [15:39:03] though pywikibot got moved last week :-} thanks! [15:39:13] the thing is the instances are one off [15:39:25] but at not really isolated from the other instances [15:40:20] hmm, is that good enough? [15:40:29] or do we have plans to isolate them further? [15:40:40] I think that is good enough [15:40:49] and still want to get them more isolated [15:41:05] one thing I wanted is to restrict network outgress traffic [15:41:17] but wmflabs does not support it (due to the OpenStack network driver we use) [15:42:11] alright [15:42:33] so for now we just add tox-jessie (or whatever?) to the check pipeline? [15:42:42] yup [15:42:51] we can't really use a new pipeline [15:43:00] until jobs in test: can be migrated as well [15:43:04] haven't dealt with composer / Zend 5.3 yet [15:44:10] so repos having composer-test still need the test pipeline :/ [15:45:45] does scaling only work with jessie? [15:45:53] or will it also work for trusty and precise? [15:46:55] nop [15:47:00] only Jessie [15:47:06] legoktm: and we lack PHP Zend 5.3 on Jessie [15:47:28] ideally we would need a way to easily specific the language version we want ( zend53 vs hhvm53 ) [15:47:30] grr [15:47:35] (zend53 vs hhvm ) [15:48:44] yeah...we'd also want same libicu version, etc. [15:49:39] yeah [15:49:52] so I am not willing to open that can of worm right now [15:50:20] if we can get pip/npm/bundler jobs migrated that would be a good first step [15:52:15] legoktm: so in short lets migrate rake/npm/tox first [15:52:23] yeah, sounds good :) [15:52:26] then figure out a way to get Zend 5.3 on the Nodepool machines [15:52:35] and add some system to switch between Zend and HHVM [15:52:41] from there we can migrate a bunch of composer related jobs [15:53:00] for MediaWiki testing, maybe we will end up with specific slaves [15:53:08] that would have the required MediaWiki packages [15:53:30] lets call it an end unless there is some objection :-} I need a short break before next meeting [15:53:32] .. [15:54:22] lets follow up on QA list as needed :-} [15:54:24] #endmeeting [15:54:25] Meeting ended Tue Oct 27 15:54:24 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [15:54:25] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-10-27-15.01.html [15:54:25] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-10-27-15.01.txt [15:54:25] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-10-27-15.01.wiki [15:54:25] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-10-27-15.01.log.html