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

refactor: adjust configuration management and smoke test setup to support production config by default #185

Open
mattp-swirldslabs opened this issue Sep 17, 2024 · 2 comments
Labels
Improvement Code changes driven by non business requirements

Comments

@mattp-swirldslabs
Copy link
Contributor

As a Block Node administrator
I want production configuration by default
so that I can minimize dealing with app.properties changes

  • Currently, smoke_test.yaml runs the smoke tests using gradle run to verify with smoke_test.sh
  • It's more difficult to override the default configuration because this does not use a test app.properties file when it starts the Block Node
  • Record files like: MediatorConfig.java and NotifierConfig.java currently must be defaulted to non-production values (e.g. 1024 for the ring buffer rather than a more realistic prod value like 67108864) so that the smoke test does not throw an OutOfMemory error.
  • As a result, the production app.properties file must contain the prod values instead to override the defaults when running in a container.

Perhaps we should change the CI tests to:

  1. Run the smoke tests via docker rather than gradle. Gradle is strictly used for build and development.
  2. Set the defaults in the config record files like MediatorConfig.java and NotifierConfig.java to the production defaults
  3. Remove the override values in app.properties to minimize the configuration burden.
  4. Leverage the test app.properties inside the container noted in Create LICENSE #1 to override the production defaults with test config.
@mattp-swirldslabs mattp-swirldslabs added the Improvement Code changes driven by non business requirements label Sep 17, 2024
@a-saksena a-saksena assigned a-saksena and unassigned a-saksena Sep 17, 2024
@a-saksena
Copy link
Contributor

@georgi-l95 , @AlfredoG87 -- Can you check if this is a good onboarding story for Atanas?

@AlfredoG87
Copy link
Contributor

Yes I think is a good story for Atanas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Improvement Code changes driven by non business requirements
Projects
None yet
Development

No branches or pull requests

3 participants