[CI:DOCS] logformatter: handle python logs

[edsantiago]

We've got some python tests running in CI, and they're really hard
to troubleshoot. This PR:

1. colorizes python unittest lines (ok / skipped / fail), and
2. links to source files

The color is nice for skimming, but it's the linking that might
make it much easier to diagnose future failures.

(Context: failure today in test/python/docker/compat/test_images.py)

Signed-off-by: Ed Santiago [email protected]

[edsantiago]

Sample log, based on the PR that failed earlier today. (Compare to the original). The "WARNING: Expected NNN" at bottom, there's not much I can do about it: it's caused by python tests whose line does not end in dot-dot-dot-space-ok because they have spurious other output.

[mheon]

@edsantiago Should we just split them into a separate Cirrus test run? Might make your life easier with the logformatter and completely eliminates the chance of confusion like yesterday.

[cevich]

LGTM

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cevich, edsantiago

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [edsantiago]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[cevich]

Re: Splitting them up. Possible to do, but will need some twiddling with .cirrus.yml and likely runner.sh as well. It could be done via a dedicated (new) task (harder), or in the same task (easier) as an additional script (similar to how we have a separate "setup" section and "main" sections). For example, one idea might be:

foo_bar_task:
    ...cut...
    env:
        TEST_FLAVOR=foobar
    setup_script: *setup
    main_script: *main
    extra_script: 'env TEST_FLAVOR=${TEST_FLAVOR}2 $GOSRC/$SCRIPT_BASE/runner.sh'
    always: *runner_stats

Wherein, the runner function _run_foobar2() performs the second section of the test. In this example, the extra_script attribute will cause a distinct and separate execution (named "extra") to happen after main_script causes _run_foobar() to run (and it passes). Obviously, you could easily use a more descriptive name than "extra" if you prefer 😄

[edsantiago]

Re: splitting up: whether or not that's done, this PR still seems useful: the python tests will be run regardless, and ISTM useful to have a one-click way to get to the source code.

@cevich I believe the context here is that the tests are running twice already. When looking at the CI failures in #13239, there were two CI jobs that had exactly the same python failure: APIv2 tests and something else. From a quick look-see (I'm on PTO today) it looks like make localapiv2 and make run-docker-py-tests both invoke python on test/python/docker; the duplication seems unnecessary.

[Luap99]

/lgtm

[cevich]

the duplication seems unnecessary.

Oh! Okay, that sounds like an easily corrected oversight. I'll open an issue. Thanks.

[cevich]

Ref: #13273