I went with throwing an exception in the validation function:

$ pear package-validate
PHP Fatal error:  Uncaught Exception in /usr/share/php/PEAR/PackageFile/v2/Validator.php:60
Stack trace:
#0 /usr/share/php/PEAR/PackageFile/v2.php(1938): PEAR_PackageFile_v2_Validator->validate(Object(PEAR_PackageFile_v2), 3)
#1 /usr/share/php/PEAR/Command/Package.php(388): PEAR_PackageFile_v2->validate(3)
#2 /usr/share/php/PEAR/Command/Common.php(270): PEAR_Command_Package->doPackageValidate('package-validat...', Array, Array)
#3 /usr/share/php/pearcmd.php(316): PEAR_Command_Common->run('package-validat...', Array, Array)
#4 {main}
  thrown in /usr/share/php/PEAR/PackageFile/v2/Validator.php on line 60

Eventually we can revisit after the jobs get migrated to Debian Stretch and a more recent version of pbuilder.

eatmydata is properly installed:

The following additional packages will be installed:
  libeatmydata1 libfakeroot
The following NEW packages will be installed:
  eatmydata fakeroot libeatmydata1 libfakeroot

I have managed to build the package for both jessie and stretch without any issues! :)

My patches are in v0.20.0. I used to have the package build from operations/debs/jenkins-debian-glue which had our fork but it is no more needed.

It is almost down, I could just use files received from rsync to be group writable. That requires a configuration tweak in rsyncd.conf achieved by the chain of patches:

As a past author of a code, there are good chance that you are qualified to be a reviewers. Then I can understand then changing to a new team or shifting interest, the review request is useless and perceived as spam.

I have made the plugin to no more add any reviewers by default (done at All-Projects.git level). So you would no more get spam notifications.

As a follow up (also posted as a comment to J139):

The Gerrit plugin blindly adds reviewers even when in a few cases it might not be appropriate (for a bot account, author of code who is not qualified to do a review, user that is no more active on a repository).

Patch completed and merged in.

And the original JavaScript to do the magic looks like: https://github.com/openstack-infra/system-config/commit/0118d2b4b53cea2641c123a57c14bf8276237f09

From one of the sub tasks I have published a blog explaining the Gerrit review by blame plugin as well as other manual way to find reviewers: J139: Blog Post: Gerrit now automatically adds reviewers. That would help to at least get some reviewers on changes since they are now added automatically by Gerrit.

I have published a blog explaining the Gerrit review by blame plugin as well as other manual way to find reviewers: J139: Blog Post: Gerrit now automatically adds reviewers

I have published a blog explaining the Gerrit review by blame plugin as well as other manual way to find reviewers: J139: Blog Post: Gerrit now automatically adds reviewers

I have published a blog explaining the Gerrit review by blame plugin as well as other manual way to find reviewers: J139: Blog Post: Gerrit now automatically adds reviewers

I had the task closed since we have https://www.mediawiki.org/wiki/Git/Reviewers

Might be related: in Gerrit we have enabled a plugin that adds reviewers based on whom previously touched the affected code. It looks promising based on my first few changes, relevant reviewers got added saving me some time (task was T101131).

For the other issue (wrong username) node-gyp source code has:

./lib/install.js:    log.warn('EACCES', 'user "%s" does not have permission to access the dev dir "%s"', osenv.user(), devDir)

We have python-minimal in a bunch of npm containers:

$ git grep -h python.*minimal dockerfiles/*/Dockerfile.template
# python-minimal for node-gyp
RUN {{ "ruby ruby2.3 ruby2.3-dev rubygems-integration python-minimal build-essential" | apt_install }} \
# python-minimal for node-gyp
RUN {{ "nodejs-legacy python-minimal ruby ruby-dev rubygems-integration build-essential" | apt_install }}
# python-minimal for node-gyp
RUN {{ "nodejs-legacy npm ruby ruby2.1 ruby2.1-dev rubygems-integration python-minimal build-essential" | apt_install }} \
# python-minimal for node-gyp
RUN {{ "nodejs nodejs-legacy ruby ruby2.3 ruby2.3-dev rubygems-integration python-minimal build-essential" | apt_install }} \

To reproduce:

$ docker run --rm -it --entrypoint=bash docker-registry.wikimedia.org/releng/npm-browser-test:0.3.1
$ cd /src
$ git init .
Initialized empty Git repository in /src/.git/
$ git fetch --quiet --depth=1 https://gerrit.wikimedia.org/r/p/mediawiki/extensions/Newsletter
$ git checkout FETCH_HEAD
$ npm install
<error reproduced>

Note the Docker containers are being passed the environment from the host. Some variables are manually blacklisted, they are related to the login command. The env to the container with:

docker run ... --env-file <(/usr/bin/env|egrep -v '^(HOME|SHELL|PATH|LOGNAME|MAIL|HHVM_REPO_CENTRAL_PATH)=')

fibers seems to be a native module which thus requires compilation. That is done using node-gyp which internally relies on python. The actual error:

Changing Build-Depends from python3:any to python3 fixes it. https://gerrit.wikimedia.org/r/#/c/labs/toollabs/+/484772/ reports:

@Paladox

You have to edit your name through wikitech

The plugin version we were using was not compatible yet with Gerrit 2.15. In the previous upgrades we forgot to bump the plugin.

All Jenkins have been upgraded to 2.150.2. Thanks @Dzahn and @thcipriani !

The job has to be refactored and generalized so we can use it on other maven repositories. mwdumper is one such use case ( T213874#4883586 ).

I had some discussions with @Gehel to create and publish proper releases out of maven repositories. The only example we have so far is for analytics/refinery which I have to migrate toward using Docker container T210271, and I think I will refactor those jobs and generalize them to all repositories. So if I am good enough, the end result would be that all maven repositories would result .jar files published to archiva.wikimedia.org.

Bazel provides Debian packages for Java 1.8. Guide: https://docs.bazel.build/versions/master/install-ubuntu.html#install-on-ubuntu

The plugin is going to be bumped by https://gerrit.wikimedia.org/r/#/c/operations/software/gerrit/+/484437/-1..1

From the releng meeting, I have added wikimedia/portals to the list.

I might look at migrating it to a CI Docker container. Longterm it would probably migrate to Blubber / Pipeline / Kubernetes which is T198901

I crafted a very basic container and got something to run with Wikibase. I will craft experimental Jenkins jobs and progress from there :-]

In T210285#4876384, @WMDE-leszek wrote:

@hashar Please do not remove these jobs. Those are daily jobs of Wikibase(Lexeme) extensions which we want to keep. It is true though, those have been red for more than a while. We're working on fixing those failures, to allow us to gradually migrate away from ruby tests to node ones.
It is actually my personal goal for this quarter to get all these daily selenium jobs of Wikibase's green. It is simply embarrassing that we haven't solved those problems for so long.

The patch did:

- login=Iniciar Sesion
+ login=Iniciar sesión

I went with install bazel from their apt package (which is a huge binary blob bah). Then:

$ cd ~/projects/operations/software/gerrit
$ bazel build plugins/reviewers-by-blame:reviewers-by-blame
INFO: Analysed target //plugins/reviewers-by-blame:reviewers-by-blame (142 packages loaded, 3182 targets configured).
INFO: Found 1 target...
Target //plugins/reviewers-by-blame:reviewers-by-blame up-to-date:
  bazel-genfiles/plugins/reviewers-by-blame/reviewers-by-blame.jar
INFO: Elapsed time: 44.699s, Critical Path: 12.04s
INFO: 126 processes: 121 processwrapper-sandbox, 5 worker.
INFO: Build completed successfully, 140 total actions

Good that makes sense :-]

That comes from Grafana webpagereplay-mobile-alerts:

I have moved the part about Wikimedia portals to a standalone task T213806. Although the jobs for each repositories more or less share the same code, the migrations to Docker would most probably be slightly different.

The intent was to migrate to Docker but it was too complicated so I have moved to permanent slaves. Meanwhile I have filled a duplicate task T210286 for the migration out of permanent slaves.

I looked at the history of commits with a tiny script:

#!/usr/bin/python3

Can't we reuse upstream CLI? https://github.com/sensiolabs/security-checker

Amazing, thank you very much for the apache-fast-test test!

I can confirm it is working fine. Thank you.

Cool! Thanks for the confirmation.

The Gemfile uses puppet ~> 4.8.2 which is the version provided by jessie-backports and stretch.

I have upgraded all containers/jobs to containers releng/toxXXXXX:0.3.0. That comes with tox 2.9.1 and the containers also have multiple python versions (from T191764).

[contint1001.wikimedia.org] out: ERROR: image docker-registry.discovery.wmnet/releng/tox-pyspark failed to build, see logs for details. The generated Dockerfile is:

FROM docker-registry.discovery.wmnet/releng/tox:0.3.0

Rebuilding:

https://doc.wikimedia.org/ is now served by doc1001.eqiad.wmnet. integration/docroot is cloned to /srv/docroot.

Looks like it was a transient state that got fixed at some point :)