Re: Save CircleCI resources with optional test jobs
Thank you for responding, If there's an option that Benedict has suggested (to allow folks who push mostly-final patches, and the folks who push rather-early patches and then update them continuously, to coexist and be able to quickly switch between configs) I'd be more in favour of this rather than just enabling a build/compile step for everyone. On Wed, Oct 20, 2021 at 8:25 PM Andrés de la Peña wrote: > Hi all, > > As Ekaterina has mentioned I’ll be OOO until Monday, and I won’t be able to > make any changes until then. > > Alex, I missed to answer your suggestion about building on every commit, > apologies for that. The discussion was open on multiple fronts and I > somehow missed that one. I can easily change it back to automatic builds on > Monday if we prefer to do so. > > The pre-commit workflows have a single button to start the build and all > the tests that were previously run automatically. If we had automatic > builds we would still have a button to start the tests. Thus, I think that > automatic builds in the pre-commit workflow would’t make a difference in > terms of usability, and we would be wasting resources in intermediate > commits. > > As for the workflows with separate approval steps, the automatic build > would save us a click at the cost of wasting resources in some cases. Since > the cost of building is not that high it might make more sense to have > automatic builds in these workflows. Alternatively, a detail that could > improve things a bit in the separate-tests workflows is making the approval > steps for running the tests depend on the approval for the build. That > wouldn’t save us any clicks but it would make impossible to miss the build > approval, since we would need to click it in order to enable the buttons > starting the tests. > > It would be really great if the build started when one approves a certain > test job, but as it has been mentioned that doesn’t seem possible with the > current CircleCI features. > > Having a config that entirely satisfies the needs of everyone doesn’t seem > possible, and I also think that we’ll eventually need better tooling to > generate the config file, although we still need to agree on a default > config. CASSANDRA-16989 has recently added flags to the config generation > script allowing to swap resources and specify the environment vars. We > should probably continue adding similar options to be able to manipulate > the approval steps, parallelism, etc. > > Regards, > > El El mié, 20 oct 2021 a las 18:03, bened...@apache.org < > bened...@apache.org> > escribió: > > > Perhaps instead of a one-size-fits-all policy we should look to improve > > scripting here anyway. We already have to overwrite the config file, it > > would seem easy enough to instead invoke a script that enables the > relevant > > workflows? > > > > If we choose to just stick with a single workflow, I don’t have a super > > strong preference for one approach or the other. > > > > From: Stefan Miklosovic > > Date: Wednesday, 20 October 2021 at 16:58 > > To: dev@cassandra.apache.org > > Subject: Re: Save CircleCI resources with optional test jobs > > Hi Ekaterina, all, > > > > If you eventually decide to switch it to automatic build on push (I > > like how it is now though), I would appreciate it if there was some > > option in generation scripts (generate.sh) so I could just have some > > shortcut / alias which would disable this very easily. > > > > It would be very nice if there was also an option to specify > > parallelism for highres nodes. My workflow so far was to 1) copy > > highres to config.yml, open editor and replace "100" with "70" for > > parallelism value. I am not sure what plan you guys are on but we can > > at most spin sometime like 80 nodes or so at once. > > > > Thanks > > > > Stefan > > > > On Wed, 20 Oct 2021 at 16:14, Ekaterina Dimitrova > > > wrote: > > > > > > Hi everyone, > > > > > > First of all, I know Andres is off these days so he might not be > > following > > > the thread today. I will try to clear the situation as the committer > who > > > approved the change. > > > > > > Alex, I would like to apologize to you! You are right, I personally > > didn’t > > > have your email (sometimes gmail plays games with the mailing list > > emails, > > > not sure why) and I assumed the lazy consensus. Andres sent email that > > this > > > was implemented a month after the discussion was open and no one > > responded > > > here during that time. In his latest email he pointed to the Slack > > > discussion that happened and where agreement was reached. > > > I see your email was sent two days after he said it is implemented. I > > guess > > > we had to be more explicit that this email announces lazy consensus. > > > > > > Anyway, I am really sorry your email was missed and please, believe me > > when > > > I say I would have considered it as the ticket was not committed yet at > > > that point! I am almost sure something similar happened to Andres
Re: Save CircleCI resources with optional test jobs
The two separate workflows try to serve both types of pushes, early and almost ready. The separate-test j8/j11 workflows are for those who push early patches, or special cases. The j8/j11 pre-commit workflows are for final stages, and it’s probably what those who push mostly-final patches would use. I think that these folks can just ignore the separate-tests workflows and use the “run everything” approval step on the pre-commit workflow. Focusing on those who push mostly final patches, and therefore use the pre-commit workflow, would there any value on running the build automatically and then requesting manual approval to run all the tests? If the patch is almost ready the tests have to be run, so I think there isn’t a difference between running the build step or not. In the end, we still have to press a single approval step, and if the build fails the tests aren’t going to start. El El jue, 21 oct 2021 a las 14:47, Oleksandr Petrov < oleksandr.pet...@gmail.com> escribió: > Thank you for responding, > > If there's an option that Benedict has suggested (to allow folks who push > mostly-final patches, and the folks who push rather-early patches and then > update them continuously, to coexist and be able to quickly switch between > configs) I'd be more in favour of this rather than just enabling a > build/compile step for everyone. > > On Wed, Oct 20, 2021 at 8:25 PM Andrés de la Peña > wrote: > > > Hi all, > > > > As Ekaterina has mentioned I’ll be OOO until Monday, and I won’t be able > to > > make any changes until then. > > > > Alex, I missed to answer your suggestion about building on every commit, > > apologies for that. The discussion was open on multiple fronts and I > > somehow missed that one. I can easily change it back to automatic builds > on > > Monday if we prefer to do so. > > > > The pre-commit workflows have a single button to start the build and all > > the tests that were previously run automatically. If we had automatic > > builds we would still have a button to start the tests. Thus, I think > that > > automatic builds in the pre-commit workflow would’t make a difference in > > terms of usability, and we would be wasting resources in intermediate > > commits. > > > > As for the workflows with separate approval steps, the automatic build > > would save us a click at the cost of wasting resources in some cases. > Since > > the cost of building is not that high it might make more sense to have > > automatic builds in these workflows. Alternatively, a detail that could > > improve things a bit in the separate-tests workflows is making the > approval > > steps for running the tests depend on the approval for the build. That > > wouldn’t save us any clicks but it would make impossible to miss the > build > > approval, since we would need to click it in order to enable the buttons > > starting the tests. > > > > It would be really great if the build started when one approves a certain > > test job, but as it has been mentioned that doesn’t seem possible with > the > > current CircleCI features. > > > > Having a config that entirely satisfies the needs of everyone doesn’t > seem > > possible, and I also think that we’ll eventually need better tooling to > > generate the config file, although we still need to agree on a default > > config. CASSANDRA-16989 has recently added flags to the config generation > > script allowing to swap resources and specify the environment vars. We > > should probably continue adding similar options to be able to manipulate > > the approval steps, parallelism, etc. > > > > Regards, > > > > El El mié, 20 oct 2021 a las 18:03, bened...@apache.org < > > bened...@apache.org> > > escribió: > > > > > Perhaps instead of a one-size-fits-all policy we should look to improve > > > scripting here anyway. We already have to overwrite the config file, it > > > would seem easy enough to instead invoke a script that enables the > > relevant > > > workflows? > > > > > > If we choose to just stick with a single workflow, I don’t have a super > > > strong preference for one approach or the other. > > > > > > From: Stefan Miklosovic > > > Date: Wednesday, 20 October 2021 at 16:58 > > > To: dev@cassandra.apache.org > > > Subject: Re: Save CircleCI resources with optional test jobs > > > Hi Ekaterina, all, > > > > > > If you eventually decide to switch it to automatic build on push (I > > > like how it is now though), I would appreciate it if there was some > > > option in generation scripts (generate.sh) so I could just have some > > > shortcut / alias which would disable this very easily. > > > > > > It would be very nice if there was also an option to specify > > > parallelism for highres nodes. My workflow so far was to 1) copy > > > highres to config.yml, open editor and replace "100" with "70" for > > > parallelism value. I am not sure what plan you guys are on but we can > > > at most spin sometime like 80 nodes or so at once. > > > > > > Thanks > > > > > > Stefan > > > > >
