Build has FAILED

skeleton

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.

Build is green

Looks good to me, thanks !

Build is green

Commit message changes to include "Fixes <ticket>"

Build is green

Review changes and changes to the commit message

this commit has lots of one-line "gpgsig" headers instead of a single "gpgsig" header with a multiline value: https://github.com/git-for-windows/git/commit/5f549aa2f78314ac37bbd436c8f80aea4c752e07

Review changes

Looks good to me.

Build was aborted

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

In D6449#167375, @vlorentz wrote:

Please use the imperative form in diff and commit titles. For example (respectively):

Fix navigation to directory(code) in snapshot view

and

Add an extra parameter called directory_url in the snapshot_context

To fix missing URL to the code (directory) view in case the snapshot is missing an origin context.

Related to T3644

or just this:

Fix missing URL to the code (directory) view in case the snapshot is missing an origin context.

Related to T3644

Two other nitpicks:

1. it's easier for everyone to have the diff title and message match the commit message most of the time
2. Use "Fixes Txxxx" or "Closes Txxxx" instead of "Related to Txxxx" for commits that completely fix an issue, it gives more details on the relation between the commit and the task.

See https://docs.softwareheritage.org/devel/contributing/git-style-guide.html

Build is green

Build is green

Please use the imperative form in diff and commit titles. For example (respectively):

rebase

rebase

Review changes

You could replace conf.py's content with: from swh.docs.sphinx.conf import * # noqa

You could replace conf.py's content with: from swh.docs.sphinx.conf import * # noqa

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.

The last origins are still ongoing. They are taking their time...

solved by T3487#71814

solved by T3487#71814

I added some inline comments to handle.

I'll make sure to do that in the upcoming patches. As @olasd wrote, the merit of this patch is merely to set the stage and make sure the module can be compiled against the cmph library. The code between #if 0 is irrelevant and I can remove it to avoid confusion if you think it is better. Just let me know :-)

In T3627#71819, @vlorentz wrote:

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

In T3641#71966, @anlambert wrote:

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.

Aside from the specific needs of the mirroring stack, the question at hand is whether the read-only object storage should be by default open to the public or not.

What's the difference in deployed dependencies versions (staging vs. prod)?

For ENEA I'd llike to test different scenarios for the source objstorage:

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.

just a quick remark about the scheduling of (sub)tasks of this task: IMHO the autoscaling should come last; all the supervision/monitoring/logging related tasks are much more important than the autoscaling.

Rebase

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,

Sure, we should have authentication / rate limit on this.
But if I'm not wrong, the target is to test the mirroring with ENEA.
If we add authentication, we need to improve the objstorage-replayer / objstorage to support it.

btw ^

Hmm, do we really want this to be open to the world with no authentication whatsoever? (which is what D6448 seems to be doing)