owncloud
Nightly: webUI test failing [acceptance]
Build: https://drone.owncloud.com/owncloud/encryption/3462/16/15
Failed Scenario:
- tests/acceptance/features/webUIMasterKeyType/webUIMasterKeys.feature:8
- tests/acceptance/features/webUIMasterKeyType/webUIMasterKeys.feature:21
Scenario: user can access their file after recreating master key with re-login is passed after rerun
Scenario: user cannot access their file after recreating master key with re-login # /var/www/owncloud/testrunner/apps/encryption/tests/acceptance/features/webUIMasterKeyType/webUIMasterKeys.feature:8
Given user "Alice" has been created with default attributes and large skeleton files # FeatureContext::userHasBeenCreatedWithDefaultAttributes()
And the administrator has set the encryption type to "masterkey" # EncryptionContext::theAdministratorSetsEncryptionTypeToUsingTheOccCommand()
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/somefile.txt" # FeatureContext::userHasUploadedAFileTo()
And user "Alice" has logged in using the webUI # WebUILoginContext::theUserHasLoggedInUsingTheWebUI()
When the administrator successfully recreates the encryption masterkey using the occ command # EncryptionContext::recreateMasterKeyUsingOccCommand()
Then the command output should contain the text 'Note: All users are required to relogin.' # OccContext::theCommandOutputContainsTheText()
INFORMATION: timed out waiting for ajax calls to start
INFORMATION: timed out waiting for outstanding ajax calls
When the user opens file "lorem.txt" expecting to fail using the webUI # WebUIFilesContext::theUserOpensFolderNamedUsingTheWebUI()
│ INFORMATION: timed out waiting for ajax calls to startINFORMATION: timed out waiting for outstanding ajax calls
Then the user should be redirected to the general exception webUI page with the title "%productname%" # WebUIGeneralContext::theUserShouldBeRedirectedToGeneralExceptionPage()
Page\OwncloudPage::waitTillXpathIsVisible xpath: .//span[@class='error error-wide']//h2[1] cannot find element (SensioLabs\Behat\PageObjectExtension\PageObject\Exception\ElementNotFoundException)
And the title of the exception on general exception webUI page should be "Forbidden" # WebUIGeneralContext::anErrorShouldBeDisplayedOnTheGeneralExceptionPageWithTitle()
And a message should be displayed on the general exception webUI page containing "Encryption not ready" # WebUIGeneralContext::anErrorShouldBeDisplayedOnTheGeneralErrorPageContaining()
SCENARIO RESULT: (fail)
Scenario: user can access their file after recreating master key with re-login # /var/www/owncloud/testrunner/apps/encryption/tests/acceptance/features/webUIMasterKeyType/webUIMasterKeys.feature:21
Given user "Alice" has been created with default attributes and large skeleton files # FeatureContext::userHasBeenCreatedWithDefaultAttributes()
And the administrator has set the encryption type to "masterkey" # EncryptionContext::theAdministratorSetsEncryptionTypeToUsingTheOccCommand()
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/somefile.txt" # FeatureContext::userHasUploadedAFileTo()
And user "Alice" has logged in using the webUI # WebUILoginContext::theUserHasLoggedInUsingTheWebUI()
Expected to be on "http://server/index.php/login" but found "http://server/apps/files/" instead (SensioLabs\Behat\PageObjectExtension\PageObject\Exception\UnexpectedPageException)
When the administrator successfully recreates the encryption masterkey using the occ command # EncryptionContext::recreateMasterKeyUsingOccCommand()
And the user re-logs in as "Alice" using the webUI # WebUILoginContext::theUserRelogsInUsingTheWebUI()
And the user opens file "lorem.txt" using the webUI # WebUIFilesContext::theUserOpensFolderNamedUsingTheWebUI()
Then no dialog should be displayed on the webUI # WebUIGeneralContext::dialogsShouldBeDisplayedOnTheWebUI()
And the user should be redirected to a webUI page with the title "Files - %productname%" # WebUIGeneralContext::theUserShouldBeRedirectedToAWebUIPageWithTheTitle()
SCENARIO RESULT: (fail)
might be a flaky one: passing here https://drone.owncloud.com/owncloud/encryption/3463/16/15 but another pipeline failed
https://drone.owncloud.com/owncloud/encryption/3461/16/15 seems to be the first one that failed, morning of 2024-03-04. And that failed against core master and latest.
https://drone.owncloud.com/owncloud/encryption/3462/16/15 failed 2024-03-24 later in the morning (I suppose that the nightly job was restarted). It only failed against core master, and passed against core latest.
For more recent nightly runs: https://drone.owncloud.com/owncloud/encryption/3463/17/15 2024-03-04 midday, only failed with core latest. https://drone.owncloud.com/owncloud/encryption/3469/16/15 2024-03-09 only failed with core master. https://drone.owncloud.com/owncloud/encryption/3470/17/15 2024-03-10 only failed with core latest 10.14.0 https://drone.owncloud.com/owncloud/encryption/3473/16/15 2024-03-12 only failed with core master. https://drone.owncloud.com/owncloud/encryption/3476/17/15 2024-03-13 only failed with core latest 10.14.0 https://drone.owncloud.com/owncloud/encryption/3480/17/15 2024-03-16 only failed with core latest 10.14.0 https://drone.owncloud.com/owncloud/encryption/3481/16/15 2024-03-17 only failed with core master.
Other nights it failed the same with core master and core latest, including the last 2 nights 2024-03-18 and 2024-03-19.
So the test is somehow "flaky", but does fail more often than pass.
for some reason core crashes after recreating master key
now we have to find why it happens
https://drone.owncloud.com/owncloud/encryption/3508/13/15
Scenario: user cannot access their file after recreating master key without re-login # /var/www/owncloud/testrunner/apps/encryption/tests/acceptance/features/webUIMasterKeyType/webUIMasterKeys.feature:8
Given user "Alice" has been created with default attributes and without skeleton files # FeatureContext::userHasBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles()
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/somefile.txt" # FeatureContext::userHasUploadedAFileTo()
And user "Alice" has logged in using the webUI # WebUILoginContext::theUserHasLoggedInUsingTheWebUI()
When the administrator successfully recreates the encryption masterkey using the occ command # EncryptionContext::recreateMasterKeyUsingOccCommand()
Then the command output should contain the text 'Note: All users are required to relogin.' # OccContext::theCommandOutputContainsTheText()
INFORMATION: timed out waiting for ajax calls to start
INFORMATION: timed out waiting for outstanding ajax calls
When the user opens file "somefile.txt" expecting to fail using the webUI # WebUIFilesContext::theUserOpensFolderNamedUsingTheWebUI()
│ INFORMATION: timed out waiting for ajax calls to startINFORMATION: timed out waiting for outstanding ajax calls
Then the user should be redirected to the general exception webUI page with the title "server" # WebUIGeneralContext::theUserShouldBeRedirectedToGeneralExceptionPage()
And the title of the exception on general exception webUI page should be "Forbidden" # WebUIGeneralContext::anErrorShouldBeDisplayedOnTheGeneralExceptionPageWithTitle()
WebUIGeneralContext::anErrorShouldBeDisplayedOnTheGeneralExceptionPageWithTitle The title of the exception on general exception webUI page was expected to be 'Forbidden' but found 'This site can’t be reached' instead.
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'Forbidden'
+'This site can’t be reached'
And a message should be displayed on the general exception webUI page containing "Encryption not ready" # WebUIGeneralContext::anErrorShouldBeDisplayedOnTheGeneralErrorPageContaining()
SCENARIO RESULT: (fail)
ci is also showing same This site can’t be reached message
in local docker setup it gives 500 internal server error
core version: 10.14.0
similar issues https://github.com/owncloud/core/issues/30116 https://github.com/owncloud/core/issues/29681
in local docker setup it gives 500 internal server error
@nirajacharya2 please look in the server owncloud.log file and find the whole error/exception/traceback that is reported when the "500 internal server error" is returned to the test runner.
That will help us find where the server code is getting an exception/problem. Then maybe we will be able to use "git blame" to see when the relevant code was last touched, understand the reason that it crashes now, and propose a fix.
builds failed: https://drone.owncloud.com/owncloud/encryption/3705 2024-09-26 https://drone.owncloud.com/owncloud/encryption/3704 2024-09-25 https://drone.owncloud.com/owncloud/encryption/3703 2024-09-24