forked from coop-cloud/nextcloud
Compare commits
9 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| fcf1ca56d3 | |||
| 15a795affd | |||
| 38c426178a | |||
| 38920ae3de | |||
| 6e6c235acd | |||
| 10fdbc92b4 | |||
| 8ce1b9cf30 | |||
| 29431d2a14 | |||
| 66fdde358e |
-35
@@ -1,40 +1,5 @@
|
||||
---
|
||||
kind: pipeline
|
||||
name: deploy to swarm-test.autonomic.zone
|
||||
steps:
|
||||
- name: deployment
|
||||
image: git.coopcloud.tech/coop-cloud/stack-ssh-deploy:latest
|
||||
settings:
|
||||
host: swarm-test.autonomic.zone
|
||||
stack: nextcloud
|
||||
generate_secrets: true
|
||||
purge: true
|
||||
deploy_key:
|
||||
from_secret: drone_ssh_swarm_test
|
||||
networks:
|
||||
- proxy
|
||||
environment:
|
||||
DOMAIN: nextcloud.swarm-test.autonomic.zone
|
||||
STACK_NAME: nextcloud
|
||||
LETS_ENCRYPT_ENV: production
|
||||
ADMIN_USER: foobar
|
||||
FPM_TUNE_VERSION: v1
|
||||
NGINX_CONF_VERSION: v1
|
||||
MY_CNF_VERSION: v1
|
||||
ENTRYPOINT_VERSION: v1
|
||||
CRONTAB_VERSION: v1
|
||||
PG_BACKUP_VERSION: v2
|
||||
SECRET_DB_PASSWORD_VERSION: v1
|
||||
SECRET_DB_ROOT_PASSWORD_VERSION: v1
|
||||
SECRET_ADMIN_PASSWORD_VERSION: v1
|
||||
SECRET_ONLYOFFICE_JWT_VERSION: v1
|
||||
SECRET_BBB_SECRET_VERSION: v1
|
||||
EXTRA_VOLUME: "/dev/null:/tmp/.dummy"
|
||||
trigger:
|
||||
branch:
|
||||
- main
|
||||
---
|
||||
kind: pipeline
|
||||
name: generate recipe catalogue
|
||||
steps:
|
||||
- name: release a new version
|
||||
|
||||
@@ -0,0 +1,91 @@
|
||||
# Nextcloud Recipe Maintenance
|
||||
|
||||
This document describes how the Nextcloud recipe is maintained. It builds on
|
||||
the floor set by [Federation Resolution
|
||||
025](https://docs.coopcloud.tech/federation/resolutions/passed/025/) and
|
||||
follows the [`MAINTENANCE.md`
|
||||
template](https://docs.coopcloud.tech/maintainers/maintain/#maintenancemd-template)
|
||||
described in the Co-op Cloud maintainers' docs.
|
||||
|
||||
All contributions should be made via a pull request so that quality and
|
||||
consistency stay something others can rely on.
|
||||
|
||||
## Maintainers
|
||||
|
||||
Everyone can apply to be a recipe maintainer.
|
||||
Simply add yourself to the list in the README.md and open a new pull request
|
||||
with the change.
|
||||
|
||||
## Maintainer Responsibilities
|
||||
|
||||
This recipe commits to the following, which is tighter than the floor set by
|
||||
Resolution 025 (stable-recipe category). However, these timelines are
|
||||
best-effort, so we aim for them as good as possible:
|
||||
|
||||
- Respond to PRs / issues within 3 working days
|
||||
- Apply security patches within 1 week of disclosure
|
||||
- Ship patch / minor image updates within 2 weeks of upstream release
|
||||
- Adopt major Nextcloud version updates within 1 release cycle of upstream
|
||||
EOL of the previous major (see below)
|
||||
- Keep documentation current
|
||||
|
||||
In order to meet these responsibilities each maintainer:
|
||||
|
||||
- Watches the repository so notifications arrive
|
||||
- Keeps an eye on [Renovate](./renovate.json) updates and helps shepherd them through
|
||||
- Has a working contact (Matrix handle or email) reachable by the others
|
||||
|
||||
## Release cadence
|
||||
|
||||
The intent is to **track Nextcloud's own release schedule** rather than invent
|
||||
our own. In practice this means:
|
||||
|
||||
- **Patch releases (e.g. `32.0.x`)**: published to this recipe shortly after
|
||||
upstream, ideally within 1 week. `chore(deps)` opens the PRs; a maintainer
|
||||
reviews the release notes and Nextcloud's issue tracker, and merges the PR
|
||||
if it is OK.
|
||||
- **Minor releases**: same flow as patch releases, but one of the maintainer
|
||||
tests it on their own instance before merging.
|
||||
- **Major releases (e.g. `32 → 33`)**: not adopted on day one. We wait for the
|
||||
first one or two upstream patch releases of the new major to land
|
||||
(typically 1–2 months) before promoting it here, to avoid passing the
|
||||
early-adopter cost to operators. Major bumps get their own PR with release
|
||||
notes and an upgrade-path check.
|
||||
Before adding a major release, the following needs to be done:
|
||||
- at least two maintainers update one of their production instances to the
|
||||
new version
|
||||
- the previous release gets a last update pointing to the docker image
|
||||
versions nextcloud:xx-fpm, so that users can auto-update if they wish so
|
||||
- the new release is added to this repo
|
||||
- If people have the time it would be nice to create specially tagged versions
|
||||
for major releases, which reflect that this is 'bleeding edge' and has not
|
||||
been thoroughly tested.
|
||||
- **Co-installed components** (Talk HPB, OnlyOffice, Whiteboard, etc.) are
|
||||
bumped alongside or shortly after the matching Nextcloud release.
|
||||
|
||||
## Pull Requests
|
||||
|
||||
A pull request can be merged once it is approved by at least one maintainer.
|
||||
PRs opened by a maintainer need approval from another maintainer. With three
|
||||
maintainers this is workable; if the group shrinks, the rule should be
|
||||
revisited.
|
||||
|
||||
Approvals should ideally include a smoke test on a real instance for anything
|
||||
beyond a patch bump — Nextcloud upgrades have a long history of surprising us
|
||||
(see the [upgrade notes in `README.md`](./README.md#upgrading-nextcloud)),
|
||||
and silent CI is not enough.
|
||||
|
||||
## Becoming a maintainer
|
||||
|
||||
Everyone is welcome to apply:
|
||||
|
||||
1. Watch the repository so you get notifications.
|
||||
2. Open a pull request adding yourself to the `Maintainer` line in
|
||||
[`README.md`](./README.md) and to the list above.
|
||||
3. Once an existing maintainer merges the PR, you'll be added to the
|
||||
[nextcloud maintainers
|
||||
team](https://git.coopcloud.tech/org/coop-cloud/teams/nextcloud-maintainers).
|
||||
|
||||
Stepping down is symmetrical: open a PR removing yourself, and flag it in
|
||||
the federation channels so the group can plan replacement before falling
|
||||
below the Res. 025 floor of one named maintainer.
|
||||
@@ -5,6 +5,7 @@
|
||||
Fully automated luxury Nextcloud via docker-swarm.
|
||||
|
||||
<!-- metadata -->
|
||||
* **Maintainer**: [@dannygroenewegen](https://git.coopcloud.tech/dannygroenewegen), [@ineiti](https://git.coopcloud.tech/ineiti)
|
||||
* **Category**: Apps
|
||||
* **Status**: 5
|
||||
* **Image**: [`nextcloud`](https://hub.docker.com/_/nextcloud), 4, upstream
|
||||
@@ -25,9 +26,9 @@ Fully automated luxury Nextcloud via docker-swarm.
|
||||
|
||||
### Onlyoffice Integration
|
||||
|
||||
First install onlyoffice following the instructions in the
|
||||
First, install onlyoffice following the instructions in the
|
||||
[OnlyOffice Recipe](https://recipes.coopcloud.tech/onlyoffice), and enable
|
||||
the JWT secret.
|
||||
the JWT secret. Then configure your nextcloud instance with:
|
||||
|
||||
`abra app config <app-name>`
|
||||
|
||||
|
||||
+1
-1
@@ -95,7 +95,7 @@ services:
|
||||
failure_action: rollback
|
||||
order: start-first
|
||||
labels:
|
||||
- "coop-cloud.${STACK_NAME}.version=13.1.0+32.0.11-fpm"
|
||||
- "coop-cloud.${STACK_NAME}.version=13.1.1+32.0.12-fpm"
|
||||
- "coop-cloud.${STACK_NAME}.timeout=${TIMEOUT}"
|
||||
- "backupbot.backup=${ENABLE_BACKUPS:-true}"
|
||||
- "backupbot.backup.volumes.redis=false"
|
||||
|
||||
Reference in New Issue
Block a user