On Sun, Nov 28, 2021 at 12:37 PM Dawid Weiss <[email protected]> wrote: > > > OK, I see. I was thinking that a simple 'gradle check' as the github > > action would be easier to understand / reproduce locally for > > contributors, and that by combining the two tasks into one, we'd use > > less server-side resources (I have no idea what the limits are here, > > It does use more resources - true. If this is a problem - we can go > back to just 'check. > It is now currently split into two phases but functionally equivalent > to 'gradlew check' - > it just runs the non-test checks first (linters). I don't mind if it's > done in one stage (but it will be longer). > > > The main thing I don't like is the long latency (more than an hour) > > before a PR goes "green" or "red". I have a habit to generally not > > I really know zero about this plugin. I don't even think it causes an > error, even if it "fails". It just adds comments about unsafe code, I > think?... The few times it did comment on my PRs it was mostly wrong - > I didn't look at its output again. >
Yeah, to me the current situation is confusing. Splitting the two check tasks to "optimize for latency" doesn't make sense when you are still going to wait 90 minutes on the very slow third check that none of us understand :) Personally, I'd prefer that users see one automated PR check, and that it's "gradle check", very easy for them to run locally. Obviously, we can and should do things to keep this running fast! --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
