dist/tools/ci: also print doxygen and flake8 versions

[aabadie]

Contribution description

This PR adds the possibility to display the doxygen and flake8 versions in the print_toolchain script. I wanted to comment in #8727 about this but it was already merged.

Issues/PRs references

#8727

[jnohlgard]

Murdock reports flake8 is missing, but the flake8 check script succeeds. What is happening there?

[aabadie]

What is happening there?

I don't understand this either. I thought it was installed, at least it should be in the riotdocker docker image. Does that mean the Murdock workers are not in sync with the riotdocker image ?

Question: why not 'just' derive the Docker image used in Murdock workers from riotdocker ?

[smlng]

Some CI-Workers were not restarted since flake8 was introduced, hence they did not pull the latest riot docker image. Nevertheless flake8 is part of the docker image, which is the base for the CI-worker image + some extra packages for murdock.

[aabadie]

the docker image, which is the base for the CI-worker image + some extra packages for murdock.

It would be great to have them defined in the same repo (riotdocker), the Dockerfile of the image used for Murdock workers could be simply put in a murdock subdirectory. Or is there already a github repo for this ?

[smlng]

you're right we need to clarify and structure this better, i.e., which is the user docker image and which is the CI-worker one. However, that's not the problem here; the problem is that updating and rolling out a new CI-worker image did not work reliably using dwq.

[kaspar030]

you're right we need to clarify and structure this better, i.e., which is the user docker image and which is the CI-worker one.

The Murdock worker is now using riotdocker as base.

However, that's not the problem here; the problem is that updating and rolling out a new CI-worker image did not work reliably using dwq.

The problem are nodes sharing a name (e.g., inria-ci), as they're sharing control channels. The only way to restart all of them (using dwq) is to issue the restart command to "inria-ci" often enough, which is, as @smlng is completely right, unreliable.

[smlng]

@kaspar030 actually the node missing flake8 was the e52 ci worker, I guess that one is under your control?

[smlng]

INRIA currently is a mere 2 or 4 core machine, at least that's what I guess from the low number of tasks per build that this worker completes.

[kaspar030]

@kaspar030 actually the node missing flake8 was the e52 ci worker, I guess that one is under your control?

That explains why restarting inria didn't reliably fix the problem.

[aabadie]

I just re-triggered Murdock and flake8 is still missing, this time on mobi1.inet.haw-hamburg.de

[smlng]

I'll restart mobi1

[smlng]

@aabadie the problem is there is no flake8 binary in the current docker container. The Dockerfile only installs python3-flake8 but not the binaries which are in the plain flake8 package. So all workers did restart and are up to date, but the packages are missing - at least for Ubuntu xenial.

I manually installed them on mobi1 now, but we may need to update the workers again.

[aabadie]

I manually installed them on mobi1 now

How ? Using pip3 install flake8 ?

[jnohlgard]

Is there something like update-alternatives which need to be run to set up the flake8 -> python3-flake8 symlink?

[aabadie]

Is there something like update-alternatives which need to be run to set up the flake8 -> python3-flake8 symlink?

I don't know, I was just comparing to how it's installed with Travis

[smlng]

So far I read that the Ubuntu package python3-flake8 does not contain the binaries, for that I explicitly installed the flake8 package via apt.

[cladmi]

Displaying them does not hurt, it even showed that not all workers have them.

[smlng]

makes perfect sense to print those, too. ACK!