Right now I'm not sure if that is a good idea for us. Our app.ini config is 92 lines, it seems like a lot of environment variables. We'd have to deal with environment variables that have to stay a secret, while having an app.ini file not in version control takes care of secrets in one go
This is a new feature: https://github.com/go-gitea/gitea/blob/master/contrib/environment-to-ini/README
Right now we are copying over a generated `app.ini` file to a conf volume (https://gitea.kosmos.org/kosmos/gitea.kosmos.org/src/branch/master/kubernetes/gitea-server.yaml#L18)
Right now I'm not sure if that is a good idea for us. Our `app.ini` config is 92 lines, it seems like a lot of environment variables. We'd have to deal with environment variables that have to stay a secret, while having an `app.ini` file not in version control takes care of secrets in one go
greg
added the question label 2020-02-14 16:00:08 +00:00
We’d have to deal with environment variables that have to stay a secret
How many passwords to we really have in the config? It can't be that many.
while having an app.ini file not in version control takes care of secrets in one go
Where does it come from then? This way also takes care of the config being intransparent.
> We’d have to deal with environment variables that have to stay a secret
How many passwords to we really have in the config? It can't be that many.
> while having an app.ini file not in version control takes care of secrets in one go
Where does it come from then? This way also takes care of the config being intransparent.
How many passwords to we really have in the config? It can’t be that many.
That's just 4, database & mailer password, internal token and secret key
Where does it come from then? This way also takes care of the config being intransparent.
We use a script to get it from the conf volume, where it can then be edited and sent to the volume with another script
> How many passwords to we really have in the config? It can’t be that many.
That's just 4, database & mailer password, internal token and secret key
> Where does it come from then? This way also takes care of the config being intransparent.
We use a script to get it from the conf volume, where it can then be edited and sent to the volume with another script
raucao
added this to the Production readiness milestone 2020-02-15 16:07:52 +00:00
However, if you want to move this repo's issues to the Chef repo, then please do so! It would probably make sense to introduce service labels for that repo's issues then (e.g. service:gitea or similar).
> Meta repo for gitea.kosmos.org operation, issues, suggestions, and feedback.
How is it not relevant anymore? The issues still seem very relevant to me, which is why I'm triaging them:
https://gitea.kosmos.org/kosmos/gitea.kosmos.org/issues
However, if you want to move this repo's issues to the Chef repo, then please do so! It would probably make sense to introduce service labels for that repo's issues then (e.g. `service:gitea` or similar).
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.
This is a new feature: https://github.com/go-gitea/gitea/blob/master/contrib/environment-to-ini/README
Right now we are copying over a generated
app.inifile to a conf volume (https://gitea.kosmos.org/kosmos/gitea.kosmos.org/src/branch/master/kubernetes/gitea-server.yaml#L18)Right now I'm not sure if that is a good idea for us. Our
app.iniconfig is 92 lines, it seems like a lot of environment variables. We'd have to deal with environment variables that have to stay a secret, while having anapp.inifile not in version control takes care of secrets in one goHow many passwords to we really have in the config? It can't be that many.
Where does it come from then? This way also takes care of the config being intransparent.
That's just 4, database & mailer password, internal token and secret key
We use a script to get it from the conf volume, where it can then be edited and sent to the volume with another script
@greg Is this still relevant, since we don't use kubernetes anymore?
This entire repo isn't relevant and can be deleted
How is it not relevant anymore? The issues still seem very relevant to me, which is why I'm triaging them:
https://gitea.kosmos.org/kosmos/gitea.kosmos.org/issues
However, if you want to move this repo's issues to the Chef repo, then please do so! It would probably make sense to introduce service labels for that repo's issues then (e.g.
service:giteaor similar).