Numbers

0 to 1k

Yesterday marked the day that Jenkins Job “Pull Request 5.0” hit the 1000 job (right now running the 1016!).

It’s been a long journey to get it to its current status ((be able to run 4.3 or 5.0 pull requests, allow multiple pull requests per job, report before and after to github just like Travis, allow external forks to be tested…)) but IMHO since the introduction of it our three main Jenkins Jobs for both 4.3 and 5.0 have been far more stable.

Thanks to everyone that reported feedback and is using it!

100k to 0?

Jenkins is not only about tests, code analysis and all other kind of jobs are running on http://jenkins.plone.org. Two of the latest additions are:

per package code analysis jobs that report back to github: packages can opt-in ((fill an issue!)) and are checked with flake8 and other tools ((more about it))
a global code analysis job: exactly the same as the per package jobs mentioned on the previous point, but running code analysis on ALL packages

The 100k is the flake8 error count for the global job, will we be able to bring that down to zero? :-)

Side note: Zope2 and CMFCore are the two (by far) with more code analysis errors, some other packages are probably going to be deprecated so there is no need to clean up them.

Best of both things?

Anyone (you!?) can grab a package clean it up, and run a pull request job to ensure nothing is broken after the clean up and happily merge it.

Happy hacking!

Make code analysis cleanups brainless

I wrote a small guide with a step by step instructions on how to cleanup a package code so that it follows our Plone style guide.

To add sugar on top, the packages that are already monitored for it, point you to that same guide, see it in action.

Enjoy!

Towards more maintainable code

On my talk at the Plone Conference 2015 (slides, talk notes from Maurits) one of my points was that a written style guide is worth nothing if you can not check/enforce it.

Who cares what a style guide says regarding indentation, dependencies, string quoting, docstrings, handling i18n, etc etc if then one can freely commit changes that go against the said style guide?

Fortunately in Python we already have pep8 (the tool) and flake8 (with its great plugin ecosystem). To top it off, on Plone we already have plone.recipie.codeanalysis. We have the tools.

Talk is cheap

I’ve been putting as much effort and free time as I could to make that happen.

plone.recipe.codeanalysis has been improved ((and by no means only by me)), flake8 plugins have been written, and finally during this last Alpine City Strategic Sprint 2016 I could implement the missing piece: report back to the users (see an example)!

The script is fairly simple:

#!/usr/bin/env bash
wget https://raw.githubusercontent.com/plone/buildout.coredev/5.0/bootstrap.py -O bootstrap.py
wget https://raw.githubusercontent.com/plone/buildout.coredev/5.0/experimental/qa.cfg -O qa.cfg
wget https://raw.githubusercontent.com/plone/plone.recipe.codeanalysis/master/.isort.cfg -O .isort.cfg
python bootstrap.py -c qa.cfg
bin/buildout -c qa.cfg
bin/code-analysis

Run the above on any Plone distribution and see the output collected on parts/code-analysis/flake8.log

Currently only a few packages are checked, but cleanup tasks can start on any Plone package as of now. Be sure to ask for a job that will check that the package remains clean as soon as your cleanup changes are merged!

Keep on!