[
https://issues.apache.org/jira/browse/BEAM-10961?focusedWorklogId=529574&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-529574
]
ASF GitHub Bot logged work on BEAM-10961:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 30/Dec/20 17:37
Start Date: 30/Dec/20 17:37
Worklog Time Spent: 10m
Work Description: ibzib commented on pull request #12938:
URL: https://github.com/apache/beam/pull/12938#issuecomment-752701353
@shehzaadn-vd Some explanation for the behavior you saw:
> any idea why
org.apache.beam.sdk.transforms.ParDoLifecycleTest.testTeardownCalledAfterExceptionInProcessElement
is showing up as failing even though it's excluded from running in
beam/runners/portability/java/build.gradle
`testTeardownCalledAfterExceptionInProcessElement` is a `ValidatesRunner`
test. `ValidatesRunner` tests are meant to be run by different runners. Each
runner defines its own list for which `ValidatesRunner` tests to skip
(typically because they are not expected to pass).
> Looking at the console output of the last successful build (#15306),
(taking the listing of tasks on the left of the screen and doing some
sort/uniq/diff on bash) this is being executed multiple times.
No task is being executed multiple times. The "Executed Gradle Tasks" list
is somewhat misleading in this regard. It prints out the task name every time
it sees a log line starting with `> Task`. Because the logs are ordered
chronologically, and Jenkins can execute many tasks in parallel, logs for
different tasks become interleaved. Gradle prints `> Task X` each time so you
can tell the logs apart. So when `> Task A` appears twice, it's not because it
is running again, it's because some other task B printed logs in between task
A's.
> It looks like running Run Java PreCommit again fixed the issue - which
suggests the test is a bit unstable, but unrelated to this PR.
I agree. When you encounter what you suspect to be a flaky test, you can
look on JIRA to see if anyone else has run into it. If no one's filed an issue
yet, please create one. (I created BEAM-11541 for
`testTeardownCalledAfterExceptionInProcessElement`.)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 529574)
Time Spent: 27.5h (was: 27h 20m)
> Enable strict dependency analysis on all Java modules
> ------------------------------------------------------
>
> Key: BEAM-10961
> URL: https://issues.apache.org/jira/browse/BEAM-10961
> Project: Beam
> Issue Type: Improvement
> Components: java-fn-execution
> Reporter: Shehzaad Nakhoda
> Assignee: Shehzaad Nakhoda
> Priority: P2
> Time Spent: 27.5h
> Remaining Estimate: 0h
>
> This is an IWYU analysis. If the module is using its transitive deps without
> depending on them, or if it has direct dependencies it doesn't use, the build
> fails. The work involves adding dependencies or adding exclusion rules
> (example:
> https://github.com/wfhartford/gradle-dependency-analyze#configurations). Even
> if they just add exclusions across the board, it will be a big win because it
> will prevent new violations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
