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
> apply my defaults to the build) but not an issue I have… so I don’t mind
>>> >> if people want the tool to integrate with git…
>>> >>
>>> >>
>>> >> With all that said, I do feel there is more, and something I feel
>>> >&g
by humans who want to add new jobs..
>> we should move away from maintaining .circleci/config-2_1.yml and instead
>> auto-generate it. Simple example of this problem is jdk11 support… we run
>> a subset of tests on jdk11 and say its supported… will jdk17 have the same
>> i
e don’t need to call “circleci config
> process” every time we touch circle config…. Also, seems that w/e someone
> new to circle config (but not cassandra) touch it they always mutate
> LOW/MID/HIGH and not .circleci/config-2_1.yml… so I keep going back to fix
> .circleci/config-2_1.ym
HIGH and not
>> .circleci/config-2_1.yml… so I keep going back to fix
>> .circleci/config-2_1.yml….
>>
>>
>> On Oct 19, 2022, at 1:32 PM, Miklosovic, Stefan
>> wrote:
>>
>> 1) would be nice to have. The first thing I do is that I change the
>&
so I have to
take extra care of these cases (I consider that to be a bug, I
think there are two or three, I do not remember). Once set, I
have that config in "git stash" so I just apply it every time I
need it.
5) would be nice too.
7) is nice but not crucial, it ta
ault
> config.yaml on parallelism. I use "sed" to change parallelism: 4 to
> parallelism: 20 and leave parallelism: 1 where it does not make sense to
> increase it. However I noticed that there is not "4" set everywhere, some
> jobs have it set to "1" so
ld be nice too.
> 7) is nice but not crucial, it takes no time to commit that.
>
>
> From: Josh McKenzie
> Sent: Wednesday, October 19, 2022 21:50
> To: dev
> Subject: [DISCUSS] Potential circleci config and workflow changes
>
>
so I
just apply it every time I need it.
5) would be nice too.
7) is nice but not crucial, it takes no time to commit that.
From: Josh McKenzie
Sent: Wednesday, October 19, 2022 21:50
To: dev
Subject: [DISCUSS] Potential circleci config and workflow
While working w/Andres on CASSANDRA-17939 a variety of things came up regarding
our circleci config and opportunities to improve it. Figured I'd hit the list
up here to see what people's thoughts are since many of us intersect with these
systems daily and having your workflow disrupted without h
28 matches
Mail list logo
