• Added the necessary directory for mongo pytest to work

MongoDB backend implementation for provenancestorage.

• Made default provenance storage to psql

• Pytest is using mongomock

@vsellier I am not sure about this.
The idea is to use this machine as the production server. (I guess this will host either postgres or mongodb after we decide on a preferred backend. But that is going to take some time)
@olasd or @aeviso will know better.

LGTM

Mongo engine
db.serverStatus().storageEngine

"name" : "wiredTiger",
"supportsCommittedReads" : true,
"oldestRequiredTimestampForCrashRecovery" : Timestamp(0, 0),
"supportsPendingDrops" : true,
"dropPendingIdents" : NumberLong(0),
"supportsSnapshotReadConcern" : true,
"readOnly" : false,
"persistent" : true,
"backupCursorOpen" : false,
"supportsResumableIndexBuilds" : true

review changes

added copyright text

template changes, removed tabs

template issues corrected

e18341dd82c1

Looks good to me, thanks ! There is still a typo remaining on an exception name, see inline comment.

Thanks. Fixed e18341dd82c1

Review changes

Requested changes

Couple of remarks inline.

@thanks. Updated the version

Suggested changes by @ardumont

In D5828#149939, @anlambert wrote:

Looks good to me ! You can now merge your feature branch in the master one and push it to remote, phabricator will automatically close the diff afterwards.

Incorporating suggested changes and improved commit message

Synatax corrections

Changed Promise to use async/await.

Updating to changes from origin/master

This will also let us think in terms of reusable widgets. I am not sure how important that would be in our case, but couple of use-cases are

• we can make swh search or the origin browser a public widget, it can be integrated in any external website with just two lines of HTML code.
• Many UI elements are in fact the same kind in SWH (eg: folder/file raw, list view etc). Most this can be re-used inside the system. This will make it efficient and easy to manage.

@zack Thanks for the input. I will start thinking about accessibility as well.
Many pages, including 'swh search', will not function as expected without enabling JS. So, I would say JS is integral.

This will simplify branches view implementation. You should create a diff to handle it.

@anlambert Thank you. I will try to do some refactoring here.

@anlambert The server code seems to have an issue when branches are filtered by name.
"swh.web.common.archive.lookup_snapshot" function is raising an error if the number of searched branches is 0.
raise
This will eventually cause a 404 error when the user search for a non existing branch name in the UI. I don't think this is the intended behavior.

2: If we have to add a UI component, do we have a design or example for that? (maybe a generic one for both branches and Releases, the "search branches" widget in github looks nice)

@anlambert I have a few questions regarding this task.
1: Should we add a filter UI component in the page or just a query param is enough?
2: If we have to add a UI component, do we have a design or example for that? (maybe a generic one for both branches and Releases, the "search branches" widget in github looks nice)
3: What about the API /snapshot/<id>, should we add the possibility of this filter there as well?
4: The branches seem to be randomly sorted over Date. Is that for a reason or something we should address?

In D5686#144406, @ardumont wrote:

first diff, achievement unlocked, w00t ;)