-
Notifications
You must be signed in to change notification settings - Fork 1k
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
[feature] Add hooks for validate method #17856
[feature] Add hooks for validate method #17856
Conversation
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
#17879 has been merged to develop2, please merge from develop2 to get rid of HookManager instantiation issue. |
conans/client/graph/compatibility.py
Outdated
compatibility_file = os.path.join(compatibility_plugin_folder, "compatibility.py") | ||
if not os.path.exists(compatibility_file): | ||
raise ConanException("The 'compatibility.py' plugin file doesn't exist. If you want " | ||
"to disable it, edit its contents instead of removing it") | ||
mod, _ = load_python_file(compatibility_file) | ||
self._compatibility = mod.compatibility | ||
self._hook_manager = HookManager(HomePaths(cache_folder).hooks_path) |
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.
You shouldn't instantiate HookManager
here anymore.
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.
Done, consuming hook_manager from conan_api.config.hook_manager instead. Please, see the commit 59c6a83
unknown_mode = global_conf.get("core.package_id:default_unknown_mode", default="semver_mode") | ||
non_embed = global_conf.get("core.package_id:default_non_embed_mode", default="minor_mode") | ||
# recipe_revision_mode already takes into account the package_id | ||
embed_mode = global_conf.get("core.package_id:default_embed_mode", default="full_mode") | ||
python_mode = global_conf.get("core.package_id:default_python_mode", default="minor_mode") | ||
build_mode = global_conf.get("core.package_id:default_build_mode", default=None) | ||
self._modes = unknown_mode, non_embed, embed_mode, python_mode, build_mode | ||
self._hook_manager = HookManager(HomePaths(self._home_folder).hooks_path) |
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.
Do not instantiate here a new HookManager
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.
Ditto.
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
@@ -44,6 +44,7 @@ def __init__(self, conan_api): | |||
""" | |||
global_conf = conan_api.config.global_conf | |||
self.global_conf = global_conf | |||
self.conan_api = conan_api |
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.
Talked with @AbrilRBS about this. It looks better than changing more methods because we need to forward the hook manager to run_validate_package_id
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'd like to learn more about the real use cases to be able to figure out the scope of definition and application of these hooks.
# These are the nodes with pref (not including PREV) that have been evaluated | ||
self._evaluated = {} # {pref: [nodes]} | ||
compat_folder = HomePaths(conan_app.cache_folder).compatibility_plugin_path | ||
self._compatibility = BinaryCompatibility(compat_folder) | ||
self._compatibility = BinaryCompatibility(compat_folder, self._hook_manager) |
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.
Do we really want to execute the validate()
pre/post hooks for all combinations of binary compatibility?
Can I have some examples of potential usages of the hook, and what does it mean to execute it for every binary compatibility hypothesis?
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 is still an open question
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 dont think so, I could remove it and add in the future, in case having a case.
For now, we only have the CI case to be covered.
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.
Then lets remove it. It is better to be minimalistic first, then add things when real use cases are requesting it.
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.
Done, removed on the commit 57878a1
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'd still like to see a more real use case for the feature, I haven't fully understood if it makes sense to be in the compatibility or not.
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.
The only real case listed right now is related to the CI: When the CI needs to skip a build, being checked in the pre_validate, but we do not want to change the recipe, by adding a new rule to raise ConanInvalidConfiguration.
About the compatibility I do not see a real usage right now, because it's related to binary compatibility mechanism, sounds be something unrelated to the validate stage.
conans/client/hook_manager.py
Outdated
"pre_validate_build", "post_validate_build", | ||
"pre_validate", "post_validate", |
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.
If we can cover the real-world use cases with just 1 of these hooks, I'd go for that, do the minimal changes to satisfy the need.
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.
So far, we have pre_validate
requested in CCI as a real case, so the CI could skip the build for those cases when the glibc version is too old but the project requires a newer version (e.g. Qt), without injecting changes in the validate() which is really consumed by users.
For other cases, @jcar87 can tell us more about it.
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.
pre_validate
as a minimum
I think post_validate
is useful too, in case ConanInvalidConfiguration
is raised in the implementation
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.
@memsharded I'll drop the hook for validate_build
.
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.
Done, removed validate_build hook on the commit a71eaaa
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Motivation
Hello!
This PR brings a new hooks for validate() methods
The intention is to help CI services validate a build without touching the recipe, by adding an extra layer of validations. For instance, the CI environment could not build a determined package due to custom settings, or some system library is not available because the O.S. is too old.
Details
The
validate
don't have a specific command, like export or build, so I usedconan create
to get a ride and check if is working.Also, the method is not defined by default, which means, the hook will only run when this method is defined in the recipe.
EDIT: This PR originally covered
validate_build
too, but the PR scope is now reduced to only covervalidate
. See the thread #17856 (comment)Automation
Changelog: Feature: Add hooks for validate method:
pre_validate
andpost_validate
.Docs: conan-io/docs#4013
/cc @jcar87
develop
branch, documenting this one.