[
https://issues.apache.org/jira/browse/CASSANDRA-17113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17627921#comment-17627921
]
Josh McKenzie edited comment on CASSANDRA-17113 at 11/2/22 7:17 PM:
--------------------------------------------------------------------
bq. The new -p flag generates only the pre-commit workflows, whereas the -s
flag generates only the workflows with separate approval steps for each test
job.
Does this still generate a separate "jdk11_jdk11, [jdk8_jdk8, jdk8_jdk11]" pair
of workflows, or does this also combine together all the pre-commit required
jobs into one workflow to be run from a top level approval? (edit: the linked
circle pipelines don't seem to have workflows in them so I can't infer from
there)
was (Author: jmckenzie):
bq. The new -p flag generates only the pre-commit workflows, whereas the -s
flag generates only the workflows with separate approval steps for each test
job.
Does this still generate a separate "jdk11_jdk11, [jdk8_jdk8, jdk8_jdk11]" pair
of workflows, or does this also combine together all the pre-commit required
jobs into one workflow to be run from a top level approval?
> Add flags to CircleCI generation script to setup the workflows
> --------------------------------------------------------------
>
> Key: CASSANDRA-17113
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17113
> Project: Cassandra
> Issue Type: Task
> Components: CI
> Reporter: Andres de la Peña
> Assignee: Andres de la Peña
> Priority: Normal
>
> CASSANDRA-16882 modified the CircleCI config to contain two separate pairs of
> j8/j11 workflows. The {{pre-commit_tests}} workflows are meant for patches
> that are mostly read for commit, and they have a single approval step on the
> Circle GUI to run the most relevant tests. The {{separate_tests}} workflows
> are meant for intermediate commits and special cases such as fixing flaky
> tests, and every test group requires manual approval on the Circle GUI. Both
> pairs of workflows are always created, so every commit/push creates the four
> workflows. None of these workflows runs anything unless manually approved on
> the GUI, not even the build.
> This ticket is a followup for those changes, and it aims to implement [this
> suggestion|https://lists.apache.org/thread/8bghc7ng18s83vd4m16ccpj89dy6bm7x]
> about having a script that enables the relevant workflows for each use case.
> I have modified the existing {{.circleci/generate.sh}} script to be able to
> generate different workflows.
> The new {{-p}} flag generates only the pre-commit workflows, whereas the
> {{-s}} flag generates only the workflows with separate approval steps for
> each test job. Both flags can be used together to generate the two pairs of
> workflows ({{-ps}}, {{-sp}}, etc.). The default option is generating all the
> workflows, so users can decide what workflow are they going to use in the
> CircleCI GUI, after pushing their changes. We can easily change the workflows
> that are generated by default to use the single pair of workflows that we
> think is better.
> Additionally, there is a {{-r}} flag that disables the first approval step of
> the generated workflows. For the {{separate_tests}} workflows it means that
> the build is automatically run, but the individual steps still need to be
> manually approved in the GUI. For the {{pre-commit_tests}} workflows, the
> {{-r}} flag will automatically run the build and the most relevant tests.
> For example, users pushing a mostly ready patch and wanting to run the tests
> at maximum speed would probably want to generate their config file with
> {{.circleci/generate.sh -hpr}} ({{-h}} for HIGHRES config, see
> CASSANDRA-16871).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
