[
https://issues.apache.org/jira/browse/CASSANDRA-18024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630490#comment-17630490
]
Ekaterina Dimitrova edited comment on CASSANDRA-18024 at 11/8/22 3:36 PM:
--------------------------------------------------------------------------
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
easily found them from CircleCI but you might want to update the table for
future reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
{quote}bq. I'd definitively do/discuss that in a separate ticket.
{quote}
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI went a long road since where we were last
year already.
Overall, I am +1 to commit the current patch, thanks!
I verified I don't see anything else except repeated jobs being deleted in
GitHub, workflows also do not expose any repeated jobs at the moment (except
the multiplexer which shows only expected runs). I ran locally generate.sh with
the different flags for trunk and things were fine.
was (Author: e.dimitrova):
So my understanding - we completely remove the repeated jobs from LOWRES,
MIDRES and HIGHRES files. If someone wants to take advantage of those - they
should use generate.sh as described in the readme. Sounds neat and
non-controversial to me. Post-processing those 3 files instead of using the
script sounds terribly inefficient to me.
All links but trunk in the patch column are broken. Not an issue for me, I
easily found them from CircleCI but you might want to update the table for
future reference.
{quote}We should coordinate in which order we merge to reduce rebase pains.
This one is quite simple, I'd say.
{quote}
Thanks! Well, if you are all in all completely ready here, I'd say commit it
and I will rebase before doing the patches in the other one. But I truly
appreciate you trying to coordinate the efforts here. :)
{quote}At the moment using those files is considered legitimate IMO, otherwise
we wouldn't have them. I think we shouldn't fail CI just to print a message
that the user might already be aware of. Not sure about how else we could print
a warning without resorting to adding a specific job and failing the entire
workflow.
Also, note that the automatic detection of modified test is not a guarantee
that all relevant tests have been selected or run, and we'll always need human
supervision to verify that everything is included and actually run. The
automatic detection is just a helper so we don't have to write the parameters,
but IMO both assignee a reviewers should always take a look at what has been
run.
{quote}
+1
I'd definitively do/discuss that in a separate ticket.
+1 All good discussions but I would like to appeal to postpone more CI
improvements for after the 4.1 release. We are almost ready to commit last
patches to have CirlceCI ready for release. Let's focus on that and then we can
continue with incremental improvements. I am sure there are plenty of them we
can do and I am all in for great user experience but we need to be reasonable
too. And the current look of CircleCI went a long road since where we were last
year already.
Overall, I am +1 to commit the current patch, thanks!
I verified I don't see anything else except repeated jobs being deleted in
GitHub, workflows also do not expose any repeated jobs at the moment (except
the multiplexer which shows only expected runs). I ran locally generate.sh with
the different flags for trunk and things were fine.
> Circle repeat jobs are always triggered even if not necessary
> -------------------------------------------------------------
>
> Key: CASSANDRA-18024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18024
> Project: Cassandra
> Issue Type: Bug
> Reporter: Berenguer Blasi
> Priority: Normal
>
> It seems that when pushing a PR, the auto multiplexing of new tests triggers
> all multiplexing jobs, even if there are no tests present for that job.
> That is wasteful as it means spinning up many nodes etc for nothing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
