add refs/tags/* permission #6243

New Issue

GiteaMirror · 2025-11-02T06:49:38-06:00

GiteaMirror commented

2025-11-02 06:49:38 -06:00

Originally created by @hilariocoelho on GitHub (Nov 2, 2020).

Description

At the current Gitea's version any user with repository "write" permission can create and push a new tag. Gitea should add more granularity for permissions configuration so I can specify if users/teams have commit/tag push permissions, tag/branch delete permissions...

Since we are using tag event to trigger release CI pipelines, anyone who can commit code to a repository can also create a new tag which means create a new repository release.

Github, GitLab, Bitbucket, Gerrit... all those git systems allow to remove repo tag permission to certain users/teams-

Gitea version (or commit ref): v1.12.5

Originally created by @hilariocoelho on GitHub (Nov 2, 2020). ## Description At the current Gitea's version any user with repository "write" permission can create and push a new tag. Gitea should add more granularity for permissions configuration so I can specify if users/teams have commit/tag push permissions, tag/branch delete permissions... Since we are using tag event to trigger release CI pipelines, anyone who can commit code to a repository can also create a new tag which means create a new repository release. Github, GitLab, Bitbucket, Gerrit... all those git systems allow to remove repo tag permission to certain users/teams- - Gitea version (or commit ref): v1.12.5

GiteaMirror added the type/proposal label 2025-11-02 06:49:38 -06:00

GiteaMirror closed this issue

2025-11-02 06:49:38 -06:00

GiteaMirror commented

2025-11-02 06:49:39 -06:00

@hilariocoelho commented on GitHub (Nov 26, 2020):

This is kinda related to #12293.

I would like to limit merges to master with "Merge pull request" options and "Squash and merge" to any other branch but release/*/release-*. If I could also forbid contributors to create tag I could have a perfect GitFlow model implemented with CI/CD pipelines for all development and delivery lifecycle where all commits of a feature/fix would be squashed into one commit only and then a batch of features/fixes would be simply merged to master or release branch. This way I could have an auto generated changelog for each release containing the name (and link) of all merged PRs.

Every release is associated to a git tag and the CI/CD pipeline would create the tag on every push event to master or release branches. Then I would have a pipeline triggered by the tag event that would create the release and deploy my product into a given environment.

In order to have such a model implemented I think these would be the required changes:

Define merging options per branch (or at least the default merge option);
"Developers" team would only be able to push commits to any branch but release/*/release-*;
"Project Admins" team would be able to push commits to release/*/release-* branches;
No one can push commits to master or develop branches.
No one but "CI/CD" user/team would have permissions to create a git tag

@hilariocoelho commented on GitHub (Nov 26, 2020): This is kinda related to #12293. I would like to limit merges to master with "Merge pull request" options and "Squash and merge" to any other branch but `release/*`/`release-*`. If I could also forbid contributors to create tag I could have a perfect GitFlow model implemented with CI/CD pipelines for all development and delivery lifecycle where all commits of a feature/fix would be squashed into one commit only and then a batch of features/fixes would be simply merged to `master` or `release` branch. This way I could have an auto generated changelog for each release containing the name (and link) of all merged PRs. Every release is associated to a git tag and the CI/CD pipeline would create the tag on every `push` event to master or release branches. Then I would have a pipeline triggered by the `tag` event that would create the release and deploy my product into a given environment. In order to have such a model implemented I think these would be the required changes: - Define merging options per branch (or at least the default merge option); - "Developers" team would only be able to push commits to any branch but `release/*`/`release-*`; - "Project Admins" team would be able to push commits to `release/*`/`release-*` branches; - No one can push commits to `master` or `develop` branches. - No one but "CI/CD" user/team would have permissions to create a git tag

GiteaMirror commented

2025-11-02 06:49:39 -06:00

@charlesmorin commented on GitHub (Oct 25, 2021):

+1

@charlesmorin commented on GitHub (Oct 25, 2021): +1

GiteaMirror commented

2025-11-02 06:49:39 -06:00

@delvh commented on GitHub (Aug 23, 2022):

Should have been implemented by #15629 over a year ago.

@delvh commented on GitHub (Aug 23, 2022): Should have been implemented by #15629 over a year ago.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#6243