You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, our controller repository contains references to the artifact crd in the Makefile, config/crd/bases/openfluxcd.ocm.software_artifacts.yaml, and config/default/kustomization.yaml.
Makefile: Contains targets to download external crds download-crd-deps. However, until now it only refers to the artifact crd. config/crd/bases/openfluxcd.ocm.software_artifacts.yaml: Contains an exact copy of https://github.com/openfluxcd/artifact/blob/main/config/crd/bases/openfluxcd.ocm.software_artifacts.yaml config/default/kustomization.yaml: Contains a link to https://raw.githubusercontent.com/openfluxcd/artifact/refs/tags/v0.1.1/config/crd/bases/openfluxcd.ocm.software_artifacts.yaml which is - again - a reference to the already copied and referenced artifact crd.
All these references seem a bit hard to maintain (which was already reported, when we changed the gvk of artifact).
Additionally, I would argue that such external CRD should not be copied in our controller repository. This harms the principle of a single source of truth.
I would even go so far as to argue that we should not make any reference to this artifact CRD in this repository as the hardcoded definition on a pinned version limits the user and developer in their scope. I would propose that users have to deploy/install their artifact CRD themselves (as it is also required for the helm- and kustomize-controller).
Done Criteria
...
Code has been reviewed by other team members
Internal technical Documentation created/updated
New / changed code is documented
Analysis of existing tests (Unit and Integration)
Unit Tests created for new code or existing Unit Tests updated
Integration Test Suite updated (includes deletion of existing unnecessary Integration Test and/or creation of new ones if required)
Enduser Documentation updated (if applicable)
Successful demonstration in Review
The text was updated successfully, but these errors were encountered:
Description
Currently, our controller repository contains references to the
artifact
crd in theMakefile
,config/crd/bases/openfluxcd.ocm.software_artifacts.yaml
, andconfig/default/kustomization.yaml
.Makefile
: Contains targets to download external crdsdownload-crd-deps
. However, until now it only refers to theartifact
crd.config/crd/bases/openfluxcd.ocm.software_artifacts.yaml
: Contains an exact copy of https://github.com/openfluxcd/artifact/blob/main/config/crd/bases/openfluxcd.ocm.software_artifacts.yamlconfig/default/kustomization.yaml
: Contains a link tohttps://raw.githubusercontent.com/openfluxcd/artifact/refs/tags/v0.1.1/config/crd/bases/openfluxcd.ocm.software_artifacts.yaml
which is - again - a reference to the already copied and referencedartifact
crd.All these references seem a bit hard to maintain (which was already reported, when we changed the
gvk
ofartifact
).Additionally, I would argue that such external CRD should not be copied in our controller repository. This harms the principle of a
single source of truth
.I would even go so far as to argue that we should not make any reference to this
artifact
CRD in this repository as the hardcoded definition on a pinned version limits the user and developer in their scope. I would propose that users have to deploy/install theirartifact
CRD themselves (as it is also required for thehelm-
andkustomize-controller
).Done Criteria
The text was updated successfully, but these errors were encountered: