diff --git a/Makefile b/Makefile index 632cac3..9921105 100644 --- a/Makefile +++ b/Makefile @@ -5,6 +5,7 @@ docker_cmd ?= docker docker_opts ?= --rm --tty --user "$$(id -u)" vale_cmd ?= $(docker_cmd) run $(docker_opts) --volume "$${PWD}"/docs/modules/ROOT/pages:/pages --workdir /pages ghcr.io/vshn/vale:2.15.5 --minAlertLevel=error /pages +sdd_vale_cmd ?= $(docker_cmd) run $(docker_opts) --volume "$${PWD}"/docs/modules/SDDs/pages:/pages --workdir /pages ghcr.io/vshn/vale:2.15.5 --minAlertLevel=error /pages preview_cmd ?= $(docker_cmd) run --rm --publish 35729:35729 --publish 2020:2020 --volume "${PWD}":/preview/antora ghcr.io/vshn/antora-preview:3.1.2.3 --antora=docs --style=syn .PHONY: all @@ -16,9 +17,13 @@ clean: rm -rf $(out_dir) '?' .cache .PHONY: check -check: +check: check-sdds $(vale_cmd) +.PHONY: check-sdds +check-sdds: + $(sdd_vale_cmd) + .PHONY: preview preview: $(preview_cmd) diff --git a/docs/modules/SDDs/pages/.vale.ini b/docs/modules/SDDs/pages/.vale.ini new file mode 100644 index 0000000..c6edbd6 --- /dev/null +++ b/docs/modules/SDDs/pages/.vale.ini @@ -0,0 +1,10 @@ +StylesPath = /styles +MinAlertLevel = warning # suggestion, warning or error + +# Only check Asciidoc files +[*.adoc] +BasedOnStyles = Microsoft +Microsoft.GenderBias = suggestion +Openly.GenderBias = suggestion +Microsoft.Dashes = suggestion +Microsoft.Quotes = suggestion diff --git a/docs/modules/SDDs/pages/0030-argocd-multitenancy.adoc b/docs/modules/SDDs/pages/0030-argocd-multitenancy.adoc index 57626cf..18899b1 100644 --- a/docs/modules/SDDs/pages/0030-argocd-multitenancy.adoc +++ b/docs/modules/SDDs/pages/0030-argocd-multitenancy.adoc @@ -44,7 +44,7 @@ However, if another team wants to deploy applications on the cluster through Pro Each team's root application is managed independently from the default root application (`root`). The bootstrap process for the additional root applications is initiated by defining the team in the configuration hierarchy in parameter `syn`. -This parameter is not associated with a specific component and becomes a reserved parameter name which components can't use. +This parameter isn't associated with a specific component and becomes a reserved parameter name which components can't use. The parameter has two fields `owner` and `teams`. Field `owner` makes the team who owns the cluster explicit. This allows the implementation to ensure that the owning team's applications are always managed through the default `root` application, even if that team has some explicit assignments for applications in `syn.teams`. diff --git a/docs/modules/SDDs/pages/0031-component-version-tracking.adoc b/docs/modules/SDDs/pages/0031-component-version-tracking.adoc index 0d05457..c8f1edd 100644 --- a/docs/modules/SDDs/pages/0031-component-version-tracking.adoc +++ b/docs/modules/SDDs/pages/0031-component-version-tracking.adoc @@ -17,17 +17,17 @@ This describes how we want to extend the Lieutenant API, CRD, and operator to al == Motivation Currently, component versions used in a Commodore compile are tracked in the cluster catalog repository. -They are stored in the commit message. +They're stored in the commit message. This approach has several drawbacks: -* The version information is not easily accessible programmatically. +* The version information isn't easily accessible programmatically. * To get an overview one needs to find every repository and check the commit history. To improve this situation, we want to introduce a central component version tracking system. The system should be centralized and accessible programmatically. Lieutenant is the central component for managing the cluster catalogs and already has a REST API. -It is backed by a CRD which already stores some state information and cluster metadata. +This API is backed by a CRD which already stores some state information and cluster metadata. We want to extend the Lieutenant API, CRD, and operator to store version information for each Commodore compile. @@ -66,7 +66,7 @@ Each version entry contains the following fields: Can be a branch name, tag, or commit hash. The `version` can point to different commits depending on when the compile was done. * `gitSha`: The commit hash of the commit referenced by the `version` field -With the `gitSha` and the `url` it is possible to uniquely identify the commit. +With the `gitSha` and the `url` it's possible to uniquely identify the commit. The `packages` and `instances` fields additionally contain: @@ -143,7 +143,7 @@ syn_lieutenant_cluster_compile_meta_tenant{cluster="my-cluster", url="https://.. === Commodore Commodore will be extended to send updated compilation information for catalog compilations which actually push a new catalog commit. -Any other catalog compilations will not update the compile metadata on the Lieutenant API. +Any other catalog compilations won't update the compile metadata on the Lieutenant API. Commodore will use its existing API token to push the compilation metadata to Lieutenant. @@ -154,7 +154,7 @@ https://github.com/projectsyn/commodore/issues/563[projectsyn/commodore#563] wan The current design with instance name as the top key allows for this. Configuration packages:: -Configuration package versions are not yet added to the commit message. +Configuration package versions aren't yet added to the commit message. We need to add them to the commit message and the Lieutenant API. == Alternatives diff --git a/docs/modules/SDDs/pages/0032-compile-pipeline.adoc b/docs/modules/SDDs/pages/0032-compile-pipeline.adoc index bd0aaeb..e2ad780 100644 --- a/docs/modules/SDDs/pages/0032-compile-pipeline.adoc +++ b/docs/modules/SDDs/pages/0032-compile-pipeline.adoc @@ -23,7 +23,7 @@ While we only aim to support GitLab at the moment, the architecture should be su Having a continuous integration solution unlocks a number of benefits: It solves the problem of configuration drift, where changes to the tenant repository might not be reflected in every cluster catalog because not all of them have since been compiled, and it lessens the burden on catalog maintainers who otherwise would need to locally compile each cluster individually. -It is already fairly straightforward to manually set up basic auto-compilation for individual tenant repositories without special support from Project Syn itself. +It's already fairly straightforward to manually set up basic automated compilation for individual tenant repositories without special support from Project Syn itself. At VSHN, such a solution has been in use for several years. However, certain features (such as automatic configuration of the compile pipeline) are hard to implement in a standalone fashion. @@ -47,7 +47,7 @@ This will go hand-in-hand with the existing repository management features in Li === Requirements for Pipeline Configuration Lieutenant imposes certain assumptions on the configuration of the pipeline: -Namely, the pipeline has to be set up on the tenant repository by way of adding (arbitrary) files to the repository, and it is configured through setting CI/CD variables on the repository. +Namely, the pipeline has to be set up on the tenant repository by way of adding (arbitrary) files to the repository, and it's configured through setting CI/CD variables on the repository. In particular, Lieutenant configures the following CI/CD variables: @@ -62,7 +62,7 @@ In particular, Lieutenant configures the following CI/CD variables: We add two new fields to the `GitRepoTemplate` (and, by extension, the `GitRepo`) CRD, under the `.spec` key, called `accessTokenSecretName` and `ciVariables`. The `accessTokenSecretName` field contains a reference to a secret. -If it is set, the Lieutenant operator will store an access token into this secret, which can be used to access the Git repository. +If the field is set, the Lieutenant operator will store an access token into this secret, which can be used to access the Git repository. In the case of GitLab, this would be a Project Access Token with read-write access to the repository. The `ciVariables` field contains a list of objects describing variable names and corresponding values. @@ -94,7 +94,7 @@ We add a new field to the `Cluster` CRD, under the `.spec` key, called `enableCo The field contains a boolean flag, which controls whether the compile pipeline should be enabled or disabled for this cluster. -It is optional; not specifying it is equivalent to setting it to `false`. +This field is optional; not specifying it defaults it to `false`. [source,yaml] ---- @@ -111,11 +111,11 @@ spec: We add new fields to the `Tenant` CRD: `spec.compilePipeline` and `status.compilePipeline` The `spec.compilePipeline` field contains configuration pertaining to the automatic setup of the compile pipeline on the tenant repository. -It is optional. +This field is optional. The `spec.compilePipeline` field contains a dict with the following fields: -* `enabled`: Boolean field which enables or disables automatic setup of compile pipelines for this tenant (regardless of whether it is enabled on the tenant's clusters). +* `enabled`: Boolean field which enables or disables automatic setup of compile pipelines for this tenant (regardless of whether automatic setup enabled on the tenant's clusters). * `pipelineFiles`: Dictionary containing file paths as keys, and file contents as values. These files will be added to the tenant's `gitRepoTemplate.templateFiles` by the Lieutenant operator. This field is optional; if absent, no new template files are added to the `gitRepoTemplate`. @@ -152,15 +152,15 @@ status: The Lieutenant Operator will be extended to automatically manage the compile pipeline for repositories where this is enabled (by way of deploying the CI config file in the tenant and the `enableCompilePipeline` field on the cluster). Since the compile pipeline has to interact with both the tenant repository as well as the cluster catalog repositories, it must be enabled on both corresponding resources for the configuration to be functional. -This way, it is possible to enable auto-compilation for some, but not all clusters on a tenant. +This way, it's possible to enable automated compilation for some, but not all clusters on a tenant. The operator will reconcile *GitRepos* as follows: * When `spec.accessTokenSecretName` is set, the operator generates an access token for the corresponding repository (via the repository host's API, using the API secret in `.spec.apiSecretRef`), and writes this token into a secret with the given name. In the case of GitLab, this is a Project Access Token. - The operator also runs a scheduled job which refreshes these tokens when they are close to expiring, or when they no longer exist on the repository host. + The operator also runs a scheduled job which refreshes these tokens when they're close to expiring, or when they no longer exist on the repository host. * The content of `.spec.ciVariables` is written to the repository's configuration on the Git host. - In the case of GitLab, it is written as CI/CD variables. + In the case of GitLab, each entry is written as a CI/CD variable. If the content of `.spec.ciVariables` changes, the corresponding configuration on the Git host should be updated. A scheduled job in the ooperator regularly checks for drift between `.spec.ciVariables` and the configuration on the Git host, and updates the latter if necessary. @@ -196,11 +196,11 @@ If a setup already includes a bunch of tenant repositories with manually configu + In particular, these repositories would already have a working `.gitlab-ci.yml` that probably could be left as-is, but can also be replaced by a lieutenant-managed one. + -Any existing manually created Project Access Tokens will be superseded by new auto-generated ones. +Any existing manually created Project Access Tokens will be superseded by new automatically generated ones. This will lead to a bunch of now-unused tokens needing to be cleaned up, but should otherwise work without requiring extra effort. External Catalog Repositories:: -There may be cases where the catalog repositories are not hosted on the same repository host as the tenant repository, in which case API access for the purpose of creating Project Access Tokens is unavailable. +There may be cases where the catalog repositories aren't hosted on the same repository host as the tenant repository, in which case API access for the purpose of creating Project Access Tokens is unavailable. The Commodore Compile Pipeline can still be used against such catalog repositories by specifying an SSH key to access them. + This can still be configured manually, and the automated configuration would not interfere. diff --git a/docs/modules/SDDs/pages/0033-commodore-component-instance-versioning.adoc b/docs/modules/SDDs/pages/0033-commodore-component-instance-versioning.adoc index 3b7f05d..0a7108f 100644 --- a/docs/modules/SDDs/pages/0033-commodore-component-instance-versioning.adoc +++ b/docs/modules/SDDs/pages/0033-commodore-component-instance-versioning.adoc @@ -18,7 +18,7 @@ It additionally details the options we chose to implement. With xref:0025-commodore-component-instantiation.adoc[SDD 0025], Commodore can instantiate a component multiple times per cluster if multiple aliases are specified. However, all aliases currently use version information from the base component. -Commodore does not currently support specifying different component versions for each alias. +Commodore doesn't currently support specifying different component versions for each alias. === Goals @@ -40,7 +40,7 @@ Support for providing different versions of Jsonnet dependencies is currently no Jsonnet dependencies are always provided from the main (non-instantiated) version of the component. If a component is to support multi-versioning, Jsonnet dependencies should therefore be compatible within a reasonable span of versions. -Similarly, if the component includes a Jsonnet library that is made available to other components, the version for the library is taken from the main (non-instantiated) version of the component. +Similarly, if the component includes a Jsonnet library that's made available to other components, the version for the library is taken from the main (non-instantiated) version of the component. Finally, if a component reads another component's default values, it will always see the default values of the main (non-instantiated) version of the component. @@ -62,7 +62,7 @@ This might force a component author to remove multi-version support in higher co === Automatically detecting multi-version support We could try to automatically determine whether a component supports multi-versioning, by way of checking whether the `${_base_directory}` parameter is used in the component's compile configuration and for Jsonnet expressions that refer to downloaded data. -However, automatically declaring components to be "safe for multi-versioning" carries some risk - even if a component is configured accordingly, it is not guaranteed that its provided Jsonnet libraries and/or its Jsonnet dependencies work if used across versions. +However, automatically declaring components to be "safe for multi-versioning" carries some risk - even if a component is configured accordingly, there's no guarantee that its provided Jsonnet libraries and/or its Jsonnet dependencies work if used across versions. Additionally, so far we've defined explicit flags for components to indicate that they support optional features, such as multiple instances. For all of those reasons, we've decided that component authors must explicitly declare whether multi-versioning is safe to use for their component. @@ -77,7 +77,7 @@ Making this change has no direct impact on the implementation of the multi-versi It might be possible to allow multiple versions of a component's Jsonnet libraries to be made available to other components. Other components would have to refer to the libraries using a specific instance's name. -This would change how components refer to libraries, and would cause components to be somewhat aware of the context in which they are used in order to refer to the correct instances. +This would change how components refer to libraries, and would cause components to be somewhat aware of the context in which they're used in order to refer to the correct instances. Since components should be modular and reusable, introducing this sort of coupling goes against the design principles of Project Syn. == References diff --git a/docs/modules/SDDs/pages/0034-commodore-component-dependencies.adoc b/docs/modules/SDDs/pages/0034-commodore-component-dependencies.adoc new file mode 100644 index 0000000..b3d4385 --- /dev/null +++ b/docs/modules/SDDs/pages/0034-commodore-component-dependencies.adoc @@ -0,0 +1,197 @@ += SDD 0034 - Commodore Component Dependencies + +:sdd_author: Simon Gerber +:sdd_owner: Aldebaran +:sdd_reviewers: VSHN Tech Teams +:sdd_date: 2026-08-17 +:sdd_status: draft +include::partial$meta-info-table.adoc[] + +[NOTE] +.Summary +==== +This SDD describes possible architectures which allow Commodore components to explicitly specify other components on which they depend. +==== + +== Motivation + +Currently, each Commodore component intrinsically depends on https://github.com/projectsyn/component-argocd[component-argocd]. +This dependency is special; Commodore https://github.com/projectsyn/commodore/blob/v1.34.1/commodore/component/compile.py#L266-L277[automatically injects a dummy `argocd.libjsonnet`] when compiling a component in isolation. + +Additionally, many components depend on monitoring stack components (https://github.com/projectsyn/component-prometheus[component-prometheus], https://github.com/appuio/component-openshift4-monitoring[component-openshift4-monitoring]) or on https://github.com/projectsyn/component-espejote[component-espejote]. + +These dependencies can't explicitly be expressed at the moment. +This has multiple drawbacks: + +* Authors of components which depend on other components need to use workarounds to make component compilation work. +The usual workarounds are fetching component libraries via `kapitan.dependencies` and replicating parts of the component's defaults. + +* Commodore has no way to verify that a cluster catalog includes all the components on which other components depend. +The catalog compilation only fails once a component library on which another component depends is missing. +Some components provide better error messages by explicitly checking that their dependencies are present in the Reclass inventory's `applications` array. + +We've been considering explicit component dependencies https://github.com/projectsyn/commodore/issues/690[for a long time] already. + +However, recently there's been an uptick of needless busywork associated with component dependencies, because we've moved some Jsonnet logic from the monitoring component libraries to the shared https://github.com/projectsyn/jsonnet-libs[Jsonnet library repository]. +This code move requires that all components that want to use the monitoring component helper libraries need to explicitly depend on the Jsonnet library repository in order for `commodore component compile` to work. +We would like to remove this explicit dependency on the Jsonnet library repository from components which only indirectly use the library repository through another component's component library. + +Explicit component dependencies allow us to remove the explicit dependency on the Jsonnet library repository from most components. +With explicit component dependencies, components don't need to know implementation details of component libraries that they consume. +Instead, components can simply declare that they depend on the components whose libraries they use. +This gives Commodore enough information to automatically include any direct component dependencies (including their Jsonnet dependencies) when compiling a component. + +=== Goals + +* Commodore components can specify other components on which they depend +* Commodore uses component dependency information for component compilation +* Commodore uses component dependency information for cluster catalog compilation + +=== Non-Goals + +* Automatic component inclusion in cluster catalogs based on dependency information +* Automatic component version resolution +* Nested component dependency resolution and fetching for component compilation + +== Design Proposal + +=== Dependency specification in the component + +// TODO(sg): Dependency groups? (group all monitoring dependencies -> enables validation of non-overlapping CEL?) + +// TODO(sg): use `._metadata.dependencies` instead of `commodore.dependencies`? Would probably make parsing in catalog compile easier. + +Commodore components can define other components on which they depend in Reclass parameter `commodore.dependencies`. +Since the parameter is specific to the component (rather than part of the component's default configuration), it must be set in the component's `.yml`, the same as `kapitan.compile`, `kapitan.dependencies` and `commodore.postprocess`. +Configuring dependencies in `.yml` ensures that the dependency definitions don't leak to other components. + +The content of parameter `commodore.dependencies` is expected to be an object where each key is a component name. +Commodore expects that the keys in `commodore.dependencies` follow the same rules as keys of https://syn.tools/commodore/reference/architecture.html#_dependency_discovery_and_versions[parameter `components`]. +Each entry of parameter `commodore.dependencies` is expected to hold an object with the following keys: + +* `url`: A URL pointing to the component's Git repository. +This field is used by component compilation to automatically fetch component dependencies. +This field is ignored by catalog compilation. +* `minversion`: An optional field which authors can use to specify a minimum required version for the dependency. +Commodore parses this field as a https://semver.org/[semantic versioning ("SemVer")] version prefixed with a `v`. +If the field isn't set, Commodore assumes that the component works with any version of the dependency. +Notably, arbitrary https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-tree-ishalsotreeish[Git tree-ish]s (which are supported for parameter `components..version`) aren't supported in this field. +* `requiredif`: An optional field which enables authors to express optional and situational dependencies (for example OpenShift-only, non-OpenShift-only). +The value is expected to be a https://cel.dev/[Common Expression Language (CEL)] expression. +The expression can reference cluster facts as `facts.`. +Additionally the expression can reference component parameters (the rendered contents of `parameters.`) as `config.`. +Other cluster metadata (dynamic facts, etc.) isn't available in the CEL expression. +For dependencies which are completely optional, the field can simply be set to `false`. + +==== Example + +The following configuration models the dependencies of https://github.com/projectsyn/component-cilium[component-cilium] in version `v4.1.11`: + +[source,yaml] +---- +parameters: + commodore: + dependencies: + openshift4-monitoring: + url: https://github.com/appuio/component-openshift4-monitoring + minversion: v6.11.3 + requiredif: 'facts.distribution == "openshift4" || facts.distribution == "oke"' + prometheus: + url: https://github.com/projectsyn/component-prometheus + requiredif: '!(facts.distribution == "openshift4" || facts.distribution == "oke")' + espejote: + url: https://github.com/projectsyn/component-espejote + requiredif: '(config.egress_gateway.enabled && config.egress_gateway.self_service_namespace.ips) || ((facts.distribution == "openshift4" || facts.distribution == "oke") && config.cilium_helm_values.kubeProxyReplacement == "strict")' + openshift-nmstate: + url: https://github.com/projectsyn/component-espejote + requiredif: 'config.egress_gateway.enabled && config.egress_gateway.egress_ip_ranges.exists(r, has(config.egress_gateway.egress_ip_ranges[r].auto_egress_interfaces) && config.egress_gateway.egress_ip_ranges[r].auto_egress_interfaces)' +---- + +=== Commodore component compilation + +Commodore component compilation renders an initial inventory for the component with just the component definition and the user-supplied input. +Commodore then reads `commodore.dependencies` from this initial inventory and determines which component dependencies to include based on each entry's `requiredif`. +The caller can steer dependency fetching by setting suitable cluster facts and component configurations in the user-supplied input. + +For dependencies which specify `minversion`, that version is used when compiling the component. +Using the version specified in `minversion` (if any) for component compilation trivially ensures that component changes that require a newer dependency version than the one specified in `minversion` result in a compilation error. +This ensures that component authors update their dependency `minversion` when they start using features introduced by a later version. + +For all other dependencies, the dependency's default branch is used when compiling the component. +Notably, using the oldest available tagged version of dependencies without `minversion` would be more equivalent to how we handle dependencies with explicit `minversion`. +However, doing so would introduce a lot of overhead, and isn't necessary for the currently specified semantics of `minversion`. + +After fetching the dependencies (using the already existing dependency fetching logic used in catalog compilation), the component compilation regenerates the temporary inventory with each dependency's defaults and component libraries included. +Additionally, this new temporary inventory will have each dependency added to the `applications` array. + +Afterwards, component compilation proceeds by calling Jsonnet-Bundler and Kapitan to render the component's manifests. + +Notably, the implementation doesn't recursively fetch dependencies. +Therefore, if any of a component's dependencies has further component dependencies, component authors must explicitly define those dependencies in the component compilation input files. + +TIP: When using the Project Syn component template, we recommend adding any indirect component dependencies in the component's test cases. + +=== Commodore catalog compilation + +Commodore catalog compilation collects the component dependency specifications for all included components after fetching the components included by the catalog. +The dependency specifications are unified by component name, and the minimum required version is the maximum of all specified minimum required versions. + +As noted in section "<<_dependency_specification_in_the_component>>", Commodore expects that matching keys in parameters `components` and `.commodore.dependencies` refer to the same component. +This assumption significantly simplifies matching required dependency versions to components that are included in a catalog. + +After dependency specifications are unified, Commodore verifies that each component dependency is explicitly included in the catalog with a compatible version +Notably, verification treats any component version Git tree-ish which doesn't parse as a SemVer version (prefixed with `v`) as higher than all SemVer versions. +Once that verification is completed, catalog compilation continues as usual. + +Notably, catalog compilation won't try to automatically include component dependencies or adjust component versions. +Making sure that a catalog includes all required components in a suitable version remains the responsibility of the operator defining the cluster catalog. +This ensures that we can keep the single pass component fetching stage for catalog compilation. + +=== Implementation Details/Notes/Constraints + +As noted in section "<<_dependency_specification_in_the_component>>", the implementation assumes that matching keys in parameters `components` and `commodore.dependencies` refer to the same component. + +We'll need to decide on a Python library which implements https://cel.dev[CEL]. +A quick search has found the following options: + +* https://github.com/cel-expr/cel-python[Google's cel-expr/cel-python] which wraps the Google C++ implementation of CEL in a Python module. +* https://github.com/hardbyte/python-common-expression-language[hardbyte/python-common-expression-language] which wraps the Rust https://crates.io/crates/cel[cel] crate in a Python module via https://pyo3.rs[PyO3]. +* https://github.com/cloud-custodian/cel-python[cloud-custodian/cel-python] which is a pure Python implementation of CEL. + +We haven't decided on one of these libraries yet, but most likely we'll either use `cel-expr/cel-python` or `hardbyte/python-common-expression-language`. + +For component version parsing, we'll probably use https://github.com/python-semver/python-semver[python-semver/python-semver]. + +=== Risks and Mitigations + +When enabling component authors to define component dependencies with version constraints, there's an inherent risk that some components can't be included in the same cluster catalog due to dependency version conflicts. +We don't expect this to be a problem as long as component authors use dependency version constraints sparingly. +Additionally, since the proposal only allows specifying a minimum version, the risk is reduced already compared to an implementation that supports full version constraints. + +//TODO(sg): add more if we find them during impl + +== Drawbacks + +The proposed implementation makes component compilation more complex. +In particular, component compilation will consume more network traffic and disk space because we now download the full component dependency instead of just the library. +Additionally, component compilation make take longer, both because we download more data and also because Commodore needs to do more setup work before the component can be compiled. + +== Alternatives + +=== Use Jsonnet-Bundler to implement component dependencies + +Instead of extending Commodore itself to support explicit component dependencies, we could try to use https://github.com/projectsyn/jsonnet-bundler[Jsonnet-Bundler] to manage component dependencies. +However, this approach has more drawbacks than the proposed design: + +* Jsonnet-Bundler doesn't have a native way to express a minimum required version +* Commodore catalog compilation would need a significant redesign to accommodate this approach +** Commodore's component version management would need to be integrated with Jsonnet-Bundler +** Commodore's component fetching would need to be replaced by Jsonnet-Bundler +* Jsonnet-Bundler doesn't work well when multiple components depend on the same component but specify different versions. + +== References + +* https://github.com/projectsyn/commodore/issues/690[Commodore #690: Add support for explicit component dependencies] +* https://github.com/projectsyn/jsonnet-bundler[projectsyn/jsonnet-bundler] +* https://cel.dev[Common Expression Language (CEL)] +* https://semver.org[Semantic Versioning ("SemVer")] diff --git a/docs/modules/SDDs/pages/index.adoc b/docs/modules/SDDs/pages/index.adoc index e8e09bc..02960d0 100644 --- a/docs/modules/SDDs/pages/index.adoc +++ b/docs/modules/SDDs/pages/index.adoc @@ -28,3 +28,4 @@ The all are using the xref:sdd-template.adoc[SDD Template]. * xref:0031-component-version-tracking.adoc[0031 - Central Component Version tracking] * xref:0032-compile-pipeline.adoc[0032 - Commodore Compile Pipeline] * xref:0033-commodore-component-instance-versioning.adoc[0033 - Commodore Component Instance Versioning] +* xref:0034-commodore-component-dependencies.adoc[0034 - Commodore Component Dependencies]