Listed (oneshot full + recurring incremental) and loaded (as far as I can tell).

(just updated my swh-env, now I see where this diff comes from :-) )

sure

LGTM (except the "rm -f ../$module.log " for which I am not convinced it's a good idea)

I've sent an email to the fsfe.

Can this be closed now? What's missing? Adding a listing task?

and with the pytest.ini hunk we don't need a (non working) dependency on swh.core[testing]

add a precision in the ci message for the pytest.ini hunk

In D4045#100032, @ardumont wrote:

ah yeah, it'd be best to align indeed.

crumbs everywhere

sure

Also https://plan.io/blog/technical-documentation/

In D4012#99525, @olasd wrote:

I don't think the origin url and visit type should be sent in the task result; they're arguments of the task already.

If we want them logged by the worker when the task ends (which I agree would be useful), then we should improve logging on the worker/celery side to show some of the task arguments (for instance, if there's a "url" argument) instead / in addition of the task id.

This is probably mostly deprecated now we have mypy & al. Also the reporting via warnings-ng-plugin may not be such a priority now.

I'd like to close this task, but unfortunately:

I guess we can say that, let's close this.

I guess this can be closed now

thx a lot

sure go

update ci message

In D4029#99626, @vlorentz wrote:

commit message! ;)

fix a couple of sedisms

rebase

LGTM, just a couple of wishes (and we are not even close to xmas!)

it's unclear to me if the hunk in swh_storage_backend_config is related with the fix or not.
isn't the very last diff hunk enough for the job?

rebase

fix docstring (thx ardumont)

several fixes and add a --template option to 'swh db create'

better ci mesg

In D3997#98782, @douardda wrote:

In D3997#98758, @douardda wrote:

I don't understand how this is supposed to work.

How does the flavor "name" is taken in consideration? Is it supposed to select "flavored" versions of sql files? What's the pattern ? As written, I don't understand how the flavor "name" is used besides being written the dbflavor table.

Oh now I get it (after reading D3981)

It's the presence of a xxx-flavor.sql that triggers the insertion/update of the flavor given as cli argument in the dbflavor table, which then specify how the other sql files are executed (thx to /if statements in there).

In D3997#98758, @douardda wrote:

I don't understand how this is supposed to work.

How does the flavor "name" is taken in consideration? Is it supposed to select "flavored" versions of sql files? What's the pattern ? As written, I don't understand how the flavor "name" is used besides being written the dbflavor table.