Skip to content
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

[full-ci] [tests-only] Update expected failures after core #38876 #2211

Merged
merged 1 commit into from
Jun 29, 2021

Conversation

kiranparajuli589
Copy link
Contributor

@kiranparajuli589 kiranparajuli589 commented Jun 24, 2021

Description

This PR update scenarios in the expected failures file with correct issue tags.

@update-docs
Copy link

update-docs bot commented Jun 24, 2021

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

@kiranparajuli589 kiranparajuli589 force-pushed the update-expected-failures-after-#38876 branch from 908a8c9 to 897b65f Compare June 24, 2021 06:19
@kiranparajuli589 kiranparajuli589 changed the title Update expected failures after core #38876 [full-ci] [tests-only] Update expected failures after core #38876 Jun 24, 2021
@phil-davis
Copy link
Contributor

@kiranparajuli589 owncloud/core#38876 has been merged. You can make an ordinary PR to update the core commit id.

@kiranparajuli589 kiranparajuli589 force-pushed the update-expected-failures-after-#38876 branch from 90f1e4c to 199488a Compare June 25, 2021 03:30
@kiranparajuli589 kiranparajuli589 force-pushed the update-expected-failures-after-#38876 branch 2 times, most recently from fe08d50 to b2e0678 Compare June 28, 2021 04:06
@kiranparajuli589 kiranparajuli589 marked this pull request as ready for review June 28, 2021 04:09
@kiranparajuli589 kiranparajuli589 self-assigned this Jun 28, 2021
@phil-davis phil-davis self-requested a review June 28, 2021 05:07
@kiranparajuli589 kiranparajuli589 force-pushed the update-expected-failures-after-#38876 branch 2 times, most recently from 8266221 to efc04c0 Compare June 28, 2021 06:49
@phil-davis
Copy link
Contributor

https://drone.owncloud.com/owncloud/ocis/5650/37/7

runsh: There were no unexpected failures.
runsh: Total unexpected passed scenarios throughout the test run:
apiTrashbin/trashbinRestore.feature:110
apiTrashbin/trashbinRestore.feature:111

@kiranparajuli589 kiranparajuli589 force-pushed the update-expected-failures-after-#38876 branch from efc04c0 to 784d98f Compare June 28, 2021 07:29
@phil-davis
Copy link
Contributor

phil-davis commented Jun 28, 2021

https://drone.owncloud.com/owncloud/ocis/5654/37/7

runsh: Total unexpected failed scenarios throughout the test run:
apiTrashbin/trashbinRestore.feature:110
apiTrashbin/trashbinRestore.feature:111
runsh: Total unexpected passed scenarios throughout the test run:
apiTrashbin/trashbinRestore.feature:108

  @skipOnOcV10 @issue-35974
  Scenario Outline: restoring a file to an already existing path overrides the file                              # /srv/app/testrunner/tests/acceptance/features/apiTrashbin/trashbinRestore.feature:96
    Given user "Alice" has uploaded file with content "file to delete" to "/.hiddenfile0.txt"                    # FeatureContext::userHasUploadedAFileWithContentTo()
    And using <dav-path> DAV path                                                                                # FeatureContext::usingOldOrNewDavPath()
    And user "Alice" has created folder "/PARENT"                                                                # FeatureContext::userHasCreatedFolder()
    And user "Alice" has uploaded file with content "PARENT file content" to <upload-path>                       # FeatureContext::userHasUploadedAFileWithContentTo()
    And user "Alice" has deleted file <delete-path>                                                              # FeatureContext::userHasDeletedFile()
    When user "Alice" restores the file with original path <delete-path> to <upload-path> using the trashbin API # TrashbinContext::userRestoresTheFileWithOriginalPathToUsingTheTrashbinApi()
    Then the HTTP status code should be "204"                                                                    # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And as "Alice" file <upload-path> should exist                                                               # FeatureContext::asFileOrFolderShouldExist()
    And the content of file <upload-path> for user "Alice" should be "file to delete"                            # FeatureContext::contentOfFileForUserShouldBe()

    Examples:
      | dav-path | upload-path                | delete-path        |
      | old      | "/PARENT/textfile0.txt"    | "/textfile0.txt"   |
      | new      | "/PARENT/textfile0.txt"    | "/textfile0.txt"   |
        The downloaded content was expected to be 'file to delete', but actually is 'PARENT file content'. HTTP status was 200
        Failed asserting that two strings are equal.
        --- Expected
        +++ Actual
        @@ @@
        -'file to delete'
        +'PARENT file content'
      | old      | "/PARENT/.hiddenfile0.txt" | ".hiddenfile0.txt" |
        The downloaded content was expected to be 'file to delete', but actually is 'PARENT file content'. HTTP status was 200
        Failed asserting that two strings are equal.
        --- Expected
        +++ Actual
        @@ @@
        -'file to delete'
        +'PARENT file content'
      | new      | "/PARENT/.hiddenfile0.txt" | ".hiddenfile0.txt" |
        The downloaded content was expected to be 'file to delete', but actually is 'PARENT file content'. HTTP status was 200
        Failed asserting that two strings are equal.
        --- Expected
        +++ Actual
        @@ @@
        -'file to delete'
        +'PARENT file content'

That scenario is intermittent. Sometimes the file is correctly restored, overwriting the existing file in /PARENT. But sometimes the content is not updated. But always the correct 204 response is given.

This is the same behavior as in core issue owncloud/core#35974

That is very strange that this intermittent behavior happens in oC10 core (implemented with PHP and database), and also in OCIS with "owncloud" storage (implemented with Go and file-system-based storage of attributes etc)

However, the test scenarios pass in OCIS with "OCIS" storage. https://drone.owncloud.com/owncloud/ocis/5654/38/6

The bug has been implemented "the same" in OCIS with "owncloud" storage. How can this be?

@phil-davis
Copy link
Contributor

In cs3org/reva PR cs3org/reva#1795 these scenarios failed consistently on "owncloud" storage.
https://drone.cernbox.cern.ch/cs3org/reva/1881/17/7

What is going on?

@C0rby you might be familiar with this. Any ideas?

@C0rby
Copy link
Contributor

C0rby commented Jun 28, 2021

Ah, damn... this is bad...
I don't know why this is happening but I'll take a look into the owncloud storage driver.

@C0rby
Copy link
Contributor

C0rby commented Jun 28, 2021

@phil-davis, I think I found the issue and opened a PR here: cs3org/reva#1833.

@phil-davis
Copy link
Contributor

cs3org/reva#1833 looks good - fixes the problem. Let's see how quickly that can be merged and then find its way into owncloud/ocis - then we will not need to mess about with how to skip the scenario.

And replace closed issues with current issues
@phil-davis phil-davis force-pushed the update-expected-failures-after-#38876 branch from 784d98f to f36cf67 Compare June 29, 2021 03:07
@phil-davis
Copy link
Contributor

I adjusted the core commit id to the latest, and put back the trashbinRestore expected-failures. We do sometimes (most of the time) have those trashbinRestore scenarios fail. So we might get a "pass" in CI. (Other PRs are often getting a pass!)

It would be good to get this merged. It does not make any difference to the issue of cs3org/reva#1833 - that can be fixed in OCIS independently.

@phil-davis
Copy link
Contributor

There were a lot of fails in the last CI run, all with owncloud storage:
https://drone.owncloud.com/owncloud/ocis/5663/25/7
Core-API-Tests-owncloud-storage-2
runsh: Total unexpected failed scenarios throughout the test run:
apiMain/checksums.feature:119
apiMain/checksums.feature:132

https://drone.owncloud.com/owncloud/ocis/5663/31/7
Core-API-Tests-owncloud-storage-5
runsh: Total unexpected failed scenarios throughout the test run:
apiShareOperationsToShares1/accessToShare.feature:24
apiShareOperationsToShares1/accessToShare.feature:25
apiShareOperationsToShares1/accessToShare.feature:41
apiShareOperationsToShares1/accessToShare.feature:42
apiShareOperationsToShares1/accessToShare.feature:58
apiShareOperationsToShares1/accessToShare.feature:59
apiShareOperationsToShares1/accessToShare.feature:74
apiShareOperationsToShares1/accessToShare.feature:75
apiShareOperationsToShares1/gettingShares.feature:39
apiShareOperationsToShares1/gettingShares.feature:40
apiShareOperationsToShares1/gettingShares.feature:62
apiShareOperationsToShares1/gettingShares.feature:63
apiShareOperationsToShares1/gettingShares.feature:85
apiShareOperationsToShares1/gettingShares.feature:86
apiShareOperationsToShares1/gettingShares.feature:106
apiShareOperationsToShares1/gettingShares.feature:107
apiShareOperationsToShares1/gettingShares.feature:188

https://drone.owncloud.com/owncloud/ocis/5663/33/7
Core-API-Tests-owncloud-storage-6
runsh: Total unexpected failed scenarios throughout the test run:
apiShareReshareToShares1/reShare.feature:61
apiShareReshareToShares1/reShare.feature:62
apiShareReshareToShares1/reShare.feature:78
apiShareReshareToShares1/reShare.feature:79
apiShareReshareToShares1/reShare.feature:95
apiShareReshareToShares1/reShare.feature:96
apiShareReshareToShares1/reShare.feature:112
apiShareReshareToShares1/reShare.feature:113

https://drone.owncloud.com/owncloud/ocis/5663/35/7
Core-API-Tests-owncloud-storage-7
runsh: Total unexpected failed scenarios throughout the test run:
apiShareUpdateToShares/updateShare.feature:29
apiShareUpdateToShares/updateShare.feature:30
apiShareUpdateToShares/updateShare.feature:77
apiShareUpdateToShares/updateShare.feature:78
apiShareUpdateToShares/updateShare.feature:256
apiShareUpdateToShares/updateShare.feature:257
apiShareUpdateToShares/updateShare.feature:394
apiShareUpdateToShares/updateShare.feature:395
apiShareUpdateToShares/updateShareGroupAndUserWithSameName.feature:34
apiShareUpdateToShares/updateShareGroupAndUserWithSameName.feature:35
apiShareUpdateToShares/updateShareGroupAndUserWithSameName.feature:54

I restarted - I am not sure what happened!

@sonarcloud
Copy link

sonarcloud bot commented Jun 29, 2021

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

@phil-davis phil-davis merged commit 0f2cb27 into master Jun 29, 2021
@phil-davis phil-davis deleted the update-expected-failures-after-#38876 branch June 29, 2021 05:03
ownclouders pushed a commit that referenced this pull request Jun 29, 2021
Merge: 95a9405 f36cf67
Author: Phil Davis <phil@jankaritech.com>
Date:   Tue Jun 29 10:48:22 2021 +0545

    Merge pull request #2211 from owncloud/update-expected-failures-after-#38876

    [full-ci] [tests-only] Update expected failures after core #38876
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants