-
Notifications
You must be signed in to change notification settings - Fork 0
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
Eagerly load, but lazily fail environment variables on startup #641
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is so we can run the type generation script without the setup. Makes it easier to run the type generation locally without setting up a bunch of needless variables. This does however make detecting missing environment variables less likely at startup. We should look into how we can make those detected at startup, but not when using `--save-swagger` arguments.
This patch introduces a abstraction called `Prop` which we use to load required properties. These will be loaded eagerly so we can crash on startup if they are missing. But they also allow us to run parts of the project without them. Allows us to run applications with `--save-swagger` argument without variables that isn't required until runtime.
This should allow us to use dependencies from `common` in `scalatestsuite` while keeping the base suite available for `common` itself.
585cb9e
to
06384a2
Compare
Caused more trouble than it was worth with this implementation. Might be worth it to revisit in the future.
0e4b14e
to
09e6ad3
Compare
09e6ad3
to
62e5f79
Compare
I would argue slightly more readable and extendable
gunnarvelle
approved these changes
Apr 4, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🥇
This makes it so props can be generic and return other types than string :^)
gunnarvelle
approved these changes
Apr 4, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Har hatt lyst til å gjøre noe som ligner på dette før, men ikke følt verdien var verdt omskrivingen før @katrinewi fikk problemer med å kjøre type genereringen lokalt pga en tullete manglende variabel.
Denne lar oss kræsje applikasjonene på oppstart dersom påkrevde variabler mangler, men fremdeles ikke kræsje med
--save-swagger
flagget.Infører ny
Prop
klasse istedenfor å hente en string med en gang vi kallerprop
.Når vi treffer et
prop
kall så forsøker vi å laste prop'en og lagrer resultatet i enProp
klasse.Denne klassen brukes så igjen senere til å sjekke om prop'en ble lastet inn riktig eller ikke fantes.