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

SONAR-24105 remove 9.9 deprecated feature #616

Closed

Conversation

jCOTINEAU
Copy link
Collaborator

@jCOTINEAU jCOTINEAU commented Jan 8, 2025

SONAR-24105

Part of

Please ensure your pull request adheres to the following guidelines:

  • explain your motives to contribute this change: what problem you are trying to fix, what improvement you are trying to make
  • Document your Changes in the CHANGELOG.md file of the respected chart as well as the Chart.yaml

Copy link
Collaborator

@carminevassallo carminevassallo left a comment

Choose a reason for hiding this comment

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

Hey @jCOTINEAU,

I think we can delete more :) If I look at the latest sonarqube LTS, we have also image.pullSecret and postgresql.postgresqlServer to be removed. On the latest sonarqube-dce LTS we have image.pullSecret on both application and search nodes.

@jCOTINEAU
Copy link
Collaborator Author

indeed, i completely overlooked those, completely missed the search, might have made a wrong checkout.

@jCOTINEAU jCOTINEAU force-pushed the feature/jc/SONAR-24105-remove-9.9-deprecated-feature branch from f6805c2 to 77820fc Compare January 8, 2025 16:03
Copy link

sonarqube-next bot commented Jan 8, 2025

@@ -223,7 +223,7 @@ metadata:
heritage: Helm
data:
SONAR_JDBC_USERNAME: sonarUser
SONAR_JDBC_URL: "jdbc:postgresql://%!s(<nil>):5432/sonarDB"
SONAR_JDBC_URL: "jdbc:postgresql://:5432/sonarDB"
Copy link
Collaborator Author

@jCOTINEAU jCOTINEAU Jan 8, 2025

Choose a reason for hiding this comment

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

here this highlight a problem we had before, in this test case we have no jdbcoverwrite as well as postgresql.enabled=false.

Hence the default data in the configmap does not make sense as no database as been configured.

i am creating a hardening ticket to ensure all our files, config map, secret and so on, are created only when it make sense.

Here for example the configmap should exist only if jdbcoverwrite or postgresql.enabled, and should fail fast in dce

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants