[vitormattos]

Summary

Automate maintained Nextcloud container releases without depending on a hardcoded 33/34/35 matrix or the Nextcloud Docker repository's retention policy.

• Add reviewed .github/nextcloud-supported.json derived from the upstream Maintenance and Release Schedule wiki; initially contains supported 33, 34 and 35.
• Add a twice-daily/manual discovery workflow that validates wiki structure, EOL consistency, official stable GitHub releases and exact official FPM image tags (amd64/arm64), then opens a PR for JSON changes. Parser/validation failures fail the workflow without changing the reviewed file or creating a PR.
• Generate the build matrix from the committed JSON rather than querying upstream during image publishing. Expired EOL entries block publication.
• Build application images from exact reviewed patch versions, and the web image once independently of a Nextcloud major.
• Move versioned and patch tags, then app :stable-fpm and legacy :latest to the newest reviewed supported major; move web :main and legacy :latest separately. Remove the previous hardcoded 35-fpm condition.
• Move staging, manifest assembly and alias promotion out of inline workflow code into testable Bash scripts. Reuse the same generic multiarch push/manifest helpers for stable and master-fpm images.
• Keep Trivy's HIGH/CRITICAL gates, Bats runtime acceptance, staging tags and development :master-fpm workflow.
• Preserve existing EOL images already published in GHCR; stop rebuilding them after their removal is approved.

CI and approval boundaries

• A bot-created PR does not publish any image. The watcher dispatches validation on the automation branch because ordinary GITHUB_TOKEN pushes do not automatically trigger PR checks.
• workflow_dispatch off main is validation-only, and publishing requires refs/heads/main plus all passing gates.
• Review and merge the proposed JSON update manually. There is no auto-merge.
• Automated PR commits use peter-evans/create-pull-request with DCO signoff and GitHub Actions verified bot signing; authored commits in this PR use the Git Signing MCP.

Validation

• Removed all four Python files and the additional Python test framework. Discovery uses scripts/nextcloud-versions.sh, a narrow AWK Markdown parser and jq; publication uses Bash; all regression tests use the project's existing Bats framework.
• 20 Bats regression tests passed for discovery/publication, plus 5 existing master-image Bats tests. Historical wiki snapshots from 2023-2026, malformed/unreleased/EOL cases and simulated Docker commands are covered.
• Re-ran the new Bash/AWK parser against all 92 upstream wiki revisions since January 2025: 76 parsed successfully; 16 safely rejected due to incomplete, malformed or contradictory upstream data. Historical formatting differences within the EOL table are tolerated when the supported-version table remains valid. No silent fallback.
• Confirmed official GitHub releases and Docker FPM tags for 33.0.10, 34.0.5 and 35.0.2 (both architectures).
• bash tests/test-scan-images.sh passed; ShellCheck, actionlint and git diff --check passed locally. The stable and discovery workflows now run Bats checks directly in CI.
• Full GitHub Actions multi-architecture CI must pass on the final commit before merge; publication itself is only exercised after merge.

Documentation

• Simplified English and Portuguese READMEs to focus on project value, supported image choices and quick adoption.
• Moved deployment and customization procedures into language-specific guides.
• Kept public tag compatibility and upgrade advice in docs/images.md, while consolidating wiki parsing, approved JSON, CI and publication details in docs/maintenance.md.
• Verified local Markdown links and Compose configuration syntax.

Operational note

:latest intentionally tracks the latest supported major. Existing deployments should pin <major>-fpm or OCI digest to avoid unsafe unattended Nextcloud major upgrades. An environment sample using 35-fpm is deliberately a pinned example; it does not control CI releases.

For users, see docs/images.md for image tags and upgrade guidance, and docs/deployment.md / docs/deployment_ptBR.md for deployment. For maintainers, see docs/maintenance.md for discovery, release workflows, approval requirements and failure handling.

Related to #47.