-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update reva to v1.4.1-0.20201118150422-667197a6b674 #823
Update reva to v1.4.1-0.20201118150422-667197a6b674 #823
Conversation
17bac11
to
d097f0f
Compare
CI in master should be improved now. A rebase here might make CI happy. |
d097f0f
to
2e8522a
Compare
so it seems the tests cannot create users:
after starting ocis with
It gives me a 200 OK ... but in the ocis log I see an error related to uploads ...
there was a refactoring in reva regarding uploads: cs3org/reva#1285 ... after creating the user he does not show up in the list of users:
and I can create the user again and again ...
|
@ishank011 @phil-davis cs3org/reva#1285 brakes the file upload for ocis and owncloud storages... I don't know why the reva tests did not pick that up ... I assume because in reva we are not using the ocs api to provision accounts ... this is bad ... 😞 The testsuite does not use TUS to upload files ... do we have tests that cover TUS? One thing that is definitely a problem is that an error in the storage driver is swallowed and we get a 200 error ... |
@butonic Yes, I figured this after reading your comments on using the dataprovider service to store accounts metadata. This PR made the non-TUS upload code work with the logic in InitiateFileUpload, where we assume a UUID in the URL instead of the actual path, so the uploads will fail if a request is sent directly to This is why the reva tests pass, as ocdav handles the InitiateFileUpload part as well. |
@ishank011 AFAICT most of the changes in the ocis drilvers |
f2aa42d
to
be41c00
Compare
the uploed is fixed. next problem I see is:
it happens when fetching the list of shares for a file returns this:
which happens when you create a new user using the ocs provisioning api, upload a file, share it and finally do the above curl request. the ocis logs contain
I remember the fixme messages in the code I'll need to debug into this ... tomorrow ... |
Fixed listing shares for nonexisting path with cs3org/reva#1316 next up: fix nil pointer
|
fix for nil pointer in cs3org/reva#1317 |
e34380c
to
bb7fecc
Compare
hm, running the locally only one test fails
in the localApiTests-ocis-storage logs on drone I found this:
95 times and it is always port 9150, which is the reva share service. I have to assume it died ... but how ... |
@butonic I still see a lot of GET requests to dataprovider for various accounts return a 404. Are the uploads actually succeeding or is this due to some other issue?
|
@ishank011 the 404 be expected, because the testsuite is creating and deleting users for every test step and sometimes double checks that a user exists/was deleted. so I'm not tooo concerned. But will look into that as well. |
dumping the error so it does not get lost:
|
bb7fecc
to
57e29a9
Compare
so
maybe because the tests when using the ocis driver sometimes wipe |
setting |
@@ -23,7 +23,7 @@ Feature: dav-versions | |||
And user "Alice" uploads file "filesForUpload/davtest.txt" to filenames based on "/davtest.txt" with all mechanisms using the WebDAV API | |||
Then the version folder of file "/davtest.txt-olddav-regular" for user "Alice" should contain "1" element | |||
And the version folder of file "/davtest.txt-newdav-regular" for user "Alice" should contain "1" element | |||
And as "Alice" file "/davtest.txt-olddav-oldchunking" should not exist | |||
Then the version folder of file "/davtest.txt-olddav-oldchunking" for user "Alice" should contain "0" element |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://drone.owncloud.com/owncloud/ocis/1451/14/7
It returned 1 element in CI
Then the version folder of file "/davtest.txt-olddav-oldchunking" for user "Alice" should contain "0" element | |
Then the version folder of file "/davtest.txt-olddav-oldchunking" for user "Alice" should contain "1" element |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, but it flips with the other storage. I think I have that solved in my next commit.
I'm more puzzled by:
ℹ Connected to selenium on port 4444 (500ms).
--
992 | tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature:486
993 |
994 | Given the setting "shareapi_auto_accept_share" of app "core" has been set to "no"
995 | And the administrator has set the default folder for received shares to "Shares"
996 | And these users have been created with default attributes:
997 | │ username │
998 | │ user1 │
999 | │ user2 │
1000 | Given user "user1" has shared folder "simple-folder" with user "user2"
1001 | And user "user2" has accepted the share "simple-folder" offered by user "user1"
1002 | When user "user2" has logged in using the webUI
1003 | √ Element <input[autocomplete="kopano-account username"]> was visible after 597 milliseconds.
1004 | √ Element <#oc-app-container> was visible after 2605 milliseconds.
1005 | √ Element <//button[@id="new-file-menu-btn" and contains(@class, "oc-button-primary") and not(@disabled)]> was present after 1932 milliseconds.
1006 | √ Element <//div[contains(@class, "oc-file") and @data-preview-loaded="false"]> was not present after 1506 milliseconds.
1007 | And the user opens folder "Shares" using the webUI
1008 | √ Element <#files-list-container> was present after 26 milliseconds.
1009 | √ Element <.vue-recycle-scroller> was visible after 46 milliseconds.
1010 | √ Element <.vue-recycle-scroller> was visible after 28 milliseconds.
1011 | √ Element <//span[contains(@class, "oc-file-name") and text()='Shares' and not(../span[contains(@class, "oc-file-extension")])]/ancestor::div[@data-is-visible="true"]//div[contains(@class, "oc-file") and (@data-preview-loaded="true" or @data-preview-loaded="disabled")]> was visible after 46 milliseconds.
1012 | √ Element <#files-list-progress> was not present after 3124 milliseconds.
1013 | √ Element <//div[contains(@class, "oc-file") and @data-preview-loaded="false"]> was not present after 19 milliseconds.
1014 | And the user opens the sharing sidebar for folder "simple-folder"
1015 | √ Element <#files-list-container> was present after 15 milliseconds.
1016 | √ Element <.vue-recycle-scroller> was visible after 41 milliseconds.
1017 | √ Element <.vue-recycle-scroller> was visible after 36 milliseconds.
1018 | √ Element <//span[contains(@class, "oc-file-name") and text()='simple-folder' and not(../span[contains(@class, "oc-file-extension")])]/ancestor::div[@data-is-visible="true"]//div[contains(@class, "oc-file") and (@data-preview-loaded="true" or @data-preview-loaded="disabled")]> was visible after 49 milliseconds.
1019 | (node:391) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 queue:finished listeners added. Use emitter.setMaxListeners() to increase limit
1020 | Then the following resources should have share indicators on the webUI
1021 | │ fileName │ expectedIndicators │
1022 | │ simple-folder │ user-indirect │
1023 | √ Element <#files-list-container> was present after 17 milliseconds.
1024 | √ Element <.vue-recycle-scroller> was visible after 38 milliseconds.
1025 | √ Element <.vue-recycle-scroller> was visible after 36 milliseconds.
1026 | √ Element <//span[contains(@class, "oc-file-name") and text()='simple-folder' and not(../span[contains(@class, "oc-file-extension")])]/ancestor::div[@data-is-visible="true"]//div[contains(@class, "oc-file") and (@data-preview-loaded="true" or @data-preview-loaded="disabled")]> was visible after 46 milliseconds.
1027 | ✖ failed
1028 | AssertionError [ERR_ASSERTION]: Expected share indicators to be the same for "simple-folder": expected [user-indirect] got []
1029 | + expected - actual
1030 |
1031 | -false
1032 | +true
1033 |
1034 | at _callee58$ (/srv/app/phoenix/tests/acceptance/stepDefinitions/filesContext.js:1081:12)
1035 | at tryCatch (/srv/app/phoenix/node_modules/regenerator-runtime/runtime.js:63:40)
1036 | at Generator.invoke [as _invoke] (/srv/app/phoenix/node_modules/regenerator-runtime/runtime.js:293:22)
1037 | at Generator.next (/srv/app/phoenix/node_modules/regenerator-runtime/runtime.js:118:21)
1038 | at asyncGeneratorStep (/srv/app/phoenix/node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:24)
1039 | at _next (/srv/app/phoenix/node_modules/@babel/runtime/helpers/asyncToGenerator.js:25:9)
1040 | at processTicksAndRejections (internal/process/task_queues.js:86:5)
1041 | When the user opens folder "simple-folder" using the webUI
1042 | - skipped
1043 | Then the following resources should have share indicators on the webUI
1044 | │ fileName │ expectedIndicators │
1045 | │ simple-empty-folder │ user-indirect │
1046 | │ lorem.txt │ user-indirect │
1047 | - skipped
1048 | deleted Share
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kulmann @LukasHirt what about the share indicators ... I know they don't work on ocis, yet ... I can try to fix that, but I'd rather get this PR in ... now ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently broken in phoenix master, according to: owncloud/web#4310
Skip it if possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently the Phoenix UI tests are only run with owncloud
storage. So I don't understand? How did it break in CI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, share indicators in the file list rely on the <oc:share-types>
property, which is not implemented in ocis, yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kulmann wasn't the Phoenix pr supposed to allow this? Ugh I need to really click through this...
0be729c
to
df6011e
Compare
https://drone.owncloud.com/owncloud/ocis/1497/42/7 phoenixWebUI5
That was the only failing pipeline. I restarted drone - let's see if the same scenarios fail again. |
https://drone.owncloud.com/owncloud/ocis/1500/42/7 |
df6011e
to
f2e7ade
Compare
@phil-davis yes I excpect them to be fixed with the rebase on top of #868 |
87b8f8d
to
1fc893f
Compare
@@ -0,0 +1,17 @@ | |||
Enhancement: Update reva to v1.4.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Enhancement: Update reva to v1.4.0 | |
Enhancement: Update reva to v1.4.1 |
And now it is 1.4.1 !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment below by @kulmann
This can be updated when we finally get to a "version" for what will pass here.
1fc893f
to
ce61c57
Compare
Would be nice to get this in as well: cs3org/reva#1326 |
By the way, we're not updating to reva 1.4.1 here, but to "some commit after the 1.4.0 tag". Go expresses that by increasing the patch version and appending the commit id. |
f992412
to
bfe9d4f
Compare
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
837fc94
to
1621a0d
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs |
Update reva to v1.4.1-0.20201123062044-b2c4af4e897d