Hello everyone,
Hope this email finds you well!
Just a heads up that I plan to open a Jira and change the CircleCI config.
Currently unit tests and in-jvm tests are triggered automatically on every
commit.
I want to change it so it could be a manual choice whether to do it or not.
Anyone against
You can have two repositories, one that triggers CI and one that doesn't, if
you're that paranoid
On 24/03/2020, 21:03, "Joshua McKenzie" wrote:
>
> You could push to the repository that triggers CI less frequently?
For the paranoid among us or those that work on a variety
+1
On 23 March 2020 at 11:27:50, Mick Semb Wever (m...@apache.org) wrote:
> >
> > The vote will be open for 72 hours (longer if needed). Everyone who has
> > tested the build is invited to vote. Votes by PMC members are considered
> > binding. A vote passes if there are at least three binding
Hello project - I'm up this week. Jordan, Jon, and I figure we should just
send these updates out on Tuesdays since it seems to keep happening that
way anyway; Mondays are hard.
Link to the JIRA board:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA
[Open vs.
Am I understanding correctly - this isn't disabling tests, just changing
when they're triggered (i.e. automatic to manual)?
So, for instance, smaller interim commits don't trigger a CI run and thus
costs?
On Tue, Mar 24, 2020 at 3:34 PM David Capwell wrote:
> >
> > I want to change it so it
>
> You could push to the repository that triggers CI less frequently?
For the paranoid among us or those that work on a variety of machines over
time, this does represent a sub-optimal arrangement.
On Tue, Mar 24, 2020 at 4:38 PM Benedict Elliott Smith
wrote:
> You could push to the
I don't think supporting only 3.6 not 3.7 was a deliberate move, it's
likely just an oversight. Yes, we should address that. Mind filing a
JIRA?
On Tue, Mar 24, 2020 at 11:33 AM Stefan Miklosovic <
stefan.mikloso...@instaclustr.com> wrote:
> Hi,
>
> I built deb package for Debian from current
Ok, I created two JIRAs. The first one is targeting 3.6/3.7 issue, the
second one is about the bug I hit. I made two issues so they can be
worked on separately.
https://issues.apache.org/jira/browse/CASSANDRA-15659
https://issues.apache.org/jira/browse/CASSANDRA-15660
Cheers
On Tue, 24 Mar 2020
Hi both,
Yes, Josh, that's what I meant. No disabling of tests or running out of
responsibility to submit patch after a full proper CI run.
I am a person who does a lot of commits before final squash and honestly,
looking now at my Circle history - I have a headache.
Ekaterina Dimitrova | Software
You could push to the repository that triggers CI less frequently? I don't
think it cares about commits, but pushes.
I think some people like to see feedback promptly, without having to go in
manually until a dtest run is needed closer to patch completion. Unfortunately
this is a situation
It looks like you can configure at the branch level and disable.
https://discuss.circleci.com/t/is-there-a-way-to-prevent-automatic-build-on-a-branch/4085
On Tue, Mar 24, 2020, 2:04 PM Benedict Elliott Smith
wrote:
> You can have two repositories, one that triggers CI and one that doesn't,
>
Hi,
I built deb package for Debian from current trunk as of today and I
wanted to test cqlsh and I got this error:
me@machine:/$ python --version
Python 2.7.16
me@machine:/$ cqlsh -u cassandra -p cassandra --execute="select * from
system_auth.roles" machine
Usage: cqlsh.py [options] [host
>
> I want to change it so it could be a manual choice whether to do it or not.
Could you explain the motivations for disabling the tests by default? My
personal stance is all tests should run (we disable a lot, at least HIGHER
should enable all...), not a fan of disabling tests.
On Tue, Mar
13 matches
Mail list logo
