In D2133#50040, @ardumont wrote:

(And maybe add support for https_<domain_name> for symmetry)

I'm for symmetry but I'm a bit worried about the amount of work on my pile of diffs that this implies...
(for the https part, for http only debian code is impacted so fine)
I'd rather change that after merging the package-loader branch if you don't mind.

I'm a bit worried that this pulls http and https from the same set of files without distinction; This looks like a good catalyst for subtle single-character bugs.

In D2078#48207, @zack wrote:

Looks good, but I'm puzzled by some testing results.
The logic of extracting the branches for snapshot computation has trickled down to swh identify. (BTW, if you're up for some refactoring, this diff might be a chance to avoid the duplication, but it's certainly not a blocker here.)
So I've tried to just reuse your change in swh.model.cli too, here's the minimal diff: D2078.
Then I've dumped the branch list just before it's hashed (with P542 in swh.model.identifiers) and what I get is this:

alias HEAD 726566732f68656164732f6d6173746572
revision refs/heads/master 9768d0b576dbaaecd80abedad6dfd0d72f1476da
revision refs/remotes/origin/master c3c588713233609f5bbbb2d9e7f3fb4a660f3f72

where HEAD is an alias, but it's pointing to an object ID (this is on the sample git repo used for tests on swh-load-git, but I obtain similar results on any other repo I've tried).
What am I missing here?

In D2082#48297, @olasd wrote:

Finally, you should make sure that the rationale for adding a new toplevel module for the pytest plugin is really clear (the paste or the reference to pytest/2042 really aren't).
From my tests and reading documentation further (pytest, tox), the issue really is a limitation of the way we're using the tox + pytest combination: we're running the tests on the checked out version of the module, instead of the version that's installed by tox (which is what pytest expects). If we adapt tox.ini to run tests on the installed version of the module (by running pytest [...] {envsitepackagesdir}/swh/core/..., then we can ship the pytest plugin wherever we want without triggering the dreaded ImportMismatchError.

While I understand what the fixture does, its documentation is lacking (you're only really documenting the inner callback, that users won't call into, not the fixture itself). I guess most of the documentation of the callback should move to the fixture itself?

Pluggable compression has been implemented for all objstorage backends, which means we could

• store the (compressed) bundles in an uncompressed objstorage on azure
• when a user requests the bundle
  • generate a temporary URL (using BlobSharedAccessSignature.generate_blob)
  • redirect to that temporary URL

The aforementioned cards have been received, installed and zfs has been setup to use them.

There was a bug in the (manually modified) Let's Encrypt config for this domain, which was silently ignored by certbot (nice), and prevented the renewal to trickle down to puppet.

♪┏(・o･)┛♪┗ ( ･o･) ┓♪ do the rebase dance party

In D2056#47656, @zack wrote:

In D2056#47634, @olasd wrote:

Would it be possible to make that extra dependency on dulwich optional, e.g. only installed when requesting swh.model[identify]?

Good one. How about swh.model[cli] instead though?

Mark race condition test as xfail

Sounds like a good first fix, thanks.

Would it be possible to make that extra dependency on dulwich optional, e.g. only installed when requesting swh.model[identify]?

I've rebased the jdk11 image on top of buster using the awful, awful a3776d744f. This means python 3.7 by default, and it looks like swh.graph CI works.

Switch conditions to get a ==