Fix regression for creating repositories in root-based containers #172
Labels
No Label
has
backport
in progress
invalid
kind
breaking
kind
bug
kind
build
kind
dependency
kind
deployment
kind
docs
kind
enhancement
kind
feature
kind
lint
kind
proposal
kind
question
kind
refactor
kind
security
kind
testing
kind
translation
kind
ui
need
backport
priority
critical
priority
low
priority
maybe
priority
medium
reviewed
duplicate
reviewed
invalid
reviewed
wontfix
skip-changelog
status
blocked
status
needs-feedback
status
needs-reviews
status
wip
upstream
gitea
upstream
other
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/helm-chart#172
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "justusbunsi/helm-chart:issue/171-repo-api"
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?
Due to #160 it was no longer possible to create repositories in root-based containers. This was caused by the missing
/tmp/gitea
directory in that image. It was dynamically created by Gitea internal functionality with less privileges than necessary.Explicitly creating the directory and set proper permissions fix this.
Fixes: #171
@luhahn Does the increase of Chart.yaml app version does the trick to indicate the correct version for the chart? As mentioned in issue #171, this was incorrect due to the previous PR #160.
Yes, missed it in your PR, sorry :D.
@ -24,0 +25,4 @@
mkdir -p "${GITEA_TEMP}"
chown 1000:1000 "${GITEA_TEMP}"
chmod ug+rwx "${GITEA_TEMP}"
Since we need this only on the root image, should we rebase your branch on my
Pr #165 so we can include your checks into the rootless if condition?
Something like this:
It wouldn't cause any issues when running for both image variants. In the root image this is necessary. For the rootless image this would fix permissions in case they are too restrictive. At least that's what I've tested so far.
Actually, I don't think that the
chown 1000:1000 /data
is necessary since thefsGroup
already declares the group as 1000. It should work without the chown-in.I leave it up to you to decide whether I should rebase or not. ?
Will update the readme.
Yea, I agree, it SHOULD :D. But it doesn't we had an issue (#135) and i could only resolve it by applying the chown.
However, i just tested your changes and yes, the chown doesn't cause any error messages :)
You'll still need to update your branch with the latest master, so we can merge
Please also add the image version into the readmes value description
Seems to be already done in
031b58c90e
.right, missed that one, sorry
109b89ec5f
to9a7f67b406
Branch up-to-date. Hopefully these changes do not introduce other side-effects. ?