Make path to downloaded binaries separately configurable #1679
Conversation
| @@ -17,7 +17,7 @@ void targets_autoclean_cb(Aktualizr &aktualizr, const std::shared_ptr<event::Bas | |||
| auto start = entry.installs.size() >= 2 ? entry.installs.end() - 2 : entry.installs.begin(); | |||
| for (auto it = start; it != entry.installs.end(); it++) { | |||
| auto fit = std::find_if(installed_targets.begin(), installed_targets.end(), | |||
| [&it](const Uptane::Target &t2) { return it->sha256Hash() == t2.sha256Hash(); }); | |||
| [&it](const Uptane::Target &t2) { return it->filename() == t2.filename(); }); | |||
There was a problem hiding this comment.
Can we guarantee that filename will be unique? I'm wondering if we should match more than just that.
There was a problem hiding this comment.
That's the target name and I think there are a lot of places where we rely on it being unique.
| std::vector<Uptane::Target> getStoredTargets() const { return package_manager_->getTargetFiles(); } | ||
| void deleteStoredTarget(const Uptane::Target &target) { package_manager_->removeTargetFile(target); } | ||
| std::ifstream openStoredTarget(const Uptane::Target &target) { | ||
| auto status = package_manager_->verifyTarget(target); |
eu-siemann
force-pushed
the
refact/bin-files
branch
from
dd0600c to
b3c884a
Compare
Signed-off-by: Eugene Smirnov <[email protected]>
Signed-off-by: Eugene Smirnov <[email protected]>
eu-siemann
force-pushed
the
refact/bin-files
branch
from
b3c884a to
46584ea
Compare
|
I've added a few unit tests to cover refactored methods and hopefully solved the remaining CI issues. |
Signed-off-by: Eugene Smirnov <[email protected]>
eu-siemann
force-pushed
the
refact/bin-files
branch
from
46584ea to
0d43dc9
Compare
|
|
||
| std::vector<Uptane::Target> PackageManagerInterface::getTargetFiles() { | ||
| std::vector<Uptane::Target> v; | ||
| auto names = storage_->getAllTargetNames(); |
There was a problem hiding this comment.
Why return just the names as strings from getAllTargetNames if we just construct fake Targets here?
There was a problem hiding this comment.
Do you mean why not construct fake targets in the storage method, or why construct them at all?
There was a problem hiding this comment.
Both, I guess. It looks like previously we were constructing Targets in SqlStorage::getTargetFiles() based on the hashes that were stored in the database. What's the benefit of losing that information?
There was a problem hiding this comment.
There is no benefit in storing this information. Those Targets were still fake and used only for bookkeeping, as the comment in API header states:
Get list of targets currently in storage. This is intended to be used with
DeleteStoredTarget and targets are not guaranteed to be verified and
up-to-date with current metadata.
For bookkeeping, it is sufficient to have only a filename.
I also think it is cleaner to keep in Storage only that logic that is directly related to reading/storing necessary information from db.
There was a problem hiding this comment.
Fair enough, thanks for clarifying!
Codecov Report
@@ Coverage Diff @@
## master #1679 +/- ##
===========================================
+ Coverage 66.79% 82.75% +15.95%
===========================================
Files 190 190
Lines 15066 12072 -2994
===========================================
- Hits 10064 9990 -74
+ Misses 5002 2082 -2920
Continue to review full report at Codecov.
|
Main changes: