feat(helm): create helm charts with script to update generated.yaml

[0xj4f]

values.yaml holds the values for meta.yaml, change the team values according to your composition.

...
  teams: ['Front End Web', 'Back End Web', 'Mobile', 'Infrastructure']
  teamGroups:
    GroupA: ['Front End Web', 'Back End Web']
    GroupB: ['Front End Web', 'Mobile']
    GroupC: ['Back End Web', 'Infrastructure']

an init container will automatically update generated.yaml on runtime from the meta.yaml
scripts/update_teams.py

      initContainers:
        - name: update-generated
          image: "0xj4f/dsomm:util"
          command: ["python", "/app/update_teams.py"]
          volumeMounts:
            - name: meta-vol
              mountPath: /app/meta.yaml
              subPath: meta.yaml
            - name: generated-vol
              mountPath: /app/generated.yaml
              subPath: generated.yaml
            - name: out-vol
              mountPath: /mnt/out

Quick test

helm template dsomm-release ./devsecops-maturitymodel > output.yaml
kubectl apply -f output.yaml
kubectl port-forward svc/dsomm-svc 8080:8080

# to test if generated yaml has been updated
curl http://localhost:8080/assets/YAML/generated/generated.yaml | tail

[wurstbrot]

Hi @0xj4f ,

thank you for your effort!

I agree that most users will have an own generated.yaml. But I assume the generated.yaml will be in a different repository.
Also for the standard case without a generated.yaml in the organization, the original one from https://raw.githubusercontent.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data/refs/heads/main/src/assets/YAML/generated/generated.yaml should be used.

Can we add a feature toggle like customContentGenerated: true/false. If it is false, helm downloads the config map via:

      {{- tpl (.Files.Get "https://raw.githubusercontent.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data/refs/heads/main/src/assets/YAML/generated/generated.yaml") . | nindent 4 }}

(not validated if it would work).
If customContentGenerated=false it will use the configured one.

I also feel that a static added file generated.yaml will be outdated soon.

[0xj4f]

Hi @0xj4f ,

thank you for your effort!

I agree that most users will have an own generated.yaml. But I assume the generated.yaml will be in a different repository. Also for the standard case without a generated.yaml in the organization, the original one from https://raw.githubusercontent.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data/refs/heads/main/src/assets/YAML/generated/generated.yaml should be used.

Can we add a feature toggle like customContentGenerated: true/false. If it is false, helm downloads the config map via:

      {{- tpl (.Files.Get "https://raw.githubusercontent.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data/refs/heads/main/src/assets/YAML/generated/generated.yaml") . | nindent 4 }}

(not validated if it would work). If customContentGenerated=false it will use the configured one.

I also feel that a static added file generated.yaml will be outdated soon.

Hi @wurstbrot,

I just tested your request to make helm download the generated.yaml, but It's not working.
I think we can only reference it if it's inside the repo.

apiVersion: v1
kind: ConfigMap
metadata:
  name: generated-config
  namespace: {{ .Values.namespace }}
data:
  generated.yaml: |
    {{- if .Values.customContentGenerated }}
{{ .Files.Get .Values.customGeneratedFilePath | indent 6 }}
    {{- else }}
{{ tpl (.Files.Get "https://raw.githubusercontent.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data/refs/heads/main/src/assets/YAML/generated/generated.yaml") . | indent 6 }}
    {{- end }}

below is an output.yaml showing empty generated.yaml after doing helm template dsomm-release ./charts > output.yaml

would you like if I just update the initContainer to download the generated.yaml inside and make the url an ENV variable but the default value will be at https://raw.githubusercontent.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data/refs/heads/main/src/assets/YAML/generated/generated.yaml?

[wurstbrot]

Hi @0xj4f,

I thought about pushing the generated.yaml from the other repo in an action. But to download it in the init container (e.g. if an env. var like IS_CUSTOM_CONTENT_GENERATED is set to false) sounds better.
As an alternativ, the name could be like IS_DOWNLOAD_GENERATED_YAML.

[wurstbrot]

Just thought about it. I think we need an env like CUSTOM_CONTENT_GENERATED_DOWNLOAD_URL in order to define from where to download. As I said, often deployment repo is different from content repo (where you generate the YAMLs). For the moment we can skip authentication options.

[wurstbrot]

Hi @0xj4f,

should we keep this PR open, merge it or close it?

Kind regards
Timo

[vbakke]

Could you just try to explain the use case this PR is resolving, @0xj4f?
I'm not completely certain I understand what it is trying to achieve, and then it is hard to comment. :)

---

I don't want to derail this PR, but I have been think about the generated.yaml file. I really think that the team progress (teamsImplemented) should be separated from the activities, dimensions and all the descriptions, @wurstbrot.

At the moment it is hard to get the latest updated version from DSOMM-data, without overriding your teams' status, progression and provided evidence.

Can we add a feature toggle like customContentGenerated: true/false.
And if customContent is false, then DSOMM could automatically check GitHub if there was newer version on the master branch (or even as a release).

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity. 📆 It will be closed automatically in two weeks if no further activity occurs.

[github-actions]

This PR was closed because it has been stalled for 20 days with no activity.