> Tests fail due to variety of reasons. Some of them fail due to
> underlying infrastructural issues. For example, getting a clean run of
> Python DTests typically involves rerunning them a couple times. Is it
> possible to do that at the test framework level i.e. in Jenkins and/or
> CircleCI
Tests fail due to variety of reasons. Some of them fail due to underlying
infrastructural issues. For example, getting a clean run of Python DTests
typically involves rerunning them a couple times. Is it possible to do that at
the test framework level i.e. in Jenkins and/or CircleCI?
Dinesh
>
That’s awesome that we have that set up. I was checking out b.a.o after my
email and noticed some recent runs. I don’t mean to prescribe any specific
way of surfacing results as long as they are easily accessible to all
contributors (well documented where to find them, etc).
Progress on posting re
> In my opinion/experience, this is all a direct consequence of lack of trust
> in CI caused by flakiness.
The challenge of this project's test state certainly feel like an
insurmountable challenge at times…
Having been battling away with Jenkins, because I do have ASF access and don't
have
Looks like there are two slack plugins for Jenkins. They trigger after
builds and if my rusty Jenkins-fu is right the trunk build can be scheduled
to run daily and then have the plugin post to slack when its done. Not an
expert and can't poke at the Jenkins instance myself so not sure what
limitati
Can someone find a circleci or jenkins bot that posts to the #cassandra-dev
channel in ASF slack once a day?
On Fri, Jan 24, 2020 at 11:23 AM Jordan West wrote:
> Keeping trunk green at all times is a great goal to strive for, I'd love to
> continue to work towards it, but in my experience its
Keeping trunk green at all times is a great goal to strive for, I'd love to
continue to work towards it, but in my experience its not easy. Flaky
tests, for the reason folks mentioned, are a real challenge. A standard we
could use while we work towards the more ambitious one, and we are pretty
clos
>
> I also don't think it leads to the right behaviour or incentives.
The gap between when a test is authored and the point at which it's
determined to be flaky, as the difficulty with responsibility assignment
(an "unrelated" change can in some cases make a previously stable test
become flaky) ma
> due to oversight on a commit or a delta breaking some test the author thinks
> is unrelated to their diff but turns out to be a second-order consequence of
> their change that they didn't expect
In my opinion/experience, this is all a direct consequence of lack of trust in
CI caused by flakin
>
> gating PRs on clean runs won’t achieve anything other than dealing with
> folks who straight up ignore the spirit of the policy and knowingly commit
> code with test breakage
I think there's some nuance here. We have a lot of suites (novnode, cdc,
etc etc) where failures show up because people
As for GH for code review, I find that it works very well for nits. It’s also
great for doc changes, given how GH allows you suggest changes to files
in-place and automatically create PRs for those changes. That lowers the
barrier for those tiny contributions.
For anything relatively substantia
The person introducing flakiness to a test will almost always have run it
locally and on CI first with success. It’s usually later when they first start
failing, and it’s often tricky to attribute to a particular commit/person.
So long as we have these - and we’ve had flaky tests for as long as
> I find it only useful for nits, or for coaching-level comments that I would
> never want propagated to Jira.
Actually, I'll go one step further. GitHub encourages comments that are too
trivial, poisoning the well for third parties trying to find useful
information. If the comment wouldn't be
The common factor is flaky tests, not people. You get a clean run, you commit.
Turns out, a test was flaky. This reduces trust in CI, so people commit
without looking as closely at results. Gating on clean tests doesn't help, as
you run until you're clean. Rinse and repeat. Breakages accum
100% agree
François and team wrote a doc on testing and gating commits
Blake wrote a doc on testing and gating commits
Every release there’s a thread on testing and gating commits
People are the common factor every time. Nobody wants to avoid merging their
patch because someone broke a test else
>
> I am reacting to what I currently see
> happening in the project; tests fail as the norm and this is kinda seen as
> expected, even though it goes against the policies as I understand it.
After over half a decade seeing us all continue to struggle with this
problem, I've come around to the sch
On 1/23/20 3:53 PM, David Capwell wrote:
2) Nightly build email to dev@?
Nope. builds@c.a.o is where these go.
https://lists.apache.org/list.html?bui...@cassandra.apache.org
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@
Thanks for the link. I have reached out to infra and will update this
thread as I hear back.
Looking around other Apache projects, there are work arounds so I don't
actually see this as a blocker, more limiting possible implementations.
So assuming we have a solution which enables CI builds on PR
On 1/23/20 2:13 PM, Mick Semb Wever wrote:
ASF policy is that patches from contributors that haven't a ICLA
filed can not have their patches automatically run through any ASF CI
system. It's up to a committer (or someone who has filed a ICLA) to
trigger the test run on the patch.
I couldn't f
> > ASF policy is that patches from contributors that haven't a ICLA
> > filed can not have their patches automatically run through any ASF CI
> > system. It's up to a committer (or someone who has filed a ICLA) to
> > trigger the test run on the patch.
>
> I couldn't find this CI+ICLA policy in
On 1/23/20 12:44 PM, mck wrote:
ASF policy is that patches from contributors that haven't a ICLA
filed can not have their patches automatically run through any ASF CI
system. It's up to a committer (or someone who has filed a ICLA) to
trigger the test run on the patch.
I couldn't find this CI+
On Thu, Jan 23, 2020 at 9:09 AM Jeff Jirsa wrote:
> On Thu, Jan 23, 2020 at 6:18 AM Jeremiah Jordan
> wrote:
>
> > It is the reviewer and authors job to make sure CI ran and didn’t
> > introduce new failing tests, it doesn’t matter how they were ran. It is
> > just as easy to let something throu
> I am fine with Jenkins or CircleCI; though I feel CircleCI is more effort
> for each member.
ASF policy is that patches from contributors that haven't a ICLA filed can not
have their patches automatically run through any ASF CI system. It's up to a
committer (or someone who has filed a ICLA
>
> CircleCI can build github forked branches.
Yes it can, but we currently require each member of the community to set up
their own CircleCI in order to test Cassandra (and non-paid account will
have many tests failing). I looked into CircleCI JIRA integration and it
seems that we would need ev
On Thu, Jan 23, 2020 at 6:18 AM Jeremiah Jordan
wrote:
> Can’t you currently open a PR with the right commit message, have do
> review there with all comments posted back to JIRA, run CI on it and then
> merge it closing the PR? This is the basic workflow you are proposing yes?
>
>
Yes you can.
PR than in other forms
>>>> and that its easier to track. One of the things i see now is that the
>>>> conversation moves to slack, so is it better not happening, happening in
>>>> slack, or happening in github?
>>>> 4) This is actually why i star
> My mind set is that by switching to PRs (even if all the conversations are
> in JIRA) we can setup automation which helps detect issues before merging.
CircleCI can build github forked branches. AFAIK there's no reason to open a PR.
The finer granularity of code review comments can also be o
gt;> back that passed review, got merged, and has been failing the build ever
> >> since. I would like to make it more clear that code is likely to do
> this
> >> or not.
> >> 5) The link documents the process as submitting patches generate by "git
> >
es generate by "git
>> format-patch", which i was told not to do my first patch
>>
>> Think i summarized all I saw.
>>
>>> On Wed, Jan 22, 2020 at 2:30 PM Dinesh Joshi wrote:
>>>
>>> I personally use Github PRs to discuss the changes i
scussion does get linked with the JIRA ticket. However,
> > committing is manual.
> >
> > Dinesh
> >
> > > On Jan 22, 2020, at 2:20 PM, David Capwell wrote:
> > >
> > > When submitting or reviewing a change in JIRA I notice that we have
> three
&g
On Jan 22, 2020, at 2:20 PM, David Capwell wrote:
> >
> > When submitting or reviewing a change in JIRA I notice that we have three
> > main patterns for doing this: link branch, link diff, and link GitHub
> pull
> > request (PR); I wanted to bring up the idea of switching
tice that we have three
> main patterns for doing this: link branch, link diff, and link GitHub pull
> request (PR); I wanted to bring up the idea of switching over to GitHub
> pull requests as the norm.
>
>
> Why should we do this? The main reasons I can think of are: consi
t we have three
main patterns for doing this: link branch, link diff, and link GitHub pull
request (PR); I wanted to bring up the idea of switching over to GitHub
pull requests as the norm.
Why should we do this? The main reasons I can think of are: consistency
wit
When submitting or reviewing a change in JIRA I notice that we have three
main patterns for doing this: link branch, link diff, and link GitHub pull
request (PR); I wanted to bring up the idea of switching over to GitHub
pull requests as the norm.
Why should we do this? The main reasons I can
r otherwise use PR related
>>> features, so I'm really wondering why it would make sense to more
>>> heavily using them.
>>
>>
>> Apache does now offer the GitBox service. This makes the github repository
>> writable. The asf and github repos are kept in
dering why it would make sense to more
> > heavily using them.
>
>
> Apache does now offer the GitBox service. This makes the github repository
> writable. The asf and github repos are kept in sync, rather than one being
> a mirror of the other.
>
> I'm not entirely su
os are kept in sync, rather than one being a
mirror of the other.
I'm not entirely sure this would be the right move for C*, given that patches
and branches are merged in a manner that GitHub pull requests don't do (unless
you're only committing to trunk). But it would mean PRs can
more
heavily using them.
On 12.12.2017 09:02, Marcus Eriksson wrote:
> To be able to use the github code review UI and closer CI integration we
> should make it obligatory to submit github pull requests for all code
> changes.
>
> The process would be:
> 1. Create or find a JIRA ti
To be able to use the github code review UI and closer CI integration we
should make it obligatory to submit github pull requests for all code
changes.
The process would be:
1. Create or find a JIRA ticket
2. Submit GH pull request
- one PR per branch (one for 3.0, one for 3.11 etc
I guess someone would have to open 3 different PRs (say, 2.2, 3.0, trunk), and
the committer would have 3 different commit messages to close each of them?
Anyone have examples of projects with branching strategies similar to ours
using github pull requests?
On 8/29/16, 6:26 AM, "Sy
rted
> at
> >> the time) when we were using https://github.com/usergrid/usergrid as
> the
> >> source:
> >> http://mail-archives.apache.org/mod_mbox/usergrid-dev/201405.mbox/%
> >> 3CCANyrgvdTVzZQD7w3C96LUHa=h7-h4qmu4h7ajsxoat0gd0f...@mail.gmail.com%3E
>
> 3CCANyrgvdTVzZQD7w3C96LUHa=h7-h4qmu4h7ajsxoat0gd0f...@mail.gmail.com%3E
> >>
> >> Here is the Thrift guide again for reference:
> >> https://github.com/apache/thrift/blob/master/
> CONTRIBUTING.md#contributing-
> >> via-github-pull-requests
> >>
&
t; Here is the Thrift guide again for reference:
>> https://github.com/apache/thrift/blob/master/CONTRIBUTING.md#contributing-
>> via-github-pull-requests
>>
>> JClouds also has a nice write up/how-to (we based Usergrid on this,
>> initially):
>> htt
>
> > Here is the Thrift guide again for reference:
> > https://github.com/apache/thrift/blob/master/
> CONTRIBUTING.md#contributing-
> > via-github-pull-requests
> >
> > JClouds also has a nice write up/how-to (we based Usergrid on this,
> > initiall
il.gmail.com%3E
>
> Here is the Thrift guide again for reference:
> https://github.com/apache/thrift/blob/master/CONTRIBUTING.md#contributing-
> via-github-pull-requests
>
> JClouds also has a nice write up/how-to (we based Usergrid on this,
> initially):
> https://cwiki.apache.org
3CCANyrgvdTVzZQD7w3C96LUHa=h7-h4qmu4h7ajsxoat0gd0f...@mail.gmail.com%3E
Here is the Thrift guide again for reference:
https://github.com/apache/thrift/blob/master/CONTRIBUTING.md#contributing-via-github-pull-requests
JClouds also has a nice write up/how-to (we based Usergrid on this,
initially)
>
>
> Nate, since you have experience with this from Usergrid, can you figure out
> what we need to do to make this happen and follow up with infra?
>
Yep - i'll look into this.
It sounds like we have consensus that enabling pull requests would be a
Very Good Thing.
Nate, since you have experience with this from Usergrid, can you figure out
what we need to do to make this happen and follow up with infra?
On Sun, Aug 28, 2016 at 3:07 PM, Nate McCall wrote:
> +1
>
> Gith
+1
Github PRs have worked well for Usergrid:
https://cwiki.apache.org/confluence/display/usergrid/Usergrid+Contribution+Workflow
On Sat, Aug 27, 2016 at 4:15 AM, Jake Luciani wrote:
> Jake could you show an example issue and how the pipeline works?
>
> On Fri, Aug 26, 2016 at 12:03 PM, Jake Fa
@Jeremiah, makes sense to send to commits@
On Fri, Aug 26, 2016 at 12:55 PM, Jeremiah D Jordan <
jeremiah.jor...@gmail.com> wrote:
> +1 for PR’s but if we start using them I think we should get them sent to
> commits@ instead of the dev@ they are currently sent to.
>
> -Jeremiah
>
> > On Aug 26,
+1 for PR’s but if we start using them I think we should get them sent to
commits@ instead of the dev@ they are currently sent to.
-Jeremiah
> On Aug 26, 2016, at 1:38 PM, Andres de la Peña wrote:
>
> +1 to GitHub PRs, I think it will make things easier.
>
> El viernes, 26 de agosto de 2016,
+1 to GitHub PRs, I think it will make things easier.
El viernes, 26 de agosto de 2016, Jason Brown
escribió:
> D'oh, forgot to explicitly state that I am +1 one on the github PR proposal
> :)
>
> On Fri, Aug 26, 2016 at 11:07 AM, Jason Brown > wrote:
>
> > It seems to me we might get more cont
D'oh, forgot to explicitly state that I am +1 one on the github PR proposal
:)
On Fri, Aug 26, 2016 at 11:07 AM, Jason Brown wrote:
> It seems to me we might get more contributions if we can lower the barrier
> to participation. (see Jeff Beck's statement above)
>
> +1 to Aleksey's sentiment abo
+1 to officially supporting GitHub PRs.
On Fri, Aug 26, 2016 at 11:07 AM Jason Brown wrote:
> It seems to me we might get more contributions if we can lower the barrier
> to participation. (see Jeff Beck's statement above)
>
> +1 to Aleksey's sentiment about the Docs contributions.
>
> On Fri, A
It seems to me we might get more contributions if we can lower the barrier
to participation. (see Jeff Beck's statement above)
+1 to Aleksey's sentiment about the Docs contributions.
On Fri, Aug 26, 2016 at 9:48 AM, Mark Thomas wrote:
> On 26/08/2016 17:11, Aleksey Yeschenko wrote:
> > Mark, I,
On 26/08/2016 17:11, Aleksey Yeschenko wrote:
> Mark, I, for one, will be happy with the level of GitHub integration that
> Spark has, formal or otherwise.
If Cassandra doesn't already have it, that should be a simple request to
infra.
> As it stands right now, none of the committers/PMC members
We still include both processes in our how to contribute, but github is the
new preferred method (thanks for the reminder to update that doc)
https://github.com/apache/thrift/blob/master/CONTRIBUTING.md
and an example of the cross commenting: THRIFT-3876 with matching PR 1045
https://github.com/
Also, Github’s ability to modify files ‘in-place’ and create pull requests from
those changes is
extremely important for our Docs progress. Now that we have proper in-tree
documentation,
this would lower the barrier for Docs writers tremendously.
--
AY
On 26 August 2016 at 17:15:54, Jake Lucia
Jake could you show an example issue and how the pipeline works?
On Fri, Aug 26, 2016 at 12:03 PM, Jake Farrell wrote:
> We just switched Apache Thrift over to using Github for all our inbound
> contributions, have not made Github canonical yet. We wanted to have one
> unified way to accept patc
I would love to be able to send PRs, there have a been a few minor
improvements I wanted to submit that are sitting in local branches for me
for when I have time to really learn how to submit a patch where PRs are
much more approachable now.
Jeff
On Fri, Aug 26, 2016 at 11:11 AM Aleksey Yeschenko
Mark, I, for one, will be happy with the level of GitHub integration that Spark
has, formal or otherwise.
As it stands right now, none of the committers/PMC members have any control
over Cassandra Github mirror.
Which, among other things, means that we cannot even close the erroneously
opened
On 26/08/2016 16:33, Jonathan Ellis wrote:
> Hi all,
>
> Historically we've insisted that people go through the process of creating
> a Jira issue and attaching a patch or linking a branch to demonstrate
> intent-to-contribute and to make sure we have a unified record of changes
> in Jira.
>
> Bu
This is one of my favorite aspects of how contributions to Spark work. This
also makes it easier to have automated testing on new branches
automatically occurring.
-Russ
On Fri, Aug 26, 2016 at 8:45 AM Ben Coverston
wrote:
> I think it would certainly make contributing to Cassandra more
> strai
We just switched Apache Thrift over to using Github for all our inbound
contributions, have not made Github canonical yet. We wanted to have one
unified way to accept patches and also make it easier for automated CI to
validate the patch prior to review. Much easier now that we have a set
pipeline
I think it would certainly make contributing to Cassandra more
straightforward.
I'm not a committer, so I don't regularly create patches, and every time I
do I have to search/verify that I'm doing it right.
But pull requests? I make pull requests every day, and GitHub makes that
process work the
Hi all,
Historically we've insisted that people go through the process of creating
a Jira issue and attaching a patch or linking a branch to demonstrate
intent-to-contribute and to make sure we have a unified record of changes
in Jira.
But I understand that other Apache projects are now recognizi
66 matches
Mail list logo
