allow the pathslicer to be a noop (with an empty slicing)

I concur with this analysis btw

Build is green

Build is green

Adapt according to suggestion

Fix cli wrap around ``

Thanks!

Adapt according to last discussion ^

Fix typos

Use correct repository

Align code and diff

Align diff description and the actual code

More typos to fix

Fix config name typos

Superseded by D6439 (provided it works)

Superseded by D6439 (provided it works)

In D6408#166674, @olasd wrote:

Rather than doing this, we should probably disable worker task events altogether (that is, run celery worker without the --events/--task-events flag)

Build is green

Adapt links

Build is green

Build is green

Rebase

no

Rewrote sentences

Build is green

Just concentrate on save forge for now

*old comment not submitted*

An alternative to annotating synthetic refs: add a "type" or "forge_type" attribute to snapshots.

Ah, another question I've been thinking about: should we go back to existing visits of git repositories and give them a new, pruned snapshot? Our data model now allows it: we can just append a new final OriginVisitStatus pointing at a pruned snapshot.

In D6424#166886, @ardumont wrote:

@dachary It'd be nice if you could describe what this is about in the commit message and
the diff description (if you actually provide a commit description, then when you create
the diff, the commit message is used as a description bootstrap). I know it's more work
for you but it happens that:

1. it helps the reviewers to have some context directly here (without having to follow

between a multitude of tasks. FYI, I've followed through the task but it's not enough,
i need to also dig in that arborescence of tasks).

2. is also how we are doing that in every other modules ;)

3. the curious could learn a thing or 2 even if they don't do a proper review.

Please and thanks in advance.

Cheers,

In T3627#71809, @zack wrote:

Thanks for your feedback @olasd. I see three main arguments raised there: (1) the raciness of archiving those data via other means (= related forks), (2) the completeness of our canvassing of synthetic refs, (3) annotating rather than not archiving "synthetic" refs.

For (1), sure, it's racy, hence we could lose stuff that gets removed from GitHub before we have the time to archive it. But this is a drop in the ocean in comparison with our lag/backlog.

@dachary It'd be nice if you could describe what this is about in the commit message and
the diff description (if you actually provide a commit description, then when you create
the diff, the commit message is used as a description bootstrap). I know it's more work
for you but it happens that:

I'm gonna attend to this soon.

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.

rSPSITE6a233452cd48 fixed the prometheus node exporter.

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

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