-
Notifications
You must be signed in to change notification settings - Fork 3k
Fixed recordedBuildConfigFile absolute path resolution #46872
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
Fixed recordedBuildConfigFile absolute path resolution #46872
Conversation
Status for workflow
|
| : Path.of(this.recordedBuildConfigFile); | ||
| if (previousBuildConfigDump == null) { | ||
| return recordedBuildConfigDirectory.toPath() | ||
| .resolve("quarkus-" + launchMode.getDefaultProfile() + "-config-dump"); |
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.
I was having a look at the original issue and is it expected we are not taking into account quarkus.config-tracking.file-suffix?
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.
We could. We'd need to refactor the current implementation further to do that.
It will come at a cost of always resolving the the build time config and bootstrap the app even on the first build (when the config dump from the previous build does not exist, since we will not know about that).
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.
Does it make sense to have a config property for it if we can't honor it?
To clarify, I wonder if we should just drop it if it can't be honored.
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.
No, it's used but by the process dumping the used config options during the build. This mojo is another client that reads that file. So all the options are actually used.
I think you had a good point though, we could potentially re-use the same option used by the build process in this mojo.
Perhaps we could keep the existing one but use it only if a user configured values explicitly.
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.
No, it's used but by the process dumping the used config options during the build.
Yeah, I had that in mind but does it make sense to make it configurable if it's hard to propagate this config everywhere?
What's the value of allowing people to adjust the suffix?
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.
Apparently, that's what @jprinet was experimenting with, generating config dumps for different profiles: local vs CI, afaiu.
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.
Exactly, when using the quarkus-build-caching-extension to make the Quarkus build goal cacheable, a recommendation is to check in the dump config in the Git repository.
You may have several versions of this dump config depending on several factors (os, arch...)
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.
Feel free to merge this. I'm just unsure it actually solves the initial issue, even if it's a step in the right direction.
|
I'd say it fixes the issue taking the current design into account. We could look into config re-use as a follow up enhancement. |
Fixes #46726