Closed Karm closed 7 months ago
eh, gonna fix WInodws
The problem is that my code is now forcing inContainer version check even on a system where container might not be available, e.g. Windows. I think I'd just drop the ability to specify threshold for container apps specifically. We haven't had container specific thresholds anyway to date I'd say.
Nope. The problem was newlines in the fake multiline native-image.cmd....
This is ready for a review now...
@zakkak notes addressed, merging
fixes #228
Thresholds properties
We need to switch on and off certain tests depending on native-image versions used, on host vs. container and most importantly, based on Quarkus version.
We use method annotations for that, e.g.
@IfQuarkusVersion(min = "3.6.0")
, or@IfMandrelVersion(min = "23.0.0", inContainer = true)
.We also use properties in text files to validate whether particular thresholds were crossed, e.g. whether the app used more RAM than expected or whether the measured time delta between JVM HotSpot mode and native-image mode was bigger than expected.
e.g.
The current
.conf
format enhances.properties
format with the power of using the annotation strings, see:Properties are being added to a map top to bottom, overwriting their previous values unless an
@If
constraint fails. If a condition fails, the following properties are not added to the map until the next@If
constraint is met.If two
@If
constraints follow immediately one after the other, they both MUST be true to process the following properties.Take a look at ThresholdsTest.java and its
threshold-*.conf
test files for a comprehensive overview.The parsing logic is compatible with plain
.properties
files as we have been using before, i.e. any key-value pair where the value is interpreted as the long type.