Is is really needed ? I find the the doc build pretty fast (apart sphinx-apidoc processing that was really long for swh-web due to the node_modules folder (workarounded in rCJSWHb3756cf917d609de38450ceae295e703b004b266),

But there is still the requirements retrieval that puts some burden, that's true.

According to https://jenkins.softwareheritage.org/job/DSTO/job/tests/2070/flowGraphTable/ , it takes 1min.

I wondered about that and figured it was best not to do it because parallel stages make the default console output confusing, unless you use the BlueOcean UI (which properly breaks down the output for each parallel stage, but is godawfully slow).

Maybe we should add a link to BlueOcean in the "create phabricator artifacts" step (included from includes/create-phabricator-artifacts.groovy.j2) - which would then show up in the Harbormaster box? (sample url: https://jenkins.softwareheritage.org/blue/organizations/jenkins/DSTO%2Ftests-on-diff/detail/tests-on-diff/1316). That would make handling the mixed output easier.

What if we pipe tox -e sphinx's output through sponge?

In D5647#145338, @vlorentz wrote:

What if we pipe tox -e sphinx's output through sponge?

I like being able to see the output "live" (even though the sphinx stuff is new enough that I haven't seen /that/ hang yet!), so I'd rather not. I think the time gain is worth doing the build in parallel; Details on failed tests show up in the phabricator UI, so I'm not too concerned about the log output being a little out of order.

Now that I've actually looked at the change, I think we need to move the "Sphinx docs" stage to the parallel block *within* the "Tests" stage. I seem to recall Jenkins had issues with nested parallel steps, at the very least when rendering the stages in the main UI.