perf-regression: Improve the management of multi quarkus native builder image versions
- Dominant language
- Java
- Stars
- 302
- Forks
- 232
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 114
Description
### Describe the feature here
The current perf-regression architecture is built on top of container build. It's quite handy when it comes to building the same native app with distinct quarkus versions on different operating systems.
On the other hand, quarkus is chosing the native builder image versions on its own. In #5452 we faced a situation where we were comparing native images built with java 17 and 21. Obviously the results were not meaningful in terms of camel-quarkus regression.
As such we would need to improve that situation, for instance:
+ Log a warn when distinct native builder image versions are detected ?
+ Compute what versions of native builder image is best suited to compare all camel-quarkus versions under test ?
+ Pass an option to force the value ala `-Dquarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-mandrel-builder-image:jdk-17` ? And then deprecated `-umnb` option ?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading the perf-regression architecture built on container build and the handling of Quarkus native builder image versions. Review the context from #5452 and compare the proposed warning, version-selection, and forced builder-image approaches. Done means native-image comparisons use compatible builder versions or clearly report when they do not.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100