[Tests-only] Reenable upload related tests

[PVince81]

Reverts #3443, the problem should be fixed through cs3org/reva#734 which was updated in ocis-reva through owncloud/ocis-reva#192

[PVince81]

Fixes owncloud/ocis-reva#188

[PVince81]

Seems there are other issues related to upload to look into:

• webUIUpload/uploadEdgecases.feature
• webUIUpload/upload.feature

[PVince81]

I'll try and isolate these and then we can at least unskip the ones that are already passing now

[PVince81]

• likely related to conflict management / overwrite with TUS:

  • tests/acceptance/features/webUIUpload/uploadEdgecases.feature:123 => raised https://github.com/owncloud/ocis-reva/issues/200
  • tests/acceptance/features/webUIUpload/upload.feature:84: works now...

• folder upload issues

  • tests/acceptance/features/webUIUpload/upload.feature:45: solved by fixing folder existence check
  • tests/acceptance/features/webUIUpload/upload.feature:31: solved by fixing folder existence check
  • tests/acceptance/features/webUIUpload/upload.feature:19: raised as TUS folder upload issues #3458

[PVince81]

so apparently I ran all tests on master and forgot to skip the OCIS ones.
anyway, I looked into the above and saw that some can further be enabled and did so.

I've disabled a few more related to overwrite and folder upload.

[PVince81]

Fixes owncloud/ocis-reva#106

[PVince81]

still 11 failures, it's as if my changes didn't matter at all...

and for some reason the test results summary is not appearing, so I have to cherry-pick the results from the log...

1. Scenario: simple upload of a file that does not exist before (attempt 2) # tests/acceptance/features/webUIUpload/upload.feature:12
2. Scenario: simple upload of a folder that does not exist before (attempt 2) # tests/acceptance/features/webUIUpload/upload.feature:31
3. Scenario: Upload of a folder inside a subdirectory (attempt 2) # tests/acceptance/features/webUIUpload/upload.feature:45
4. Scenario: uploading a big file (when chunking is implemented this upload should be chunked) (attempt 2) # tests/acceptance/features/webUIUpload/upload.feature:60
5. Scenario: upload a new file into a sub folder (attempt 2) # tests/acceptance/features/webUIUpload/upload.feature:76
6. Scenario: overwrite an existing file (attempt 1, retried) # tests/acceptance/features/webUIUpload/upload.feature:84
7. Scenario: overwrite an existing file in a sub-folder (attempt 1, retried) # tests/acceptance/features/webUIUpload/upload.feature:125
8. Scenario: upload a new file into a sub folder (attempt 1, retried) # tests/acceptance/features/webUIUpload/uploadEdgecases.feature:46
9. Scenario: upload a new file into a sub folder (attempt 1, retried) # tests/acceptance/features/webUIUpload/uploadEdgecases.feature:47
10. Scenario: Upload a big file called "0" (when chunking in implemented that upload should be chunked) (attempt 1, retried) # tests/acceptance/features/webUIUpload/uploadEdgecases.feature:115
11. Scenario: Upload a file with the same name as already existing folder (attempt 1, retried) # tests/acceptance/features/webUIUpload/uploadEdgecases.feature:139

Sadly, all these tests pass locally for me with ocis master a1da513f74b9ddfe1790f534169edf32b5e4c8b9 Using: chrome (76.0.3809.87) on Linux platform.

Sometimes I see this:

√ Element <#files-file-upload-button> was visible after 28 milliseconds.
Timed out while waiting for element <#files-upload-progress> to be visible for 10000 milliseconds. - expected "visible" but got: "not visible" (10017ms)
undefined√ Element <#files-upload-progress> was not visible after 19 milliseconds.

or

    And the user browses to the files page
Timed out while waiting for element <#files-list-progress> to be present for 10000 milliseconds. - expected "found" but got: "not found" (10012ms)
undefined√ Element <#files-list-progress> was not present after 10 milliseconds.

But when I look at VNC I see that the page is already loaded.
I wonder if ocis is so fast that we don't have time to detect the progress bar at all ??
In any case it seems that waiting for the progress bar is looking for trouble, potential timing issues. I suggest we adjust the test code to not rely on the progress bar but on the final result if possible.

White the tests appear green locally, it seems on CI it's stricter and considers these timeouts as failure.

@dpakach @individual-it can you have a look at that part and adjust the test code for not relying on the progress bar ?

[PVince81]

I made another PR that only reenables the tests that already pass on CI, just to move forward: #3461

[ownclouders]

💥 Acceptance tests webUIOCIS failed. Please find the screenshots inside ...

https://drone.owncloud.com/owncloud/phoenix/9722/

[dpakach]

the upload is just stuck at 0% , the progress bar doesn't disappears. Not sure why this is happening.

[PVince81]

@dpakach strange. in my observation, as far as I remember, the operation already completed successfully without the progress bar appearing at all (maybe very fast). At least in my local tests.

[dpakach]

@PVince81 I run with screenshots in CI just now you can check them in #3457 (comment)
But it's strange indeed.

[ownclouders]

💥 Acceptance tests webUIOCIS failed. Please find the screenshots inside ...

https://drone.owncloud.com/owncloud/phoenix/9748/

[ownclouders]

💥 Acceptance tests webUIOCIS failed. Please find the screenshots inside ...

https://drone.owncloud.com/owncloud/phoenix/9750/

[ownclouders]

💥 Acceptance tests webUIOCIS failed. Please find the screenshots inside ...

https://drone.owncloud.com/owncloud/phoenix/9751/

[PVince81]

we should remove the ".gitignore" commit. I had some weird local files in that folder (maybe from download tests) and falsely believed that the whole folder must be excluded

[PVince81]

I've extracted the folder check commit to #3473.
Hopefully if that passes it will be one less worry.

[dpakach]

@PVince81 I tried this by running drone locally, and get this log in browser

core.bundle.js:83 HEAD http://localhost:9164/data/d6636d01-d64d-498d-80cd-5a65e360acf8 net::ERR_CONNECTION_REFUSED

It tries to connect to localhost for the data even when reva is running in completley different host. This might be the reason for failing tests.

[PVince81]

@dpakach this could be a setup thing, not sure how to adjust it.

Note: this was not relevant before TUS since we didn't need to connect to the storage service directly and is now becoming relevant with the introduction of TUS. So we'll need to adjust the config.

@butonic

[PVince81]

that's the service "reva-storage-oc-data"

need to set REVA_STORAGE_OC_DATA_URL (https://github.com/owncloud/ocis-reva/blob/master/pkg/flagset/storageocdata.go#L116) to specify the correct URL

[PVince81]

I pushed a fix, let's see if this works.

Also, a similar fix for ocis-reva: owncloud/ocis-reva#213

[PVince81]

still failing :-/

1. Scenario: simple upload of a file that does not exist before (attempt 2) # tests/acceptance/features/webUIUpload/upload.feature:13

[PVince81]

wait, I didn't push...

[PVince81]

pushed now (had local conflict and went away for lunch after pushing and missed the error message locally...)

[ownclouders]

💥 Acceptance tests webUIOCIS failed. Please find the screenshots inside ...

https://drone.owncloud.com/owncloud/phoenix/9763/

[PVince81]

indeed the same issue as before...

1) Scenario: simple upload of a file that does not exist before (attempt 1, retried) # tests/acceptance/features/webUIUpload/upload.feature:13

[PVince81]

seems now we have issues again, even with latest reva: https://cloud.drone.io/owncloud/ocis-reva/376/3/11 from owncloud/ocis-reva#221

[PVince81]

raised #3492 to look into this.
it's blocking owncloud/ocis-reva#215