[
https://issues.apache.org/jira/browse/CASSANDRA-18731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756921#comment-17756921
]
Ekaterina Dimitrova commented on CASSANDRA-18731:
-------------------------------------------------
Not a full review, but I skimmed through the patch and left some comments on
the patch.
I have a question - this layer is where the descriptions will be, but there
should be scripts that take the config from the yamls and create a config for
pipelines for whatever software we use - CircleCI, Jenkins... Is this correct?
Something similar to what [~dcapwell] was suggesting in CASSANDRA-17600?
For example, the config_template for CircleCI will be populated by checking
what pipelines are described; it will populate some default CircleCI
parameters, and the rest of the C* specific options will be pulled from this
pipeline and jobs config? Do I understand correctly? Like having a default
template with parameters populated based on this layer, and the pipelines will
be multiplicated again based on the pipelines described here(pre-commit, etc)?
> Add declarative root CI structure
> ---------------------------------
>
> Key: CASSANDRA-18731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18731
> Project: Cassandra
> Issue Type: Improvement
> Components: CI
> Reporter: Josh McKenzie
> Assignee: Josh McKenzie
> Priority: Normal
> Fix For: 5.x
>
>
> Currently we have a somewhat declarative structure in .circleci, however
> there's still quite a bit that's baked in (resource limitations, parallelism,
> which suites qualify for which pipelines (pre-commit vs. post-commit vs.
> ???), etc). Further, while CASSANDRA-18133 brings the build scripts in-tree,
> all these parameters (pipelines, env vars, job definitions, resource
> constraints) are all still scattered throughout the shell scripts and/or
> reliant on the {{JenkinsFile}} to determine what suites comprise what
> pipelines.
> This ticket aims to decouple the definition of pipelines and jobs for CI from
> the implementations themselves. The goal here is to define, establish, and
> test both the base config and some helper methods to provide _other_
> configurations (circle, ASF CI, etc) the tools they need to programmatically
> inherit base CI config from a purely declarative structure.
> Follow-up tickets will involve rewriting the in-tree build scripts and
> JenkinsFile generation to rely on this structure, as well as integrating the
> config parsing unit tests into our CI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
