Update reva to v1.4.1-0.20201118150422-667197a6b674 #823
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
butonic
force-pushed
the
update-reva-to-v1.3.1-0.20201109104617-f47d01b73dec
branch
2 times, most recently
from
17bac11
to
d097f0f
Compare
|
CI in master should be improved now. A rebase here might make CI happy. |
butonic
force-pushed
the
update-reva-to-v1.3.1-0.20201109104617-f47d01b73dec
branch
from
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 |
butonic
force-pushed
the
update-reva-to-v1.3.1-0.20201109104617-f47d01b73dec
branch
from
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 |
butonic
force-pushed
the
update-reva-to-v1.3.1-0.20201109104617-f47d01b73dec
branch
5 times, most recently
from
e34380c
to
bb7fecc
Compare
butonic
changed the title
|
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: |
butonic
force-pushed
the
update-reva-to-v1.3.1-0.20201109104617-f47d01b73dec
branch
from
bb7fecc
to
57e29a9
Compare
|
so maybe because the tests when using the ocis driver sometimes wipe |
|
setting |
phil-davis
reviewed
Nov 13, 2020
| @@ -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.
https://drone.owncloud.com/owncloud/ocis/1451/14/7
It returned 1 element in CI
Suggested change
| 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.
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.
@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.
Currently broken in phoenix master, according to: owncloud/web#4310
Skip it if possible.
There was a problem hiding this comment.
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.
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.
@kulmann wasn't the Phoenix pr supposed to allow this? Ugh I need to really click through this...
butonic
force-pushed
the
update-reva-to-v1.3.1-0.20201109104617-f47d01b73dec
branch
from
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 |
butonic
force-pushed
the
update-reva-to-v1.3.1-0.20201109104617-f47d01b73dec
branch
from
df6011e
to
f2e7ade
Compare
|
@phil-davis yes I excpect them to be fixed with the rebase on top of #868 |
butonic
force-pushed
the
update-reva-to-v1.3.1-0.20201109104617-f47d01b73dec
branch
from
87b8f8d
to
1fc893f
Compare
butonic
changed the title
phil-davis
reviewed
Nov 18, 2020
| @@ -0,0 +1,17 @@ | |||
| Enhancement: Update reva to v1.4.0 | |||
There was a problem hiding this comment.
Suggested change
| 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.
See comment below by @kulmann
This can be updated when we finally get to a "version" for what will pass here.
butonic
force-pushed
the
update-reva-to-v1.3.1-0.20201109104617-f47d01b73dec
branch
from
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. |
kulmann
force-pushed
the
update-reva-to-v1.3.1-0.20201109104617-f47d01b73dec
branch
from
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>
kulmann
force-pushed
the
update-reva-to-v1.3.1-0.20201109104617-f47d01b73dec
branch
from
837fc94
to
1621a0d
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
kulmann
approved these changes
Nov 23, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update reva to v1.4.1-0.20201123062044-b2c4af4e897d