-
Notifications
You must be signed in to change notification settings - Fork 276
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
ngclient: Avoid loading targets metadata twice #1593
ngclient: Avoid loading targets metadata twice #1593
Conversation
Pull Request Test Coverage Report for Build 1470873479Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
Did you consider if we could use RepositorySimulator to test this (to continue avoiding the actual web server tests)? A similar mocking approach could work or this could even be a feature in RespositorySimulator if you think there might be more demand for it EDIT: actually the second loading of course loads the local metadata only so the repository side is irrelevant and your mocking should work as is in a RepositorySimulator test |
It has to be extended a bit for delegations but why not doing it now. |
We discussed this already but documenting here: An implementation of delegation support for RepositorySimulator exists but not in develop yet The options for this PR are:
I think the latter is fine: this is not an urgent change |
okay, current RepositorySimulator should have basic delegation support now |
tests/test_updater_ng.py
Outdated
with patch.object( | ||
self.repository_updater, | ||
"_load_targets", | ||
wraps=self.repository_updater._load_targets, | ||
) as wrapped_load_targets: |
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 think this could mock builtins.open
to actually test for file loads: the test wouldn't then depend so much on knowledge of updater implementation details.
It's not a major thing I guess: If mocking open() is significantly more complex then let's not do it.
f86b045
to
3f6b439
Compare
Added the test in |
Now these changes are not compatible with #1680 ... |
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 like it, mocking open()
feels like the correct thing to check for and is readable.
LGTM to merge. Left two comments for you to decide.
tuf/ngclient/updater.py
Outdated
self._load_targets(role_name, parent_role) | ||
# The metadata for 'role_name' must be loaded | ||
# before its targets and delegations can be inspected. | ||
if not self._trusted_set.get(role_name): |
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.
more pythonic IMO:
if not self._trusted_set.get(role_name): | |
if role_name not in self._trusted_set: |
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.
yeah, very pythonic :) it is updated now.
# Run refresh, top-level roles are loaded | ||
updater = self._run_refresh() | ||
# Clean up calls to open during refresh() | ||
wrapped_open.reset_mock() |
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're adding a test for a specific bug fix, that makes sense... but this obviously leads to "shouldn't we check that refresh opens correct files the correct number of times as well?" Maybe a follow up issue if you don't feel like handling here?
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 planning to open an issue about testing the loading of metadata. Doing it now ... #1681
3f6b439
to
1792f1e
Compare
oof, I just understood what you mean (originally thought you just referred to a plain merge conflict)... this change looks trivial but with that other PR it means you need to handle the else-case in I think 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.
marking "request changes" for the merge conflict plus previous comment
When traversing the delegations tree looking for targets, avoid re-loading already verified targets metadata. Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
1792f1e
to
4db4737
Compare
It should be ready now. |
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.
LGTM, thanks
Fixes #1578
Description of the changes being introduced by the pull request:
When traversing the delegations tree looking for targets, avoid re-loading already verified targets metadata.
Please verify and check that the pull request fulfills the following
requirements: