A little bit more than one hour to do the conversion. That is easier than expected!

We had a generic task to add shellcheck to Wikimedia CI at T148494

A few years later, this an effort to run shell scripts validation via T254480 including scripts generated through .erb templates.

We have plenty of disk space.

And we have a test to ensure that they use composer: cef9feb370f62118b7e8cc9460e3e98e877e2520

All BlueSpice repositories are now using the composer flavor of jobs (via extension-quibble-composer).

The typo is in RelPath\\joinPath

I am not sure what the task was about.

Excellent, thank you very much ;)

In T236689#5846956, @Legoktm wrote:

In T236689#5611791, @hashar wrote:

I went to Fabric website ( https://get.fabric.io/ ) which states:

Fabric will be deprecated on March 31, 2020. New users should start in Firebase

Uh, wrong fabric. We use https://www.fabfile.org/

I have looked at the given build and the dim ansi sequence seems good now:

Filed at https://github.com/doxygen/doxygen/issues/7832

Perfect! So from now on, you just have to Code-Review +2 and CI will take care of running the defined tests and ultimately get the change merged if everything is fine. Happy hacking!

Well done @RhinosF1 ;)

I have just found out that Debmonitor now also crawls docker-registry.wikimedia.org . An example is the doxygen package https://debmonitor.wikimedia.org/packages/doxygen

@awight I have reviewed the changes as well as some pending open hotfixes, but ended up reverting a couple changes. That seems the easiest to restore Quibble working state and let us cut a new release.

Looks good to me now. We have been lucky to have both puppet master blocked on a merge conflict!

The one on beta fails because of a missing etcd::autogen_pwd_seed. I have made a dummy
puppet patch in hieradata/cloud/eqiad1/deployment-prep/common.yaml

I have:

• disabled puppet agent on both puppet master
• rebased /var/lib/git/operations/puppet on both puppet master.

On both, I have made a copy to /var/lib/git/labs/private-back

and of course now it no more happens :-\

Another example choking on view/src/EditSectionGenerator.php

#0  tcache_get (tc_idx=9) at malloc.c:2934
#1  __GI___libc_malloc (bytes=153) at malloc.c:3042
#2  0x00005569d27cf47c in QCString::LSData::create (size=<optimized out>) at ./qtools/qcstring.h:492
#3  QCString::StringRep::StringRep (this=0x7ffcc3ad3b80, 
    str=0x5569d6a0e1d0 "\nReturns HTML allowing to edit label, description and aliases.\n\n@param string $languageCode\n@param EntityId|null $entityId\n\n@return string HTML\n")
    at ./qtools/qcstring.h:492
#4  0x00005569d29309f5 in QCString::QCString (str=<optimized out>, this=0x7ffcc3ad3b80) at ./qtools/qcstring.h:161
#5  detab (refIndent=<synthetic pointer>: <optimized out>, s=...) at ./src/markdown.cpp:2535
#6  processMarkdown (fileName=..., lineNr=<optimized out>, e=<optimized out>, input=...) at ./src/markdown.cpp:2572
#7  0x00005569d2932844 in processMarkdownForCommentBlock (comment=..., fileName=..., lineNr=lineNr@entry=25) at ./src/markdown.cpp:2606
#8  0x00005569d2abb94b in handleCommentBlock (yyscanner=0x5569d4b0ec80, doc=..., brief=false) at scanner.l:7028
#9  0x00005569d2abea30 in scannerYYlex (yyscanner=0x5569d4b0ec80) at ./qtools/qcstring.h:161
#10 0x00005569d2ae164e in parseCompounds (yyscanner=0x5569d4b0ec80, rt=...) at scanner.l:7216
#11 0x00005569d2ae16d9 in parseCompounds (yyscanner=0x5569d4b0ec80, rt=...) at scanner.l:7230
#12 0x00005569d2ae1fb0 in parseMain (filesInSameTranslationUnit=..., sameTranslationUnit=<optimized out>, rt=std::shared_ptr<class Entry> (use count 1, weak count 0) = {...}, 
    fileBuf=<optimized out>, fileName=0x5569d56216a8 "/src/view/src/EditSectionGenerator.php", yyscanner=0x5569d4b0ec80) at scanner.l:7314
#13 COutlineParser::parseInput (this=<optimized out>, fileName=0x5569d56216a8 "/src/view/src/EditSectionGenerator.php", fileBuf=<optimized out>, 
    root=std::shared_ptr<class Entry> (use count 1, weak count 0) = {...}, sameTranslationUnit=<optimized out>, filesInSameTranslationUnit=...) at scanner.l:7436
#14 0x00005569d279ede2 in parseFile (parser=..., root=std::shared_ptr<class Entry> (use count 1, weak count 0) = {...}, fd=0x5569d4dd0420, fn=<optimized out>, sameTu=<optimized out>, 
    filesInSameTu=...) at ./qtools/qcstring.h:595
#15 0x00005569d27b8cd6 in parseFiles (root=std::shared_ptr<class Entry> (use count 1, weak count 0) = {...}) at ./qtools/qcstring.h:595
#16 0x00005569d27ca2fa in parseInput () at ./src/doxygen.cpp:10860
#17 0x00005569d277c079 in main (argc=1, argv=0x7ffcc3ad48a8) at ./src/main.cpp:37

One that fails on Parsing file /src/view/lib/resources.test.php...

#0  tcache_get (tc_idx=9) at malloc.c:2934
#1  __GI___libc_malloc (bytes=161) at malloc.c:3042
#2  0x000055738e16747c in QCString::LSData::create (size=<optimized out>) at ./qtools/qcstring.h:492
#3  QCString::StringRep::StringRep (this=0x7fff78b75de0, 
    str=0x557392c7e1c0 "\n\\copyright GPL-2.0-or-later\n@author Daniel Werner < daniel.a.r.werner@gmail.com >\n@author H. Snater < mediawiki@snater.com >\n\n@codeCoverageIgnoreStart\n")
    at ./qtools/qcstring.h:492
#4  0x000055738e2c89f5 in QCString::QCString (str=<optimized out>, this=0x7fff78b75de0) at ./qtools/qcstring.h:161
#5  detab (refIndent=<synthetic pointer>: <optimized out>, s=...) at ./src/markdown.cpp:2535
#6  processMarkdown (fileName=..., lineNr=<optimized out>, e=<optimized out>, input=...) at ./src/markdown.cpp:2572
#7  0x000055738e2ca844 in processMarkdownForCommentBlock (comment=..., fileName=..., lineNr=lineNr@entry=3) at ./src/markdown.cpp:2606
#8  0x000055738e45394b in handleCommentBlock (yyscanner=0x557390d2ec80, doc=..., brief=false) at scanner.l:7028
#9  0x000055738e456a30 in scannerYYlex (yyscanner=0x557390d2ec80) at ./qtools/qcstring.h:161
#10 0x000055738e479f43 in parseMain (filesInSameTranslationUnit=..., sameTranslationUnit=<optimized out>, rt=std::shared_ptr<class Entry> (use count 2, weak count 0) = {...}, 
    fileBuf=<optimized out>, fileName=0x557392c74a08 "/src/view/lib/resources.test.php", yyscanner=0x557390d2ec80) at scanner.l:7301
#11 COutlineParser::parseInput (this=<optimized out>, fileName=0x557392c74a08 "/src/view/lib/resources.test.php", fileBuf=<optimized out>, 
    root=std::shared_ptr<class Entry> (use count 2, weak count 0) = {...}, sameTranslationUnit=<optimized out>, filesInSameTranslationUnit=...) at scanner.l:7436
#12 0x000055738e136de2 in parseFile (parser=..., root=std::shared_ptr<class Entry> (use count 1, weak count 0) = {...}, fd=0x557390fe8aa0, fn=<optimized out>, sameTu=<optimized out>, 
    filesInSameTu=...) at ./qtools/qcstring.h:595
#13 0x000055738e150cd6 in parseFiles (root=std::shared_ptr<class Entry> (use count 1, weak count 0) = {...}) at ./qtools/qcstring.h:595
#14 0x000055738e1622fa in parseInput () at ./src/doxygen.cpp:10860
#15 0x000055738e114079 in main (argc=1, argv=0x7fff78b76a08) at ./src/main.cpp:37

And it failed again. I have filed a new task T254465

I have switched the Jenkins job to use 1.8.18.

Container rebuild and I have switched the Jenkins jobs to Doxygen 1.8.18

To retain the quick blue CR+2, we need Verified to be at max score.

From stylelint 7.6.0 changelog:

Fixed: the string and verbose formatters now use dim instead of gray for greater compatibility with different terminal color schemes.

I had the plugin updated on May 6th from 0.6.2 to 0.6.3 T233688

I have no idea how the token has been generated for T248387

For history purpose, from which account the Github token got generated? Is that from one of our shared github accounts or a personal one? I am asking in case we have to regenerate it somehow.

Partitions on contint1001 have changed. It used to have a secondary volume group with a 250G volume mounted at /mnt/docker. That followed up the addition of two extra SSD that went with their own lvm group T207707

T200739 is for Gerrit 2.16.x . This task is for 3.x

The group has been created in 2015 by @Ottomata

I have archived the repository in Github and deactivated the one in Diffusion.

That could be the subject of a nice debate: When do we close a task?

The last use was for integration/docroot / T224591 . The services have been migrated to contint2001 which uses Buster and php7, we will reimage contint1001 next week. So I guess we are all set and there is no need to keep this task open an extra week.

A quick and dirty fix is https://github.com/mika/jenkins-debian-glue/pull/233 :]

The Jenkins xunit plugin embeds a bunch of XSD files https://github.com/jenkinsci/xunit-plugin/tree/master/src/main/resources/org/jenkinsci/plugins/xunit/types

I should have mentioned it. 2.0.0 is a breaking change, the plugin now passes the xml through schema validation https://plugins.jenkins.io/xunit/

That broke some reports. The debian glue jobs run lintian and has a script to generate a junit xml such as:

<testsuite time="0" tests="1" failures="0" skipped="0" errors="0" assertions="0">
   <testcase name="lintian-checks" classname="lintian.<all>" assertions="0" time="0"/>
</testsuite>

We use docker run ... | tee log/rake.log which has two issues:

In T253723#6170328, @Pablo-WMDE wrote:

1.8.18 is out

Went there to check if you actually filed an upstream ticket. The word "crash" actually appears twice in the change log so maybe someone found it before us.

Doxygen 1.8.17 has a bunch of issues, notably on Wikibase. T253723 has some details and gdb stacktraces.

Doxygen 1.8.18 is out. I rebuild a package and I have confirmed the issue no more occurs inside the same Docker container. Guess I will fill a task / rebuild etc. Sorry for the annoyance.

None of that explains why it crashes in the Docker container while that works just fine on my local machine :-\

Crafted a container with gdb added to it and with the package having the debug symbols

FROM docker-registry.wikimedia.org/releng/doxygen:0.7.0

The Doxygen package published on apt.wikimedia.org and used in docker-registry.wikimedia.org/releng/doxygen:0.7.0 is broken somehow. It crashes when generating documentation for mediawiki/extensions/Wikibase with errors such as:

I went to some arbitrary commit from the past and it worked fine. With git bisect the issue comes from: 9c2cc04e28f8dffe0e230c2f3d2c1f01afbc46b2

*   [BAD] e450192e11 - (HEAD -> master) Merge "WikibaseValueFormatterBuilders: inject specialized services" (8 days ago) <jenkins-bot>
|\  
| * [GOOD] 9c2cc04e28 - WikibaseValueFormatterBuilders: inject specialized services (13 days ago) <Jakob Warkotsch>
* |   [GOOD] 704ccc8368 - Merge "FP: Allow descriptions in ApiPrefetchingTermLookup" (8 days ago) <jenkins-bot>

Repro:

$ cd mediawiki/extensions/Wikibase
$ git rev-parse HEAD
af206ee5d88f82a5dcfc2cd9b289eb3171e12210
$ docker run --rm -it --entrypoint=doxygen --workdir /src --user=$UID -v "$(pwd):/src" docker-registry.wikimedia.org/releng/doxygen:0.7.0
...
Parsing file /src/repo/WikibaseRepo.datatypes.php...
corrupted size vs. prev_size

I forgot about having the data synchronized ahead of the maintenance window which caused a 2 hours delay. We then had to fight with file permissions changes introduced by rsync. Eventually the service got switched and seems operational now. I will continue monitoring but I am guessing it will be fine from now on.

I have deleted both tags.

In T252310#6168492, @Xqt wrote:

Now verify always fails if the parent isn't master but another patch set which isn't merged already. For example
https://gerrit.wikimedia.org/r/#/c/pywikibot/core/+/598977/ bases on
https://gerrit.wikimedia.org/r/#/c/pywikibot/core/+/598876/ which bases on origin/master

A recheck is successfull after the parent was merged in this example:
https://gerrit.wikimedia.org/r/#/c/pywikibot/core/+/560057/

This is a regression to the previous behaviour when a patchset chain could be published.

That works with Doxygen 1.8.16 from docker-registry.wikimedia.org/releng/doxygen:0.6.1-s1

We have recently upgraded to Doxygen 1.8.17 T242155