Dec 11 2019
Resolved by D2424.
Dec 9 2019
Nov 26 2019
Closed by 9a98e8be06817055693671cfbe6917645171993e
Nov 20 2019
And it's fixed.
Ok, the stacktrace and the current indexer code (master) seems out of sync.
rDCIDXb2ff26454b37f3d332b90ff6a70a45b43dea6526 fixing that part of the journal client.
I failed to find the swh-docker-compose.logs file.
I finally found the reference of the node the build ran on though (because i keep forgetting that) 
Nov 19 2019
Nov 18 2019
Nov 12 2019
Indeed, the Dockerfile fix is much simpler. Let's hope they will fix the issue upstream (not sure regarding this comment).
We've migrated away from doing that ages ago in favor of app factories, and I'd very much prefer we avoid introducing this again: Side effects such as reading configuration files unconditionally running in importable modules are very bad form.
Seems the simplest solution is to instantiate the wsgi application in swh.*.api.server modules.
Ah, I guess that's the opposite then.
Works fine for me? Are you sure your docker image is up to date?
I was also looking at it.
Sep 6 2019
Sep 5 2019
Hm, i don't know how to close this issue, but it should be closed now.
Thx to this change (provided by @olasd) in the swh-docker-dev repository, tasks are exectued:
diff --git a/conf/loader.yml b/conf/loader.yml index 4a4fb54..0cc07e6 100644 --- a/conf/loader.yml +++ b/conf/loader.yml @@ -5,6 +5,7 @@ storage: celery: task_broker: amqp://guest:guest@amqp// task_modules: + - swh.loader.package.tasks - swh.loader.debian.tasks - swh.loader.dir.tasks - swh.loader.git.tasks @@ -16,6 +17,7 @@ celery: - swh.deposit.loader.tasks
Jul 28 2019
May 22 2019
May 10 2019
Apr 13 2019
Apr 2 2019
Mar 25 2019
Let's call it done, event if the small dataset part has not been addressed.
Let's call it done, some minor parts may still need a bit of attention thou