Generate the ini config file from environment variables? #44
Labels
No Label
bug
dev environment
docs
duplicate
enhancement
feature
idea
invalid
kredits-1
kredits-2
kredits-3
ops
question
security
ui/ux
wontfix
bug
design
dev environment
docs
duplicate
enhancement
feature
good first issue
idea
invalid
kredits-1
kredits-2
kredits-3
on hold
ops
question
release
major
release
minor
release
patch
security
ui/ux
wontfix
No Milestone
No Assignees
2 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: kosmos/gitea.kosmos.org#44
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 anapp.ini
file 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:gitea
or similar).