Looks globally fine to me, but I have a few comments/requests.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 2 2020
Build is green
tox run is fine
Build has FAILED
@civodul I wanted to raise the topic of storing container metadata (in the style of what tools like pristine-tar do) here too, so thanks for giving me the chance :-)
I agree it might be a technical solution, *but*, I'm not sure I see the point.
Didn't you agree that having a "lookup service" from tarball/container checksums to SWHIDs (the Software Heritage identifiers, that can then be used to lookup stuff in the archive) would be enough to satisfy distro needs?
If yes, then "archiving container metadata" could be replaced by simply having a way to add entries to the lookup table. And allowing distros to do so is option that we can explore. (Once the service exists, of course.)
Build has FAILED
Build is green
Make the returned results a tuple of lists
Do I get it right that the primary reason why tarballs aren't systematically archived is that doing so would be too expensive storage-wise (no deduplication)?
Build is green
Build is green
Update: Improve tests implementation
I'll rewrite this using swh-model and only two endpoints for all types
I'll rewrite this using swh-model and only two endpoints for all types
Build is green
Landed as 248c277445adbae5813ba80ce0618858d8126634.
Replaced by linked diffs
Jul 1 2020
nice ;)
Build is green
- Use new swh.storage.algos.origin.origin_get_latest_visit_status utility function in revised get_origin_visit implementation
Build is green
more mypy vs. attrs-strict fighting
Build has FAILED
make mypy happy (hopefully)
Build has FAILED
restrict extra_headers to (bytes, bytes) only
Build has FAILED
improve bw-compat support, tests and hypothesis strategies
In T2344#43031, @moranegg wrote:Great news !!
Does this mean we need to be SWORD 3 compatible?
I'm not sure about popping the extra_headers off of the incoming metadata field right now. This feels like something we want to do long term, but if you do that right now, it means you're putting upgrades of swh.model and swh.storage (with support with the new field) and all loaders in lockstep of one another. If you upgrade swh.model now, you'll lose the extra_headers until swh.storage will be able to store them.
Landed in eda756252f2151ba602ae47646e35fab4a83ebc1
Build is green
heads up on status, storage related endpoints developed by vlorentz deployed in storage 0.9.0:
- origin-metadata (we already had but it got abstracted)
- content-metadata (new)
Build is green
This needs more work in order to reuse utility functions from storage and rewrite tests using hypothesis.
Looks good, some remarks above though (proposal to improve coverage).
Build is green
Agreed on irc that the priority of the task can be decreased, this:
- metadata field is kinda deprecated
- as this will soon get migrated to the metadata storage
- does not impact that many repositories
Build is green
Rebase