In D6458#167772, @olasd wrote:

In D6458#167771, @olasd wrote:

Yeah, sure, I don't have a problem with that.

(That is, I don't have a problem with these changes landing first, as long as we make sure that eventually we have a proper way of reproducing test failures that have come out of "random" fixtures.)

Rebase

Add missing tests_data parameter to snapshot_swhid fixture

In D6458#167702, @olasd wrote:

Thanks for working on reducing the number of hypothesis fixtures!

I'm a bit concerned about the reproducibility of test results, given fixtures that pull random list elements, with no control on the sequence of test executions and on the seed of the python random module when the fixture is called. (Now that I've looked at swh.web.tests.data, I'm even more concerned :-))

I don't have an answer about "what to use?", unfortunately, except just going for exhaustive tests (i.e. running the test functions for *all* values of the origins in the test data set), which doesn't sound very compelling unless the size of the sample dataset is small, which doesn't look to be the case.

https://github.com/pytest-dev/pytest/issues/5463 has some background about concerns with respect to random seeding in tests.

Apart from that, I see that some of the function-level fixtures are doing ""heavy"" querying on the test data for information that is, in effect, static (e.g. the list of origins with more than two visits, etc.). I wonder if it would be possible to extract this logic to only run it once on initialization of the test data?

I initially wrote: we may want to initialize a single, module scoped seed_storage fixture with all data inserted, and make the storage fixture used by tests a function-scoped fixture which would clone this seed storage instance - I assume some tests have to *write* to the storage, so you can't just have one global read only storage fixture - but I now see that's what swh.web.tests.data does. Maybe _init_tests_data could be turned into that seed_storage module-scoped pytest fixture, instead of the current ad-hoc logic? This would also help us control the random seed used for generating the test data (allowing us to override it to reproduce test results)?

Forgot to remove content_swhid strategy

Fix typo in function name

Rebase

Still some work to do before I can accept the diff:

• add missing tests
• remove the use of the browse-origin-log view in codebase (grep for it)

In D6455#167506, @ardumont wrote:

lgtm

I suppose you'll align the other hypothesis strategies the same way in other diffs?

It seems that the browse-snapshot-log view is missing tests so we should create the file swh/web/tests/browse/views/test_snapshot.py
and implement tests here.

Looks good to me, thanks !

Looks good to me.

Looks good for the code but still some issues in the commit message (typo + formatting),
I would have done like this for instance.

Issues related to git dumb loading have been handled and the 5 dumb origins that were failing have been resubmitted through save code now and successfully loaded, closing this.

Looks good but some small changes are required.

I added some inline comments to handle.

Looks like the bug comes from that piece of javascript code. We should test if the pathname ends with /branches/ or /releases/ instead to activate the correct tab.

Looks good to me.

In T3608#71812, @jayeshv wrote:

Yes we can, the snapshot should be provided as query parameter in other views in that case.

Thanks. Then we can delete most of the code in https://forge.softwareheritage.org/source/swh-web/browse/master/swh/web/browse/snapshot_context.py

Testing will be a bit tricky, I will try to add some generic cypress test.

In T3608#71800, @jayeshv wrote:

@anlambert do you think we can deprecate following routes as well? I think they can be redirected to the corresponding swh/web/browse/views/<object_type>.py routes.

• /snapshot/(?P<snapshot_id>[0-9a-f]+)/content/
• /snapshot/(?P<snapshot_id>[0-9a-f]+)/directory/(?P<path>.+)
• / snapshot/(?P<snapshot_id>[0-9a-f]+)/directory/
• `/snapshot/(?P<snapshot_id>[0-9a-f]+)/content/(?P<path>.+)/'

we can delete a lot of code from snapshot_context.py module then

Just to be clear, you're looking to keep these URL working, but turn them into redirects over to swhid-centric URLs with context parameters (and drop the original view code from these URLs), correct?

Rebase

Fix test after rebase

Rebase

Rebase