Compare commits

..

2 Commits

Author SHA1 Message Date
8922150994 docs/maintainers/handbook.md aktualisiert 2025-06-05 09:13:49 +00:00
1618faa420 docs/maintainers/handbook.md aktualisiert
Thats how I until now understood process of adding an env var. Thought it might help other's who are new. I am very open to suggestions, other best practices, corrected typos...
2025-06-04 16:40:33 +00:00
3 changed files with 39 additions and 47 deletions

View File

@ -1,41 +0,0 @@
---
title: "Resolution 031"
---
- Topic: Critical fixes amended process
- Date: 2025-06-10
- Deadline: 2025-06-24
- Size: Medium
### Summary
This resolution proposes specific changes to [`R010: Budget 004: Critical
fixes`](../passed/010.md). These changes are primarily intended to improve
transparency and match our new organising methods.
## Details
Ammendments are as follows.
1. "Confirmation from at least one other member": should be confirmed on the
issue itself and not in the Matrix chat. It is suggested to indicate this
when posting in the Matrix chat (aka "Please +1 on the issue itself").
1. "A fix is deemed critical": when it is marked with the label "critical fix".
There is no specific project tracker for only these issues. This label can
be re-used across repositories also.
### R010 in full
> We propose to have a standing budget of 10 hrs / month available for fixes in Abra, Co-op Cloud recipes and other critical tools (e.g. recipes.coopcloud.tech) in the Co-op Cloud ecosystem.
>
> A fix is deemed critical when it is listed on this toolshed/organising board:
>
> > https://git.coopcloud.tech/toolshed/organising/projects/24
>
> This board is collectively gardened by Co-op Cloud participants (both federation members and not). The process for adding a ticket to the board requires getting confirmation from at least one other member of the federation.
>
> This budget can be claimed by any volunteer who would like to develop the fix. If the volunteer is not a Co-op Cloud federation member, they must first be "vouched for" by a federation member. This is an informal process which can be arranged via the Matrix chat. This aims to assure agreement on timing and what the fix should contain beforehand.
>
> Fixes can be claimed by assiging yourself to the ticket. If within 1 week there is no updates on the ticket, another volunteer can propose to take over. This process is also informal: please @ the original volunteer and give some reasonable time for them to reply (suggested: 1 day).
>
> If the fix is urgent and things need to move faster, please state so on the ticket. Please consult with at least one other member of the federation to confirm that there is indeed agreement on the urgency of the fix.

View File

@ -124,6 +124,45 @@ You can also access it in your configs using the following syntax:
{{ env "FOO" }}
```
### Example: Adding environment variables to existing recipe
Here is a four step example how to add a new environment variable to a recipe without breaking existing deployments.
1. add env-var to the `compose.yml` in section `environment`:
```yaml
environment:
# ... existing envs
- REQUIRE_AUTH_FOR_PROFILE_REQUESTS=${REQUIRE_AUTH_FOR_PROFILE_REQUESTS:-false}
# ... other existing envs
```
With `${REQUIRE_AUTH_FOR_PROFILE_REQUESTS:-false}` you set a default value (`false`), ensuring not to break existing deployments.
If you're sure that it won't cause problems, if operators of existing deployments don't set the variable, you could also just put:
```yaml
environment:
# ... existing envs
- REQUIRE_AUTH_FOR_PROFILE_REQUESTS
# ... other exisitng envs
```
Note: If you need to break something, make sure to add a [release note](/maintainers/handbook/#how-do-i-write-version-release-notes) explaining to operators what they should change before upgrading.
2. add env-var to the `.env.sample`
```yaml
#REQUIRE_AUTH_FOR_PROFILE_REQUESTS=true
```
3. now you can use the environment-variable in your `.tmpl` files, e.g. add to `homserver.yaml.tmpl`
```yaml
require_auth_for_profile_requests: {{ env "REQUIRE_AUTH_FOR_PROFILE_REQUESTS" }}
```
4. increase number of YAML-version in `abra.sh` (e.g. from `v30` to `v31`), only then it will be deployed.
```yaml
export HOMESERVER_YAML_VERSION=v31
```
Note: If during development and testing you have to increase it several times, you can just "flatten" it in the end. Only make sure that you `undeploy`/`deploy` your existing instance.
### Global environment variables
- `TYPE`: specifies the recipe name
@ -717,11 +756,6 @@ Please note:
1. In order to pass execution back to the original entrypoint, it's a good idea to find the original entrypoint script and run it from your own entrypoint script. If there is none, you may want to reference the `CMD` definition or if that isn't working, try to actually specify `cmd: ...` in the `compose.yml` definition (there are other recipes which do this).
1. Also it might be necessary to define command: although there is an original entrypoint. That's [due to the fact](https://docs.docker.com/reference/compose-file/services/#entrypoint) that if entrypoint is non-null, Compose ignores any default command from the image, for example the `CMD` instruction in the Dockerfile.
1. Pratically you would e.g. look for the Dockerfile of the upstream image. In there you should find the docker-entrypoint.sh (or similar) and where it's located. Furthermore you find the `CMD`-line there.
1. Just put in your entrypoint.sh in the last line: exec /path/to/docker-entrypoint.sh "@" (path and filename you should find in upstream Dockerfile) and insert command: to your service in compose.yml with the value of what you find in the CMD line of the Dockerfile.
1. If you're feeling reckless, you can also use the Golang templating engine to do things conditionally.
Then, wire up the vendored config version:

View File

@ -126,7 +126,6 @@ nav:
- "In Progress":
- federation/resolutions/index.md
- federation/resolutions/in-progress/030-docs-naming-survey.md
- federation/resolutions/in-progress/031.md
- "Minutes":
- federation/minutes/index.md
- "Recently":