[
https://issues.apache.org/jira/browse/BEAM-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930753#comment-16930753
]
Udi Meiri commented on BEAM-8213:
---------------------------------
We already have the "rat" check split out from the others. I'd support having a
separate lint and doc check as well (or add it to RAT).
There are actually more than 4 versions of each test run. :( Using pytest we'll
be able to set the test suite name. (or set --junit-prefix)
I don't know how to provide sub-job results early on though.
Nose and pytest both capture logs, and (nose at least) report captured logs for
each test in the XML result file, so I find that sufficient.
I have an ongoing project to migrate to pytest.
https://github.com/apache/beam/pull/7949
I am in the process of splitting it up to smaller PRs.
> Run and report python tox tasks separately within Jenkins
> ---------------------------------------------------------
>
> Key: BEAM-8213
> URL: https://issues.apache.org/jira/browse/BEAM-8213
> Project: Beam
> Issue Type: Improvement
> Components: build-system
> Reporter: Chad Dombrova
> Priority: Major
>
> As a python developer, the speed and comprehensibility of the jenkins
> PreCommit job could be greatly improved.
> Here are some of the problems
> - when a lint job fails, it's not reported in the test results summary, so
> even though the job is marked as failed, I see "Test Result (no failures)"
> which is quite confusing
> - I have to wait for over an hour to discover the lint failed, which takes
> about a minute to run on its own
> - The logs are a jumbled mess of all the different tasks running on top of
> each other
> - The test results give no indication of which version of python they use. I
> click on Test results, then the test module, then the test class, then I see
> 4 tests named the same thing. I assume that the first is python 2.7, the
> second is 3.5 and so on. It takes 5 clicks and then reading the log output
> to know which version of python a single error pertains to, then I need to
> repeat for each failure. This makes it very difficult to discover problems,
> and deduce that they may have something to do with python version mismatches.
> I believe the solution to this is to split up the single monolithic python
> PreCommit job into sub-jobs (possibly using a pipeline with steps). This
> would give us the following benefits:
> - sub job results should become available as they finish, so for example,
> lint results should be available very early on
> - sub job results will be reported separately, and there will be a job for
> each py2, py35, py36 and so on, so it will be clear when an error is related
> to a particular python version
> - sub jobs without reports, like docs and lint, will have their own failure
> status and logs, so when they fail it will be more obvious what went wrong.
> I'm happy to help out once I get some feedback on the desired way forward.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
