On Sun, Nov 28, 2021 at 11:34 AM Dawid Weiss <[email protected]> wrote: > > Hi Robert, > > > * gradle check -x test: 8 minutes, 15 seconds > > * gradle test: 9 minutes, 8 seconds > > These are done in parallel on separate VMs - if we merge them the > combined time will be longer (that's why I split them into two > stages).
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, etc). > > > * lift: 84 minutes > > This is some sonatype static checker/ bot. I don't know who added it > but it doesn't seem to be harmful? 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 even look at PRs until I see the green checkmark, I try to encourage this workflow at work. General idea: don't waste humans time if the computer can do it. The second thing I don't like is that this static checker doesn't run locally. So if the user did the right thing and ran 'gradle check' before creating their PR, they could still fail it? Without any way to test changes locally to make the thing pass, just play whack-a-mole? Again, I'm not sure what it does, but I kinda don't like that workflow. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
