There is also a default.yml that probably should be shipped in the recipe.
Yes! I wonder how this relates to #16; which files should we include as docker configs directly, which should be "initial deploy only" configs (e.g. production-initial.yml which is only copied to production.yml if it doesn't exist), and which should be entirely operator-managed 🤔
> There is also a `default.yml` that probably should be shipped in the recipe.
Yes! I wonder how this relates to #16; which files should we include as docker configs directly, which should be "initial deploy only" configs (e.g. `production-initial.yml` which is only copied to `production.yml` if it doesn't exist), and which should be entirely operator-managed 🤔
Related: https://docs.joinpeertube.org/maintain/configuration#peertube-configuration
Not exactly applicable but what I did with the beast that is `matrix-synapse` is just go through the base config for each update and decide if the new config deserves to be Packaged In The Recipe By Default ™️ and otherwise, I left it to the default settings: https://git.coopcloud.tech/coop-cloud/matrix-synapse/src/branch/main/homeserver.yaml.tmpl
@3wordchant and me looked at the issue in a bit more detail and for now we tell people to manually copy the default.yml for every release in to their config volume. That is because the local production.yml often needs manual editing as well, depending on your local circumstances.
Eventually, it would be good to track and ship those default.yml though.
@3wordchant and me looked at the issue in a bit more detail and for now we tell people to manually copy the `default.yml` for every release in to their config volume. That is because the local `production.yml` often needs manual editing as well, depending on your local circumstances.
Eventually, it would be good to track and ship those `default.yml` though.
Runs it (with some pleasant options?) between /config/default.yml (old) and /app/config/default.yml (new)
Then either offers to copy the new default.yml into /config, or a separate command to do that.
@rscmbbng wild idea: abra command (defined in `abra.sh` which:
1. Downloads [`dyff`](https://github.com/homeport/dyff)
2. Runs it (with some pleasant options?) between `/config/default.yml` (old) and `/app/config/default.yml` (new)
Then either offers to copy the new `default.yml` into `/config`, or a separate command to do that.
The entire PeerTube configuration can be set using environment variables.
Keep in mind that environment variable configuration keys override web admin configuration
Which means future recipe versions could be more tailored towards integrating with object storage recipes etc
Also I noticed this change in the [docker release notes](https://github.com/Chocobozzz/PeerTube/releases/tag/v8.2.0):
> The entire PeerTube configuration can be set using environment variables.
> Keep in mind that environment variable configuration keys override web admin configuration
Which means future recipe versions could be more tailored towards integrating with object storage recipes etc
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.
The upstream config file has had a LOT of additions https://github.com/Chocobozzz/PeerTube/blob/develop/config/production.yaml.example
CC @rscmbbng
There is also a
default.ymlthat probably should be shipped in the recipe.Yes! I wonder how this relates to #16; which files should we include as docker configs directly, which should be "initial deploy only" configs (e.g.
production-initial.ymlwhich is only copied toproduction.ymlif it doesn't exist), and which should be entirely operator-managed 🤔Related: https://docs.joinpeertube.org/maintain/configuration#peertube-configuration
Not exactly applicable but what I did with the beast that is
matrix-synapseis just go through the base config for each update and decide if the new config deserves to be Packaged In The Recipe By Default ™️ and otherwise, I left it to the default settings: https://git.coopcloud.tech/coop-cloud/matrix-synapse/src/branch/main/homeserver.yaml.tmpl@3wordchant and me looked at the issue in a bit more detail and for now we tell people to manually copy the
default.ymlfor every release in to their config volume. That is because the localproduction.ymloften needs manual editing as well, depending on your local circumstances.Eventually, it would be good to track and ship those
default.ymlthough.@rscmbbng wild idea: abra command (defined in
abra.shwhich:dyff/config/default.yml(old) and/app/config/default.yml(new)Then either offers to copy the new
default.ymlinto/config, or a separate command to do that.Also I noticed this change in the docker release notes:
Which means future recipe versions could be more tailored towards integrating with object storage recipes etc