@douardda As discussed orally, i was unsure at the time.

@nahimilega I did not review the diff completely, i let the initial reviewers finalize it.

Summarizing the last exchange to:

|-----------------------------------+----------------+-------------------+----------------------------------|
| metadata provided (codeMeta term) | Fallback value | SWH release field | Description                      |
|-----------------------------------+----------------+-------------------+----------------------------------|
| X                                 | X              | target            | revision containing all metadata |
| X                                 | X              | target_type       | hard-coded: 'revision'           |
| softwareVersion                   | X              | name              | Release name if any              |
| releaseNote                       | X              | message           | Release message if any           |
| datePublished (if any)            | `deposit_date` | date              | Publication date                 |
|-----------------------------------+----------------+-------------------+----------------------------------|

Don't know why the build now.

Thanks for the fix!

they are never read. origin-id is not even set by listers, and description is only set by half of them, so even if we had a use case for it, we would have to repopulate the table before using it.
And description belongs in the extrinsic metadata workflow anyway.

Related D1606

Sounds good.

Sounds good to me.

Can you please try and fix the build?

Can you land and tag the loader-core's changes to ensure this build is fine?

sound good to me

I just realized the dependency on D1603 for that.
That must be the real reason of the build failure (same goes for the other diff with the extra v in its requirements-swh.txt's version declared on the loader-core).

Sounds good (also clearer).

For the build failure which i think i saw the reason, check the extra 'v' in the requirements-swh.txt.

Build is not ok.

That's even clearer than before!
Thanks.

I have a question though in there but that's not blocking.

ah, now i grok better the previous diff \m/
Thanks.

Ho, i just saw a previous diff, i'll amend the description then and repass on it.

For the sake of missing configuration field (looked multiple times differently and nowhere to be found on my side).

For the sake of discussion ;)

They are useless.

Almost there (again).
But this time, i'm right (hopefully ;)

I did not see it earlier, in your command sample, please insert a space between $ and the start of the command.
I think it's way clearer to read.
Also it eases copy/paste from a user perspective (one cannot always see clearly the limit between the prompt and the start of the cli she wants to execute).

Sounds good.

Heads up, a priori, there is a bootstrap step missing.
@olasd told me it's possible we need to start an incremental one first (thanks).

Ok, so without further ado, removing the incremental phabricator lister.
It does not really exist.

From swh-lister db, all "main" instances listed:

Might be a flaky thing somewhere in our stack.
Rescheduling that task and it worked.

docker-run tryout for that same forge was fine.

Related T1801

Well, yeah, the real forge is https://developer.blender.org!

Which I changed here in this diff.

Migration done.

A middle-ground would be to change swh-model to install pyblake2 on all systems with a Python < 3.6, by using this in the dependency declaration: extras_require={':python_version<"3.6"':: ['pyblake2']}

If we apply this logic, it's not only on directory that this is missing...