I'm writing up a more complete proposal, but here are some examples.
Parameters can be set from either the UI (not my intent) or via the
circleci CLI. Effectively, the config-2_1.yml can have parameters specified
like:
parameters:
run_extra_test:
type: boolean
default: false
jobs:
ex
> This could also be a pipeline parameter instead of hacking it in generate.sh
Curious how this works… I run a script that deletes all the approvals and
removes the testing workflows… I really don’t want to use the UI at all…. I
assumed pipeline params are a UI thing, but I think the goal here
This could also be a pipeline parameter instead of hacking it in
generate.sh. I promise I'll have a proposal before the end of the week.
Derek
On Mon, Oct 24, 2022 at 2:13 PM Josh McKenzie wrote:
> @Ekaterina: I recall us going back and forth on whether default should be
> require approval or n
@Ekaterina: I recall us going back and forth on whether default should be
require approval or not and there not being a consensus. I'm fine not changing
the status quo and just parameterizing that in generate.sh so folks can locally
script how they want to setup when they alias up generate.sh.
>
> - Ticket for: remove -h, have -f and -p (free and paid)
+1 to this, probably there isn't anyone using -h. There are some jobs that
can't pass with the free option. Maybe we should remove them from the
workflow when the free option is used. Perhaps that could save new
contributors some confusi
Seems like my email crashed with Andres’ one.
My understanding is we will use the ticket CASSANDRA-17113 as placeholder,
the work there will be rebased/reworked etc depending on what we agree
with.
I also agree with the other points he made. Sounds reasonable to me
On Mon, 24 Oct 2022 at 15:03, Ek
Thank you Josh
So about push with/without a single click, I guess you mean to parameterize
whether the step build needs approval or not? Pre-commit the new flag will
use the “no-approval” version, but during development we still will be able
to push the tests without immediately starting all tests
>
> Yep - instead of having to go to circle and click, when you push your
> branch the circle hook picks it up and kicks off the top level job
> automatically. I tend to be paranoid and push a lot of incremental work
> that's not ready for CI remotely so it's not great for me, but I think
> having
> Auto-run on push? Can you elaborate?
Yep - instead of having to go to circle and click, when you push your branch
the circle hook picks it up and kicks off the top level job automatically. I
tend to be paranoid and push a lot of incremental work that's not ready for CI
remotely so it's not gre
> I am cool with removing circle if apache CI is stable and works, we do need
> to solve the non-committer issue but would argue that partially exists in
> circle today (you can be a non-commuter with a paid account, but you can’t be
> a non-committer with a free account)
There's a few threads h
I agree with David with one caveat - last time I checked only some Python
tests lack enough resources with the free tier. The rest run slower than
with a paid account, but they do fine. In fact I use the free tier if I
want to test only unit or in-jvm tests sometimes. I guess that is what he
meant
> 1. Tune parallelism levels per job (David and Ekaterina have insight on this)
> Question for David, do you tune only parallelism and use only xlarge? If yes,
> we need to talk :D
Yes, and this is 100% because I am lazy. Too high parallel jobs are a problem
for circle as 100% of resources ne
I am cool with removing circle if apache CI is stable and works, we do need to
solve the non-committer issue but would argue that partially exists in circle
today (you can be a non-commuter with a paid account, but you can’t be a
non-committer with a free account)
> On Oct 20, 2022, at 2:20 P
Random thought (and on-topic, even!) now that I'm starting to understand
CircleCI config better: we should use conditionals and parameters so that
we can have a single, uniform config across version branches, and limit the
diffs across branches to version related flags to enable or disable sets of
> I believe it's original intention to be just about CircleCI.
It was but fwiw I'm good w/us exploring adjacent things regarding CI here. I'm
planning on deep diving on the thread tomorrow and distilling a snapshot of the
work we have a consensus on for circle and summarizing here so we don't los
On Thu, 20 Oct 2022 at 22:07, Derek Chen-Becker
wrote:
> Would the preclusion of non-committers also prevent us from configuring
> Jenkins to auto-test on PR independent of who opens it?
>
> One of my current concerns is that we're maintaining 2x the CI for 1x the
> benefit, and I don't currently
Would the preclusion of non-committers also prevent us from configuring
Jenkins to auto-test on PR independent of who opens it?
One of my current concerns is that we're maintaining 2x the CI for 1x the
benefit, and I don't currently see an easy way to unify them (perhaps a
lack of imagination?). I
Sounds like great plan to me.
Just wanted to mention one caveat. Non-committers do not have access to ASF
CI. I do not think this will change. While no one of us ever said no to
push a patch for testing, it is good to have a good backup plan people can
do it themselves. Currently this is CircleCI.
On Thu, Oct 20, 2022 at 1:45 PM Josh McKenzie wrote:
>
> My high level hope is that we can:
>
> 1. Unstick mainline yearly releases (vote to accept circle results, make
> circle more robust <- WE ARE HERE)
> 2. Invest resources into the ASF CI environment to get it to being a viable
> replacemen
My high level hope is that we can:
1. Unstick mainline yearly releases (vote to accept circle results, make circle
more robust <- WE ARE HERE)
2. Invest resources into the ASF CI environment to get it to being a viable
replacement for circle (requirements for this qualification TBD)
3. Deprecate
+1 to all of these, especially improving CircleCI generation and
ergonomics. I still have a bunch of reservations around CircleCI in
general, but in the short term we can make it less painful (to a point).
Cheers,
Derek
On Thu, Oct 20, 2022 at 6:38 AM Ekaterina Dimitrova
wrote:
> Yes, they do.
Yes, they do. This is the only test suite that gets max resources with -m.
Probably you had some other issue Berenguer as I can confirm I was running
them successfully these days
On Thu, 20 Oct 2022 at 6:54, Brandon Williams wrote:
> They passed with -m for me recently.
>
> Kind Regards,
> Brand
They passed with -m for me recently.
Kind Regards,
Brandon
On Thu, Oct 20, 2022 at 12:03 AM Berenguer Blasi
wrote:
>
> Can python upgrade tests be ran without -h? Last time I tried iirc they fail
> on -m
>
> On 20/10/22 4:11, Ekaterina Dimitrova wrote:
>
> Thank you Josh. Glad to see that our C
Can python upgrade tests be ran without -h? Last time I tried iirc they
fail on -m
On 20/10/22 4:11, Ekaterina Dimitrova wrote:
Thank you Josh. Glad to see that our CI is getting more attention. As
no Cassandra feature will be there if we don't do proper testing,
right? Important as all the su
Thank you Josh. Glad to see that our CI is getting more attention. As no
Cassandra feature will be there if we don't do proper testing, right?
Important as all the suites and tools we have. With that being said I am
glad to see Derek is volunteering to spend more time on this as I believe
this is a
> 1. Tune parallelism levels per job (David and Ekaterina have insight on this)
+1 to this! I drastically lower our parallelism as only python-dtest upgrade
tests need many resources…
What I do for JVM unit/jvm-dtest is the following
def java_parallelism(src_dir, kind, num_file_in_worker, incl
1) would be nice to have. The first thing I do is that I change the parallelism
to 20. None of committed config.yaml's are appropriate for our company CircleCI
so I have to tweak this manually. I think we can not run more that 25/30
containers in parallel, something like that. HIGHRES has 100 an
27 matches
Mail list logo
