Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: allow specifying revision history limit for deployments #8094

Merged
merged 1 commit into from
May 18, 2023
Merged

chore: allow specifying revision history limit for deployments #8094

merged 1 commit into from
May 18, 2023

Conversation

celonis-eg
Copy link
Contributor

@celonis-eg celonis-eg commented May 11, 2023

⚠️ Note on feature completeness ⚠️

We are narrowing the scope of acceptable enhancements to DefectDojo in preparation for v3. Learn more here:
https://github.com/DefectDojo/django-DefectDojo/blob/master/readme-docs/CONTRIBUTING.md

Description

Allows setting the number of revisions of a replicaset maintained by a deployment in Kubernetes. Sets a default value of retained revisions for each deployment (worker, beat, and django).

Test results

n/a as this only touches the helm templates.

Documentation

The values file is updated with sane defaults.

Checklist

This checklist is for your information.

  • Make sure to rebase your PR against the very latest dev.
  • Features/Changes should be submitted against the dev.
  • Give a meaningful name to your PR, as it may end up being used in the release notes.
  • Add the proper label to categorize your PR.

@github-actions github-actions bot added the helm label May 11, 2023
Copy link
Contributor

@dsever dsever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please take a look

helm/defectdojo/values.yaml Outdated Show resolved Hide resolved
@dsever dsever requested a review from alles-klar May 12, 2023 09:18
@celonis-eg celonis-eg requested a review from dsever May 12, 2023 11:08
helm/defectdojo/values.yaml Outdated Show resolved Hide resolved
Copy link
Contributor

@dsever dsever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please take a look at my additional comments

@celonis-eg celonis-eg requested a review from dsever May 15, 2023 19:15
Copy link
Contributor

@dsever dsever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to understand what would be the usecase of keeping different number of rev. for different types of deployments?

@@ -1,3 +1,4 @@
{{- $revisionHistoryLimit := or .Values.django.revisionHistoryLimit .Values.revisionHistoryLimit }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, so maybe I wasn't clear in my proposal about the simplification. I was thinking just to have one definition like .Values.revisionHistoryLimit and ommit under specific deployments in values. Like is in the e.g . https://github.com/bitnami/charts/blob/main/bitnami/apache/values.yaml .

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is actually an even better solution than just exposing a single value. If you want to set a standard value for all deployments it works exactly as you would want, while also providing more flexibility to users that want to specify different limits for different parts of the overall deployments 🤔

Copy link
Contributor

@dsever dsever May 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure, helm as is already complicated, @alles-klar what is your opinion?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is more flexible but also more complex. If there is a use case for it, the flexible one is ok. Personally can't imagine a relevant use case for this. I mean it is just the revision history and not nothing imported to customize per deployment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I felt that this was a pretty flexible and un-opinionated method that I have used in other helm charts in the past. I figured it might be a good fit here. Since you all have strong opinions on that topic then I will defer. Please take another look.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fwiw i left the conditional rendering (but not the conditional assignment) in so that users who did not specify this value in any other customizations. This will keep any templates from being unexpectedly modified by an opinionated statement of the default history limit by these templates and defer to Kubernetes's defaults. Hope that is okay.

@celonis-eg celonis-eg requested a review from dsever May 17, 2023 17:32
@@ -11,6 +11,9 @@ metadata:
helm.sh/chart: {{ include "defectdojo.chart" . }}
spec:
replicas: {{ .Values.celery.beat.replicas }}
{{- if .Values.revisionHistoryLimit }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just final polishing, so values by default parameters is disabled so then value is 10. What is the reason with this approach you are not using {{ .Values.revisionHistoryLimit | default 10 }} to save 6 LoC of flow control. It is not a big deal but code would be more readable

Copy link
Contributor

@dsever dsever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved

Copy link
Contributor

@mtesauro mtesauro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved.

@mtesauro mtesauro merged commit 3a65402 into DefectDojo:dev May 18, 2023
113 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants