kennknowles commented on PR #24584:
URL: https://github.com/apache/beam/pull/24584#issuecomment-1343098810
Yes, it is good a good point.
If you are working on an I/O then it will not be a problem, because the
"Java PreCommit" will not run, just the quick IO precommit.
If you are working on the core SDK then yes it will create a large number of
jobs because all the IOs trigger.
- Best case: There are more jobs but they are all fast enough that it is
not a problem. Gradle cache will help this. It will still be slower than one
big job.
- Worse case: The queue gets jammed. Then one idea would be to not trigger
the IOs but just to include them in the core SDK precommit.
And yes I am just doing this now because the GHA migration is not done soon
enough and this was pretty easy and should remove a lot of flaking, and let us
re-run just certain pieces
----
Long version:
Before this PR we had the rules:
- core changed -> core + all IOs job runs
- one IO changed -> core + all IOs job runs
The rules I am implementing are:
- core changed -> core unit tests run
- core changed -> all IO unit tests run
- one IO changed -> one IO unit tests run
This PR implements those rules directly:
- core changed -> core job runs
- core changed -> all IO jobs run
- one IO changed -> one IO job runs
We could also implement the rules with these jobs:
- core changed -> one big job runs that includes all the tests
- one IO changed -> one IO job runs
The benefit of having separate IO jobs is that if there is a flake the rerun
can be just the IO job.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
