The only thing is, and this is still a bit "up in the air" as to how to handle (I think), is that if another operator deploys and doesn't copy over MEDIAWIKI_LANGUAGE then they'll potentially have a broken config cus they're missing the "en" default.
Two ways I've seen people mitigate that is 1) add a note to the release notes 2) add a default to the env loading.
LGTM!
The only thing is, and this is still a bit "up in the air" as to how to handle (I think), is that if another operator deploys and doesn't copy over `MEDIAWIKI_LANGUAGE` then they'll potentially have a broken config cus they're missing the "en" default.
Two ways I've seen people mitigate that is 1) add a note to the release notes 2) add a default to the `env` loading.
Oh wait a sec, does it also need to be threaded in via the compose.yml file env?
Hm, its working for me as is. Its only needed for the template, so maybe no?
The only thing is, and this is still a bit "up in the air" as to how to handle (I think), is that if another operator deploys and doesn't copy over MEDIAWIKI_LANGUAGE then they'll potentially have a broken config cus they're missing the "en" default.
True, didn't think of that! Will add a note.
> Oh wait a sec, does it also need to be threaded in via the `compose.yml` file env?
Hm, its working for me as is. Its only needed for the template, so maybe no?
> The only thing is, and this is still a bit "up in the air" as to how to handle (I think), is that if another operator deploys and doesn't copy over MEDIAWIKI_LANGUAGE then they'll potentially have a broken config cus they're missing the "en" default.
True, didn't think of that! Will add a note.
Oh wait a sec, does it also need to be threaded in via the compose.yml file env?
Hm, its working for me as is. Its only needed for the template, so maybe no?
If you run env | grep -i language inside the container, do you see anything? If not, I'd say it's worth adding to the env stanza in the compose.yml. The config might already be written since you deployed before this change.
> > Oh wait a sec, does it also need to be threaded in via the `compose.yml` file env?
>
> Hm, its working for me as is. Its only needed for the template, so maybe no?
>
If you run `env | grep -i language` inside the container, do you see anything? If not, I'd say it's worth adding to the `env` stanza in the `compose.yml`. The config might already be written since you deployed before this change.
If you run env | grep -i language inside the container, do you see anything? If not, I'd say it's worth adding to the env stanza in the compose.yml. The config might already be written since you deployed before this change.
Yes, it is set inside the running container. And I can use it to change the language on a deploy --chaos.
Actually, there is all kinds of vars set in app that are not set in db, like LETS_ENCRYPT_ENV, ENTRYPOINT_CONF_VERSION, ... Same behaviour for my outline deployment. Is this a bug?
Anyway, will just add it.
> If you run `env | grep -i language` inside the container, do you see anything? If not, I'd say it's worth adding to the `env` stanza in the `compose.yml`. The config might already be written since you deployed before this change.
Yes, it is set inside the running container. And I can use it to change the language on a `deploy --chaos`.
Actually, there is all kinds of vars set in `app` that are not set in `db`, like `LETS_ENCRYPT_ENV`, `ENTRYPOINT_CONF_VERSION`, ... Same behaviour for my outline deployment. Is this a bug?
Anyway, will just add it.
Actually, there is all kinds of vars set in app that are not set in db, like LETS_ENCRYPT_ENV, ENTRYPOINT_CONF_VERSION, ... Same behaviour for my outline deployment. Is this a bug?
> Actually, there is all kinds of vars set in app that are not set in db, like LETS_ENCRYPT_ENV, ENTRYPOINT_CONF_VERSION, ... Same behaviour for my outline deployment. Is this a bug?
These are injected in via `abra` AFAIR. This supports `kadabra` being able to restart deployments because the env vars are attached via `abra`. This was mentioned in https://docs.coopcloud.tech/abra/upgrade/#06x-beta-07x-beta
Hm, its working for me as is. Its only needed for the template, so maybe no?
Yes, in my experience variables which only appear in configs don't need to be added in compose.yml. Probably no harm in them being there though.
The only thing is, and this is still a bit "up in the air" as to how to handle (I think), is that if another operator deploys and doesn't copy over MEDIAWIKI_LANGUAGE then they'll potentially have a broken config cus they're missing the "en" default.
Thanks so much for this change! ♥
>Hm, its working for me as is. Its only needed for the template, so maybe no?
Yes, in my experience variables which only appear in configs don't need to be added in `compose.yml`. Probably no harm in them being there though.
> The only thing is, and this is still a bit "up in the air" as to how to handle (I think), is that if another operator deploys and doesn't copy over MEDIAWIKI_LANGUAGE then they'll potentially have a broken config cus they're missing the "en" default.
Best solution to this I can think of is to use the golang `or` construction to provide a default, e.g. https://git.coopcloud.tech/coop-cloud/matrix-synapse/src/branch/main/homeserver.yaml.tmpl#L41
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Title says it all
LGTM!
The only thing is, and this is still a bit "up in the air" as to how to handle (I think), is that if another operator deploys and doesn't copy over
MEDIAWIKI_LANGUAGEthen they'll potentially have a broken config cus they're missing the "en" default.Two ways I've seen people mitigate that is 1) add a note to the release notes 2) add a default to the
envloading.Oh wait a sec, does it also need to be threaded in via the
compose.ymlfile env?Hm, its working for me as is. Its only needed for the template, so maybe no?
True, didn't think of that! Will add a note.
If you run
env | grep -i languageinside the container, do you see anything? If not, I'd say it's worth adding to theenvstanza in thecompose.yml. The config might already be written since you deployed before this change.Yes, it is set inside the running container. And I can use it to change the language on a
deploy --chaos.Actually, there is all kinds of vars set in
appthat are not set indb, likeLETS_ENCRYPT_ENV,ENTRYPOINT_CONF_VERSION, ... Same behaviour for my outline deployment. Is this a bug?Anyway, will just add it.
These are injected in via
abraAFAIR. This supportskadabrabeing able to restart deployments because the env vars are attached viaabra. This was mentioned in https://docs.coopcloud.tech/abra/upgrade/#06x-beta-07x-betaThanks so much for this change! ♥
Yes, in my experience variables which only appear in configs don't need to be added in
compose.yml. Probably no harm in them being there though.Best solution to this I can think of is to use the golang
orconstruction to provide a default, e.g. https://git.coopcloud.tech/coop-cloud/matrix-synapse/src/branch/main/homeserver.yaml.tmpl#L41