Skip to content

ci: initial acceptance test workflow#41552

Draft
phil-davis wants to merge 22 commits into
masterfrom
acceptance-workflow-20260519
Draft

ci: initial acceptance test workflow#41552
phil-davis wants to merge 22 commits into
masterfrom
acceptance-workflow-20260519

Conversation

@phil-davis
Copy link
Copy Markdown
Contributor

TBD

@phil-davis phil-davis force-pushed the acceptance-workflow-20260519 branch 2 times, most recently from 8951ddd to f63cd28 Compare May 21, 2026 00:14
Comment thread tests/acceptance/config/behat.php Outdated
Comment on lines +51 to +54
'ldapAdminPassword' => 'admin',
'ldapUsersOU' => 'TestUsers',
'ldapGroupsOU' => 'TestGroups',
'ldapInitialUserFilePath' => '/../../config/ldap-users.ldif',
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I expected, the --convert-config tool didn't do anything special with your YAML aliases (because it runs after the YAML is parsed) so it has duplicated all the blocks that were in your shared common_ldap_suite_context and common_feature_context_params definitions.

You might want to extract all those duplicates out to variables for readability / ease of maintenance?

Comment thread tests/acceptance/run.sh
Comment on lines 442 to 453
# If there were no scenarios in the requested suite or feature that match
# the requested combination of tags, then Behat exits with an error status
# and reports "No scenarios" in its output.
# This can happen, for example, when running core suites from an app and
# requesting some tag combination that does not happen frequently. Then
# sometimes there may not be any matching scenarios in one of the suites.
# In this case, consider the test has passed.
MATCHING_COUNT=`grep -ca '^No scenarios$' ${TEST_LOG_FILE}`
if [ ${MATCHING_COUNT} -eq 1 ]
then
echo "Information: no matching scenarios were found."
BEHAT_EXIT_STATUS=0
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since Behat 3.20.0, we have an --allow-no-tests argument for exactly this situation - it will always exit 0 if no tests are found. That might allow you to simplify your bash script a bit?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That for the info @acoulton

Comment thread tests/acceptance/run.sh
Comment on lines 650 to 670
echo "Rerun failed scenario: ${FAILED_SCENARIO_PATH}"
${BEHAT} ${COLORS_OPTION} --strict -c ${BEHAT_YML} -f pretty ${BEHAT_SUITE_OPTION} --tags ${BEHAT_FILTER_TAGS} ${FAILED_SCENARIO_PATH} -v 2>&1 | tee -a ${TEST_LOG_FILE}
${BEHAT} ${COLORS_OPTION} --strict -c ${BEHAT_CONFIG_FILE} -f pretty ${BEHAT_SUITE_OPTION} --tags ${BEHAT_FILTER_TAGS} ${FAILED_SCENARIO_PATH} -v 2>&1 | tee -a ${TEST_LOG_FILE}
BEHAT_EXIT_STATUS=${PIPESTATUS[0]}
if [ ${BEHAT_EXIT_STATUS} -eq 0 ]
then
# The scenario was not expected to fail but had failed and is present in the
# unexpected_failures list. We've checked the scenario with a re-run and
# it passed. So remove it from the unexpected_failures list.
for i in "${!UNEXPECTED_FAILED_SCENARIOS[@]}"
do
if [ "${UNEXPECTED_FAILED_SCENARIOS[i]}" == "$SUITE_SCENARIO" ]
then
unset "UNEXPECTED_FAILED_SCENARIOS[i]"
fi
done
else
echo "webUI test rerun failed with exit status: ${BEHAT_EXIT_STATUS}"
# The scenario is not expected to fail but is failing also after the rerun.
# Since it is already reported in the unexpected_failures list, there is no
# need to touch that again. Continue processing the next scenario to rerun.
fi
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't explored / followed the full details of what your bash script does if scenarios fail but it looks like at least some of it is concerned with retrying failed scenarios.

You might want to look into Behat's --rerun and --rerun-only options:

  • --rerun is the original flag, it will run all scenarios that failed on the last execution, but it runs everything if nothing failed.
  • --rerun-only was added in 3.15.0 - it will run all scenarios that failed on the last execution, or just exit 0 without running anything if there were no previous failures.

Note these run all the failures in a single Behat execution, it looks like you may be running a separate Behat process for each scenario - so if the failures are due to state conflicts between scenarios then those might happen again depending on what gets re-run.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note these run all the failures in a single Behat execution, it looks like you may be running a separate Behat process for each scenario - so if the failures are due to state conflicts between scenarios then those might happen again depending on what gets re-run.

From memory, I think that I reran them one scenario at a time because I was parsing the list of failed scenarios in Bash, and it was easiest to run just one failed scenario as I found it (I had the exact feature file and line number).

I will have a look at the --rerun-only option. That looks good for me.

Comment thread tests/acceptance/run.sh
Comment on lines 423 to 425
# Find the count of scenarios that passed
SCENARIO_RESULTS_COLORED=`grep -Ea '^[0-9]+[[:space:]]scenario(|s)[[:space:]]\(' ${TEST_LOG_FILE}`
SCENARIO_RESULTS=$(echo "${SCENARIO_RESULTS_COLORED}" | sed "s/\x1b[^m]*m//g")
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't guarantee the output of the pretty formatter over time (though we don't expect to change it much).

Rather than attempting to parse it with grep / sed / awk etc, you could look into the JSON formatter added in 3.26.0. JSON is always rendered to a file, so you could also keep the pretty output but use jq or similar to parse the values you need out of the JSON file?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I didn't like parsing the "pretty" output, as it can change at any time. I remember it changing one time when extra information was added to the output lines, and I had to realise that and code for it.

JSON (or any other structured data format) will be much better.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. I think a few people parsed pretty in the past because the only other option was the JUnit XML and parsing that in the shell isn't that straightforward either. Hopefully the new JSON / jq will help.

@phil-davis phil-davis force-pushed the acceptance-workflow-20260519 branch from eabecb8 to bf458e0 Compare May 21, 2026 10:19
@phil-davis phil-davis force-pushed the acceptance-workflow-20260519 branch from bf458e0 to 0f0279c Compare May 21, 2026 11:35
phil-davis added 21 commits May 22, 2026 08:24
This fixes log file messages like

{"reqId":"rRziQ2UaFono1r96TEdK","level":3,"time":"2026-05-19T12:44:35+00:00","remoteAddr":"::1",
"user":"Brian","app":"PHP","method":"PUT",
"url":"\/server\/remote.php\/webdav\/textfile0.txt-chunking-42-3-2",
"message":"Trying to access array offset on false at
\/var\/www\/html\/server\/lib\/private\/Files\/Storage\/Wrapper\/Encryption.php#475"}
This will fix log file messages like

{"reqId":"oAKAHIupnZUz4ujYoFqY","level":3,"time":"2026-05-19T12:46:31+00:00","remoteAddr":"::1",
"user":"--","app":"PHP","method":"POST",
"url":"\/server\/ocs\/v1.php\/apps\/federation\/api\/v1\/request-shared-secret",
"message":"strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated
at \/var\/www\/html\/server\/apps\/federation\/lib\/DbHandler.php#298"}
testRemoteUrl was only checking for a responding ownCloud at the
provided host. But if the server is installed in a subdirectory
then the requests were not sent there. For example:
- the cloud server is at http://mydomain.com/cloud
- testRemoteUrl checked for a repsonse from http://mydomain.com/status.php

Now it checks for a response from http://mydomain.com/cloud/status.php
Bump to the current minor releases. This is what is used in reality
in CI, so record that here to make sure that everyone is using at
least these versions.
Because 7.4.12 has a limit of 128 on the number of collection aliases.
And we need over 200.
A way to configure this may be needed.
Using YML for the Behat config has b een deprecated.
So make the change to Behat PHP config.
@phil-davis phil-davis force-pushed the acceptance-workflow-20260519 branch from 6de7e4a to d8e9307 Compare May 21, 2026 22:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants