[GitHub] [beam] damccorm commented on pull request #25612: Disable triggering most IO_Direct precommit on buildSrc and core change

["damccorm (via GitHub)" <gi...@apache.org>]

damccorm commented on PR #25612:
URL: https://github.com/apache/beam/pull/25612#issuecomment-1442438491

   I wonder if a better fix here is to consolidate some of our sharded precommits so that instead of having 1 precommit for IOs (our old state) or 21 precommits for IOs (our current state) we have a precommit per IO if the IO changes frequently and we have 1 precommit (or a few precommits) for the remaining relatively stable ones.
   
   A completely different alternative would be to have individual IO suites that trigger when that IOs directory is modified and 1 "mega IO" suite that triggers when we want to run all of our IO tests. That has the downside of getting out of sync more easily, but does what we want about as efficiently and precisely as possible.
   
   All of this is more of a test structure question for a set of suites I don't personally care a ton about, so I'll defer to you, other IO folks, and @kennknowles (who did the initial sharding, which has been a win IMO), but I don't love the idea of not running precommits that have the potential to break on dependency changes. I also acknowledge, though, that all of these solutions stink because the real solution is to actually fix the infrastructure (which probably means move to GHA for us), but that's not a realistic stopgap solution.


-- 
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: github-unsubscribe@beam.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org