[
https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339057#comment-17339057
]
Ekaterina Dimitrova edited comment on CASSANDRA-16625 at 5/4/21, 2:57 PM:
--------------------------------------------------------------------------
Thank you for the detailed explanation [~adelapena].
So my assumption that it will be issue for whoever updates/prepares new
patches/final config files not for the end user is right. For the end user it
will be still a matter of copy paste the file and just add what they want to do
in their request.
I am not sure how much this could be an issue to be honest and what could be
the problems for that person who is updating the config. I see on average
changes to those config files happen once per month.
I guess it is a tradeoff:
- if we don't have additional patch and someone wants to use them, they should
be adding manually the parameters to the file
- if we want to make it possible through POST, then we might make it prone to
issues during development and updating the files.
I kind of feel that both options give great benefit but they are suboptimal but
there are currently limitations in CircleCI that do not give us a better
option. In both cases people will need a readme and either copy-paste
parameters to the file or set parameters in the POST request. In that sense I
guess too many patches becomes a bit of overkill.
bq. By the way, I have also observed that the CircleCI CLI tool also removes
the license header when generating the config, so the current
.circleci/generate.sh also requires some minor manual intervention to add the
missed licenses. I have included a fix for this in the patch.
Great catch, thanks!
One thing that I am worried about and I am wondering whether there is a way to
make our lives easier - under Artifacts we will have all the logs from all the
runs which is super helpful but currently I don't see any identification of
which logs are for which run... So in case of 3 fails in 1000 runs I am not
sure how we can easily identify the logs we need. Any ideas? Probably we can
try to add some identification to the logs for example. WDYT?
was (Author: e.dimitrova):
Thank you for the detailed explanation [~adelapena].
So my assumption that it will be issue for whoever updates/prepares new
patches/final config files not for the end user is right. For the end user it
will be still a matter of copy paste the file and just add what they want to do
in their request.
I am not sure how much this could be an issue to be honest and what could be
the problems for that person who is updating the config. I see on average
changes to those config files happen once per month.
I guess it is a tradeoff:
- if we don't have additional patch and someone wants to use them, they should
be adding manually the parameters to the file
- if we want to make it possible through POST, then we might make it prone to
issues during development and updating the files.
I kind of feel that both options give great benefit but they are suboptimal but
there are currently limitations in CircleCI that do not give us a better
option. In both cases people will need a readme and either copy-paste
parameters to the file or set parameters in the POST request. In that sense I
guess too many patches becomes a bit of overkill.
bq. By the way, I have also observed that the CircleCI CLI tool also removes
the license header when generating the config, so the current
.circleci/generate.sh also requires some minor manual intervention to add the
missed licenses. I have included a fix for this in the patch.
Great catch, thanks!
One thing that I am worried about and I am wondering whether there is a way to
make our lives easier - under Artifacts we will have all the logs from all the
runs which is super helpful but currently I don't see any identification of
which logs are for which run... So in case of 3 fails in 1000 runs I am not
sure how we can easily identify the logs we need. Any ideas? Not sure whether
we can add some identification to the logs for example. WDYT?
> Add a CircleCI job to run some tests repeatedly
> -----------------------------------------------
>
> Key: CASSANDRA-16625
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16625
> Project: Cassandra
> Issue Type: Task
> Components: CI
> Reporter: Andres de la Peña
> Assignee: Andres de la Peña
> Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I think it could be useful to have an optional CircleCI job to run some
> specific tests n times. That way, tickets could attach CircleCI runs showing
> that the changes don't make a certain ticket flaky or, conversely, that they
> fix a flaky test. Doing this systematically should mitigate the risk of
> introducing new flaky tests, and I guess it would be more convenient and easy
> to share than running the tests locally or on a private CI system.
> It would also be nice to have something similar in Jenkins, but I'm focusing
> this ticket on CircleCI because it's available also for non-committers, so
> assignees can run their tests before setting the tickets as ready for review.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
