ci: run core's acceptance suite against the published image

[DeepDiver1975]

What

Adds .github/workflows/acceptance.yml — a reusable + dispatchable workflow that
runs core's Behat acceptance suite against a published owncloud/server
image — and wires it into main.yml as an acceptance job on master.

Why

Today's CI (docker-build.yml) proves the image builds, passes Trivy and answers
/status.php. That's it. There is no functional test of the shipped artifact,
so defects in the image's own layers — entrypoint scripts, the config.php
template, the app bundle — are only ever found by hand.

The retired .drone.star in this repo used to run exactly this pipeline, so
this is a port of something proven rather than a new invention.

How it works

• Test code comes from the release QA tarball (…-qa.tar.bz2), which is the
  same build as the shipped code and ships a version-matched testing app. The
  behat manifest, which the tarball omits, is fetched from the matching core tag.
• run.sh --remote proxies every occ call through the testing app's OCS
  endpoint, so the suite needs no shell access to the container.
• Sharding uses run.sh --part N M, mapped onto a matrix (api × 10,
  cli × 3 — kept at or below the suite count so no shard boots a full stack
  just to find it has nothing to run).

Notable adaptations for Actions

Decision	Reason
docker run --network host for everything, not services:	The suite hands federated addresses like localhost:8081 to the server, so they must resolve to the peer from inside the container. On a bridge network they resolve to the container itself.
testing app bind-mounted from the QA tarball, writable	The app's GitHub "latest" release asset was last rebuilt in 2022 and isn't version-matched. And 25-chown.sh chowns the whole app tree at every start — the entrypoint aborts with exit 123 if that fails, so :ro kills the server.
Enabled apps pinned explicitly	Core CI installs from core's tree, where Installer::getShippedApps() enables every default_enable app. The Complete bundle default-enables a different set; a mismatch shows up as failures that look like server regressions (e.g. disabling files_external makes apiAuth report OCS 999 instead of 997).
OWNCLOUD_REDIS_ENABLED only, no OWNCLOUD_MEMCACHE_LOCKING	The template's redis branch uses array_merge_recursive; setting both renders memcache.locking as a two-element array instead of a class name.

Trigger and scope

• master only, after build. Deliberately off PRs — those are mostly
  renovate digest bumps and the ~4 min loop should stay that fast.
• Default filter is @smokeTest. The full set is available via
  workflow_dispatch (clear filter-tags, raise shards).
• 10.16.3 is not covered: 10.x ships no QA tarball, and it still uses
  behat.yml rather than behat.php, so run.sh would need a different
  invocation. Noted in a comment on the matrix entry.

Verification

Run locally against owncloud/server:11.0.0-rc3 with the exact stack the
workflow builds (mariadb 10.6 + redis 8 + inbucket + two rc3 containers on
8080/8081):

• status.php green on both ports; occ transport returns code=0 on both
• app:list shows exactly the intended 13 enabled apps
• memcache.locking renders as the \OC\Memcache\Redis scalar
• A real smoke shard: Total 76 scenarios (76 passed, 0 failed), exit 0,
  "There were no unexpected failures." — including apiFederationToRoot1 4/4,
  which is what proves the --network host federation addressing works.

actionlint (incl. its shellcheck pass) is clean on both files.

Out of scope

• The 34 webUI suites (need Selenium; core's own CI never enables them).
• Testing the image before publish. docker-build.yml pushes to a job-local
  registry and exposes no outputs, so that needs an upstream change in
  owncloud-docker/ubuntu. Worth doing later — it would catch defects before
  publish rather than after.
• Fixing anything the run surfaces. apps_paths is written unconditionally by
  the config template so AppManagementContext::setAppsPaths() can't mutate it,
  and convert/ffmpeg are absent (hence the additional-packages input).
  Separate PRs.

🤖 Generated with Claude Code

[phil-davis]

https://github.com/owncloud-docker/server/actions/runs/30525799046
The action shivammathur/setup-php@f3e473d116dcccaddc5834248c87452386958240 is not allowed in owncloud-docker/server because all actions must be from a repository owned by owncloud-docker, created by GitHub, verified in the GitHub Marketplace, or match one of the patterns: ...

[phil-davis]

This might work. I am glad that I didn't spend days trying to convert the drone starlark code into this! How do we actually run it to see a result?

[DeepDiver1975]

ow do we actually run it to see a result?

As a first approach I want to run the tests in this PR with the 11.0.0-rc3 image - quick win for the upcoming release.

In the long run a minimal smoke test should run upon every build - maybe a bigger suite - no idea yet ..... exploring ....

[phil-davis]

https://github.com/owncloud-docker/server/actions/runs/30528690247/job/90827472789?pr=677

    And the owncloud log level has been set to debug                                                                                       # LoggingContext::owncloudLogLevelHasBeenSetTo()
      The expected log level is 0 but the log level has been set to 2
      Failed asserting that 2 matches expected 0.

The code underneath calls to the testing app to do:
occ log:manage --level=0

Is there anything special about trying to adjust the log level inside the container?

[phil-davis]

The owncloud log for https://github.com/owncloud-docker/server/actions/runs/30528690247/job/90827472789?pr=677 has a lot of complaints about background jobs, for example:

{"reqId":"4VgKk3UjHzLm1zHWYfSF","level":3,"time":"2026-07-30T09:12:33+00:00","remoteAddr":"::1","user":"--","app":"core","method":"POST","url":"\/ocs\/v2.php\/apps\/testing\/api\/v1\/occ","message":"Exception: {\"Exception\":\"OCP\\\\AppFramework\\\\QueryException\",\"Message\":\"Could not resolve OCA\\\\Activity\\\\BackgroundJob\\\\ExpireActivities! Class \\\"OCA\\\\Activity\\\\BackgroundJob\\\\ExpireActivities\\\" does not exist\",\"Code\":0,\"Trace\":\"#0 \\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/AppFramework\\\/Utility\\\/SimpleContainer.php(108): OC\\\\AppFramework\\\\Utility\\\\SimpleContainer->resolve()\\n#1 \\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/ServerContainer.php(86): OC\\\\AppFramework\\\\Utility\\\\SimpleContainer->query()\\n#2 \\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/BackgroundJob\\\/JobList.php(282): OC\\\\ServerContainer->query()\\n#3 \\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/BackgroundJob\\\/JobList.php(372): OC\\\\BackgroundJob\\\\JobList->buildJob()\\n#4 \\\/var\\\/www\\\/owncloud\\\/core\\\/Command\\\/Background\\\/Queue\\\/Status.php(98): OC\\\\BackgroundJob\\\\JobList->listJobs()\\n#5 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/symfony\\\/console\\\/Command\\\/Command.php(341): OC\\\\Core\\\\Command\\\\Background\\\\Queue\\\\Status->execute()\\n#6 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/symfony\\\/console\\\/Application.php(1094): Symfony\\\\Component\\\\Console\\\\Command\\\\Command->run()\\n#7 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/symfony\\\/console\\\/Application.php(356): Symfony\\\\Component\\\\Console\\\\Application->doRunCommand()\\n#8 \\\/var\\\/www\\\/owncloud\\\/lib\\\/composer\\\/symfony\\\/console\\\/Application.php(195): Symfony\\\\Component\\\\Console\\\\Application->doRun()\\n#9 \\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/Console\\\/Application.php(165): Symfony\\\\Component\\\\Console\\\\Application->run()\\n#10 \\\/var\\\/www\\\/owncloud\\\/console.php(96): OC\\\\Console\\\\Application->run()\\n#11 {main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/AppFramework\\\/Utility\\\/SimpleContainer.php\",\"Line\":94}"}

I suppose that many apps are in the disabled list, but their background jobs are still registered. Is there something that can be done to de-register background jobs for apps that are disabled, or?