[tests-only] [full-ci] Bump OCIS_COMMITID

[phil-davis]

owncloud/QA#738

checks that the latest things merged to oCIS work OK with the current web code.

[phil-davis]

https://drone.owncloud.com/owncloud/web/25319/57/15

runsh: Total unexpected passed scenarios throughout the test run:
webUIFilesSearch/search.feature:50
webUIFilesSearch/search.feature:129
runsh: Exit code: 1

more scenarios passed! I will remove them from expected-failures.

[saw-jan]

@phil-davis I think bumping will also fix this issue: #6877
if so, could you add fixes for that issue?

[ownclouders]

Results for oCISSharingAndUpload https://drone.owncloud.com/owncloud/web/25320/67/1

💥 The acceptance tests failed on retry. Please find the screenshots inside ...

webUIUpload-upload_feature-L94.png

[phil-davis]

https://drone.owncloud.com/owncloud/web/25320/67/15

Checking expected failures in /var/www/owncloud/web/tests/acceptance/expected-failures-with-ocis-server-ocis-storage.md
Error: Scenario webUIUpload/upload.feature:94 failed but was not expected to fail.
runsh: Total unexpected failed scenarios throughout the test run:
webUIUpload/upload.feature:94
runsh: There were no unexpected success.
runsh: Exit code: 1

The acceptance tests step failed, but the pipeline passed. That is disturbing - there seems to be a problem processing the results. Maybe related to the GitHub comment #6876 (comment) about "failed on retry", and that full-ci is running, or some other combination of conditions. (see discussion in #6880 - I was confused)

upload.feature:94 did fail twice - both times with:

   And as "Alice" the content of "big-video.mp4" in the server should be the same as the content of local file "big-video.mp4"
    ✖ failed
      Error: AssertionError [ERR_ASSERTION]: asserting content of local file "/uploads/big-video.mp4"
          at assertContentOfLocalFileIs (/usr/src/app/src/stepDefinitions/filesContext.js:150:17)
          at StepDef.action (/usr/src/app/src/stepDefinitions/filesContext.js:132:5)
          at processTicksAndRejections (node:internal/process/task_queues:96:5)
          at async /usr/src/app/src/app.js:61:7
          at /var/www/owncloud/web/tests/acceptance/stepDefinitions/middlewareContext.js:38:15
          at runMicrotasks (<anonymous>)
          at processTicksAndRejections (internal/process/task_queues.js:95:5)

@saw-jan is that a known flaky test? Or?

[kulmann]

https://drone.owncloud.com/owncloud/web/25320/67/15

Checking expected failures in /var/www/owncloud/web/tests/acceptance/expected-failures-with-ocis-server-ocis-storage.md

Error: Scenario webUIUpload/upload.feature:94 failed but was not expected to fail.

runsh: Total unexpected failed scenarios throughout the test run:

webUIUpload/upload.feature:94

runsh: There were no unexpected success.

runsh: Exit code: 1

The acceptance tests step failed, but the pipeline passed.

upload.feature:94 did fail twice - both times with:

   And as "Alice" the content of "big-video.mp4" in the server should be the same as the content of local file "big-video.mp4"

    ✖ failed

      Error: AssertionError [ERR_ASSERTION]: asserting content of local file "/uploads/big-video.mp4"

          at assertContentOfLocalFileIs (/usr/src/app/src/stepDefinitions/filesContext.js:150:17)

          at StepDef.action (/usr/src/app/src/stepDefinitions/filesContext.js:132:5)

          at processTicksAndRejections (node:internal/process/task_queues:96:5)

          at async /usr/src/app/src/app.js:61:7

          at /var/www/owncloud/web/tests/acceptance/stepDefinitions/middlewareContext.js:38:15

          at runMicrotasks (<anonymous>)

          at processTicksAndRejections (internal/process/task_queues.js:95:5)

@saw-jan is that a known flaky test? Or?

It is definitely flaky, saw it failing yesterday as well and then succeeding again. I can't tell about the frequency - it's noticable but not like every second run.

[phil-davis]

I restarted drone to get another result, and will think about what might be happening with the false pass of the pipeline.

[saw-jan]

@saw-jan is that a known flaky test? Or?

Yeah, seen from yesterday. I think we have an issue for that test. I will re-open the issue if that is the case.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[phil-davis]

https://drone.owncloud.com/owncloud/web/25323/67/15

  Scenario: conflict with a big file (when chunking is implemented this upload should be chunked) # features/webUIUpload/upload.feature:94
- Connecting to selenium on port 4444...

ℹ Connected to selenium on port 4444 (321ms).
  Using: chrome (94.0.4606.61) on Linux platform.

    Given user "Alice" has been created with default attributes and without skeleton files in the server
    And user "Alice" has created folder "simple-folder" in the server
    And user "Alice" has uploaded file with content "initial content" to "lorem.txt" in the server
    And user "Alice" has uploaded file with content "initial content" to "simple-folder/lorem.txt" in the server
    And user "Alice" has logged in using the webUI
√ Element <input[autocomplete="kopano-account username"]> was visible after 1054 milliseconds.
√ Element <input[autocomplete="kopano-account username"]> was not present after 227 milliseconds.
√ Element <#files-view> was visible after 967 milliseconds.
    Given a file with the size of "30000000" bytes and the name "big-video.mp4" has been created locally in the middleware
    When the user renames file "lorem.txt" to "big-video.mp4" using the webUI
√ Element <//span[contains(@class, "oc-resource-name") and (@data-test-resource-name='lorem.txt' or @data-test-resource-path='/lorem.txt')]/ancestor::tr[contains(@class, "oc-tbody-tr")]> was visible after 34 milliseconds.
waiting for 500ms ...
Timeout waiting for Ajax calls to start
waiting for 500ms ...
√ Element <//*[@id="sidebar-panel-actions-item"]//*[contains(@class, "sidebar-panel__body-content")]> was present after 15 milliseconds.
√ Element <.oc-modal> was visible after 35 milliseconds.
waiting for 500ms ...
√ Element <.oc-modal> was not present after 205 milliseconds.
    And the user reloads the current page of the webUI
    And the user uploads a created file "big-video.mp4" with overwrite using the webUI
    Then file "big-video.mp4" should be listed on the webUI
√ Element <#upload-menu-btn:not([disabled])> was visible after 697 milliseconds.
√ Element <#files-file-upload-button> was visible after 59 milliseconds.
waiting for 500ms ...
√ Element <.oc-modal-body-actions-confirm:enabled> was visible after 31 milliseconds.
√ Element <.oc-modal> was not present after 25 milliseconds.
√ Element <//span[contains(@class, "oc-resource-name") and (@data-test-resource-name='big-video.mp4' or @data-test-resource-path='/big-video.mp4') and @data-test-resource-type='file']/ancestor::tr[contains(@class, "oc-tbody-tr")]> was visible after 39 milliseconds.
    And as "Alice" the content of "big-video.mp4" in the server should be the same as the content of local file "big-video.mp4"

webUIUpload/upload.feature:94 passed the first time - good.