In test_metadata_serialization.py "test_case_data" is actually a string
when the decorator calls the actual test functions.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
By configuring mypy to show error codes when we get a warning by mypy
we will receive an error code as well.
Those error codes are useful when you want to disable specific mypy
warning for a line with:
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
When traversing the delegations tree looking for targets,
avoid re-loading already verified targets metadata.
Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
Add sanity types checks on Targets delegation paths and
path_hash_prefixes making sure that they are strings.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
This changes `TrustedMetadataSet` to return new trusted Metadata
on successful calls of the `update_<role>` functions and also
changes `Updater._load_targets` to return loaded metadata as well
Signed-off-by: Ivana Atanasova <iyovcheva@iyovcheva-a02.vmware.com>
This change edits the ngclient `Updater` to traverse the delegation
tree on nodes, instead of edges in order to skip already visited
nodes.
For more detailed clarification, please review
theupdateframework/specification#177
Fixes#1528
Signed-off-by: Ivana Atanasova <iyovcheva@iyovcheva-a02.vmware.com>
Consistent snapshot and consistent targets are now
extensively tested in test_updater_consistent_snapshot.py.
Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
After the recent changes there are a couple of new pylint warnings that
appeared.
They are caused by the new test file that was added
test_updater_top_level_update.py and the limit of public functions was
reached in the TestMetadata class in test_api.py
The warnings should be addressed before enabling all of the linters
on the tests files.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Existence of py.typed in the top-level package tells users of the
packages that the packages are annotated.
This should fix mypy errors like this in downstream projects:
error: Skipping analyzing "tuf.api.metadata":
found module but no type hints or library stubs
Fixes#1633
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
Address or disable pylint warnings raised on all test files inside
the "tests/" directory testing the code of the new implementation.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
_ is often used when a function returns multiple values and you need
a sub-portion of them. Then, those values that are unnecessary can be
named _.
Currently, pylint warns us that this is not a good variable name, so
fix that.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Pylint reported a couple of warnings flagged as "duplicate-code".
We were truly duplicating code - one of the examples was when we
imported the same objects from tuf/api/metadata.py:
MetaFile, Role, Root, Snapshot, TargetFile, Targets, and Timestamp
in two separate modules.
So, I thought we do want to be repetitive here and include that code at
both modules. The problem is that besides importing the above
classes the modules imported other classes from tuf.api.metadata.py
and there was no way to disable this check.
I searched and found out that this is a known problem:
https://github.com/PyCQA/pylint/issues/214.
That's why the only solution I see is to disable this warning
temporarily and hoping that one day when this issue is fixed we will
remember to turn it on again.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
In order to make the `RootVersion` test cases understandable it's
better if we use keywords and don't split the different RootVersions
into multiple lines.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
test_sign_verify() is testing too many cases and after the recent
pylint warning about the usage of too many local variables it became
clear it's time to split this test function.
I decided to split it logically as half of the function was about
failures connected with verify.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Except for 'root' role, RepositorySimulator does not
keep previous metadata versions, it always serves the latest
one. The metadata version check during fetch serves mostly
for informative purposes and removing it allows generating test
metadata with mismatching version.
Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
Extend the TestRefresh cases with additional checks
for expected metadata files and their content written
on the file system.
Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
Mark roles as a Mapping to indicate that users should not add or remove
values from the dictionary during the lifetime of the Root object)
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Add ngclient/updater tests following the top-level-roles metadata
update from the specification (Detailed client workflow)
using RepositorySimulator.
Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
* current workflow only needs to read git content
* if the workflow in the future does need write access, it's good to
see permissions explicitly changing
For context: "pull_request" runs never have write access anyway, so this
significantly changes only the "push" runs that happen when branches are
merged to develop.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
This is a minimal test case to show the basic functionality:
I'd like to update most of the tests to use the implicit method
but would like to do that when there's less churn in these tests.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
Refresh can still be done explicitly (so client has more control over
when data is downloaded) but there's no reason we can't do it
automatically as well: Call refresh() from get_targetinfo() if
top-level targets is not loaded.
Update API documentation accordingly.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
By default pylint does format checks:
https://pylint.pycqa.org/en/latest/technical_reference/features.html?highlight=format#format-checker
The problem is we also use black and isort who have format checkers as
well. This makes pylint format checks obsolete.
Also, it's possible that you would want to disable a warning and you
can end up in the situation where you will have to disable it for
two tools altogether.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
