github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-07-11 04:23:04 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

[Proposal] Support configuring permissions of automatic tokens of Actions jobs #10823

New Issue
Open
opened 2025-11-02 09:19:10 -06:00 by GiteaMirror · 16 comments
GiteaMirror commented 2025-11-02 09:19:10 -06:00
Owner
Copy Link

Originally created by @wolfogre on GitHub (May 10, 2023).

Background

When a Gitea Actions job has been picked by a runner, a automatically generated token will be given to the runner at the same time. This is a short-lived token that immediately becomes invalid when the job is completed.

The token can be used to access the repository to which it belongs, such as cloning code via actions/checkout. You can use it with gitea.token, secrets.GITEA_TOKEN, or github.token, secrets.GITHUB_TOKEN to ensure compatibility.

However, the permissions of this token are not really clear to everyone. IIRC, currently it can:

  • Read the code of the repository to which it belongs, and write the code if the job is not triggered by a pull request from a forked repository.
  • Read resources of public repositories or submit issues to them as a signed-in user.

Sometimes it’s not convenient, for example, you cannot use this token to write packages, so it’s annoying when releasing.

Some PRs try to add more permissions to this token, but I’m cautious about this, see:

My reason is that, in the absence of a means to configure permissions for automatic tokens, we need to be cautious about granting more permissions by default, even if it may cause some inconvenience, as it could bring about security risks. I would say it's "inconvenient", not "impossible", because you can always provide an access token or deploy key as a secret to do anything you want, just like using an external CI/CD system.

However, Gitea Actions isn't an external CI/CD system, so it could do better. The first thing that should be done is supporting the configuration of permissions for automatic tokens. It's not a simple thing, but the good news is that we can refer to GitHub.

How does a GitHub do

On GitHub, you can choose between permissive mode or restricted mode on the settings page of a repository or organization.

The two modes have different default permissions, see Automatic token authentication. This is a coarse-grained setting. Sometimes it's not enough.

So you can specify permissions for specific workflows or jobs in the workflow files. See:

However, you can overwrite the default permissions of the mode in workflow files by this, instead of being limited by them. That means even if the repository is in restricted mode, it is still possible to obtain higher permission in its workflow files. In my opinion, Gitea is not suitable for this design, because Gitea doesn't support code owners yet, that means as long as someone has permission to write code, they can access anything via Actions by obtaining higher permission in workflow files.

Unfortunately, I noticed that the permission control only applies to accessing the same repository, not to accessing other repositories in the same organization. Therefore, the token cannot access other private repositories within the same organization. See Cloning private github repository within organisation in actions - Stackoverflow.

I think Gitea needs to do more to support it.

Solution

Here is my proposal, which draws heavily from GitHub but has been adjusted for Gitea.

Support configuring the permissions

Support configuring the maximum access on the settings page of a repository or organization Something like (this is a fake sketch, I haven't done anything yet):

image

You can still specify permissions for specific workflows or jobs in the workflow files. However, you cannot obtain higher permissions than the configuration on setting page. You may have noticed that the units in Gitea are not exactly the same as the scopes in GitHub, so some adjustments are needed.

If the job is triggered by a pull request from a forked repository, the maximum access will always be lower than read.

Support configuring access between repositories

On the settings page of an organization, users can configure which repositories can be accessed by Actions from other repositories within the same organization.

image

Private packages can be accessed by Actions only when they have been linked to repositories

As packages belong to the organization level, it is difficult to determine what to do when repository X tries to write package Y. So let's make things simpler, repository X can write package Y only if:

  • Package Y has been linked to repository X, and write permission to packages has been granted to repository X.
  • Package Y has been linked to repository Z, but repository Z has been set to be accessible by other repos within the same organization, including repository X. Additionally, write permission to packages has been granted to repository X.

An access token or deploy key as a secret is recommended for more complex situations

Such as:

  • A organization has repositories X, Y and Z, I want X to be accessed by Y, but not Z; And Y can be accessed by Z, but not A.
  • I want create/delete repositories in Actions workflows.
  • I am the only user of my Gitea instance, I want the workflows can do anything without limits.
Originally created by @wolfogre on GitHub (May 10, 2023). ## Background When a Gitea Actions job has been picked by a runner, a automatically generated token will be given to the runner at the same time. This is a short-lived token that immediately becomes invalid when the job is completed. The token can be used to access the repository to which it belongs, such as cloning code via `actions/checkout`. You can use it with `gitea.token`, `secrets.GITEA_TOKEN`, or `github.token`, `secrets.GITHUB_TOKEN` to ensure compatibility. However, the permissions of this token are not really clear to everyone. IIRC, currently it can: - Read the code of the repository to which it belongs, and write the code if the job is not triggered by a pull request from a forked repository. - Read resources of public repositories or submit issues to them as a signed-in user. Sometimes it’s not convenient, for example, you cannot use this token to write packages, so it’s annoying when releasing. Some PRs try to add more permissions to this token, but I’m cautious about this, see: - https://github.com/go-gitea/gitea/pull/23729#issuecomment-1492811800 - https://github.com/go-gitea/gitea/pull/24554#issuecomment-1537040811 My reason is that, in the absence of a means to configure permissions for automatic tokens, we need to be cautious about granting more permissions by default, even if it may cause some inconvenience, as it could bring about security risks. I would say it's "inconvenient", not "impossible", because you can always provide an access token or deploy key as a secret to do anything you want, just like using an external CI/CD system. However, Gitea Actions isn't an external CI/CD system, so it could do better. The first thing that should be done is supporting the configuration of permissions for automatic tokens. It's not a simple thing, but the good news is that we can refer to GitHub. ### How does a GitHub do On GitHub, you can choose between permissive mode or restricted mode on the settings page of a repository or organization. The two modes have different default permissions, see [Automatic token authentication](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token). This is a coarse-grained setting. Sometimes it's not enough. So you can specify permissions for specific workflows or jobs in the workflow files. See: - [`permissions`](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions) - [`jobs.<job_id>.permissions`](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions) However, you can overwrite the default permissions of the mode in workflow files by this, instead of being limited by them. That means **even if the repository is in restricted mode, it is still possible to obtain higher permission in its workflow files**. In my opinion, Gitea is not suitable for this design, because Gitea doesn't support [code owners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) yet, that means as long as someone has permission to write code, they can access anything via Actions by obtaining higher permission in workflow files. Unfortunately, I noticed that the permission control only applies to accessing the same repository, not to accessing other repositories in the same organization. Therefore, the token cannot access other private repositories within the same organization. See [Cloning private github repository within organisation in actions - Stackoverflow](https://stackoverflow.com/questions/57612428/cloning-private-github-repository-within-organisation-in-actions). I think Gitea needs to do more to support it. ## Solution Here is my proposal, which draws heavily from GitHub but has been adjusted for Gitea. ### Support configuring the permissions Support configuring the maximum access on the settings page of a repository or organization Something like (this is a fake sketch, I haven't done anything yet): ![image](https://github.com/go-gitea/gitea/assets/9418365/dee17aa3-1102-4b82-8565-d5a8d693a240) You can still specify permissions for specific workflows or jobs in the workflow files. However, **you cannot obtain higher permissions than the configuration on setting page**. You may have noticed that the units in Gitea are not exactly the same as the scopes in GitHub, so some adjustments are needed. If the job is triggered by a pull request from a forked repository, the maximum access will always be lower than read. ### Support configuring access between repositories On the settings page of an organization, users can configure which repositories can be accessed by Actions from other repositories within the same organization. ![image](https://github.com/go-gitea/gitea/assets/9418365/dd35c9a3-be50-413a-a6a7-e72fbd812a71) ### Private packages can be accessed by Actions only when they have been linked to repositories As packages belong to the organization level, it is difficult to determine what to do when repository X tries to write package Y. So let's make things simpler, repository X can write package Y only if: - Package Y has been linked to repository X, and write permission to packages has been granted to repository X. - Package Y has been linked to repository Z, but repository Z has been set to be accessible by other repos within the same organization, including repository X. Additionally, write permission to packages has been granted to repository X. ### An access token or deploy key as a secret is recommended for more complex situations Such as: - A organization has repositories X, Y and Z, I want X to be accessed by Y, but not Z; And Y can be accessed by Z, but not A. - I want create/delete repositories in Actions workflows. - I am the only user of my Gitea instance, I want the workflows can do anything without limits.
GiteaMirror added the $20💎 Bountytopic/gitea-actionstype/proposal labels 2025-11-02 09:19:10 -06:00
GiteaMirror commented 2025-11-02 09:19:11 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (May 10, 2023):

Hmm, having it in-action sure would be convenient because then this permission config would be easily ported to new repos and possibly GH actions without fiddling with the UI. Why exactly do you think such config is unsuitable?

BTW, on GH actions it's possible to obtain write access to the repo by using a write-level deploy key while checking out. I think this method was mostly superceded by the permissions option now, but we should be aware that this "escape hatch" exists.

      - uses: actions/checkout@v3
        with:
          ssh-key: ${{ secrets.DEPLOY_KEY }}
@silverwind commented on GitHub (May 10, 2023): Hmm, having it in-action sure would be convenient because then this permission config would be easily ported to new repos and possibly GH actions without fiddling with the UI. Why exactly do you think such config is unsuitable? BTW, on GH actions it's possible to obtain write access to the repo by using a write-level deploy key while checking out. I think this method was mostly superceded by the `permissions` option now, but we should be aware that this "escape hatch" exists. ```yaml - uses: actions/checkout@v3 with: ssh-key: ${{ secrets.DEPLOY_KEY }} ```
GiteaMirror commented 2025-11-02 09:19:11 -06:00
Author
Owner
Copy Link

@wolfogre commented on GitHub (May 11, 2023):

Why exactly do you think such config is unsuitable?

I'm sorry I didn't make myself clear, please check the latest version of the description.

image image

BTW, on GH actions it's possible to obtain write access to the repo by using a write-level deploy key while checking out.

Yes, and you can do that on Gitea Actions too.

I think this method was mostly superceded by the permissions option now, but we should be aware that this "escape hatch" exists.

I agree with you, just like I said, "An access token or deploy key as a secret is recommended for more complex situations".

@wolfogre commented on GitHub (May 11, 2023): > Why exactly do you think such config is unsuitable? I'm sorry I didn't make myself clear, please check the latest version of the description. <img width="808" alt="image" src="https://github.com/go-gitea/gitea/assets/9418365/2cb5608d-ef8a-4970-bcfd-a68aaccd5a97"> <img width="820" alt="image" src="https://github.com/go-gitea/gitea/assets/9418365/c6d037b5-eedc-4958-8ad2-397cb02d14ed"> > BTW, on GH actions it's possible to obtain write access to the repo by using a write-level deploy key while checking out. Yes, and you can do that on Gitea Actions too. > I think this method was mostly superceded by the `permissions` option now, but we should be aware that this "escape hatch" exists. I agree with you, just like I said, "An access token or deploy key as a secret is recommended for more complex situations".
GiteaMirror commented 2025-11-02 09:19:11 -06:00
Author
Owner
Copy Link

@Renari commented on GitHub (Nov 16, 2023):

I encountered this today and thought this token feature didn't even exist because it was unable to push releases, my work around atm is to create an application token and to reassign GITEA_TOKEN to the application token:

e.g.

env:
  GITEA_TOKEN: ${{ secrets.APPLICATION_TOKEN }}

This is less than ideal though since it binds the repo permissions to that user account, for my use case a single developer on this project this is fine, but less than ideal since in a team scenario it's binding functionality to an individual user account.

@Renari commented on GitHub (Nov 16, 2023): I encountered this today and thought this token feature didn't even exist because it was unable to push releases, my work around atm is to create an application token and to reassign `GITEA_TOKEN` to the application token: e.g. ```yaml env: GITEA_TOKEN: ${{ secrets.APPLICATION_TOKEN }} ``` This is less than ideal though since it binds the repo permissions to that user account, for my use case a single developer on this project this is fine, but less than ideal since in a team scenario it's binding functionality to an individual user account.
GiteaMirror commented 2025-11-02 09:19:11 -06:00
Author
Owner
Copy Link

@Frankkkkk commented on GitHub (Dec 21, 2024):

If someone is interested in implementing this feature (also explained here), I will gladly pay them 200€ or gift it to a charity of their choice.

@Frankkkkk commented on GitHub (Dec 21, 2024): If someone is interested in implementing this feature (also explained [here](https://codeberg.org/forgejo/forgejo/issues/3571)), I will gladly pay them 200€ or gift it to a charity of their choice.
GiteaMirror commented 2025-11-02 09:19:11 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 21, 2024):

This issue suggests there is a permission in the workflow YAML files which is different from your proposal. Which one do you prefer?

In fact, I think this issue are blocked by some other tasks. One of them is the workflow YAML parser should be replaced by actionslint. The one we are using from act_runner doesn't work well for some syntaxes including permissions.

BTW: We support bounty via https://console.algora.io/org/go-gitea/bounties but we can't guarantee the pull request from bounty hunter will be accepted.

@lunny commented on GitHub (Dec 21, 2024): This issue suggests there is a `permission` in the workflow YAML files which is different from your proposal. Which one do you prefer? In fact, I think this issue are blocked by some other tasks. One of them is the workflow YAML parser should be replaced by actionslint. The one we are using from act_runner doesn't work well for some syntaxes including `permissions`. BTW: We support bounty via https://console.algora.io/org/go-gitea/bounties but we can't guarantee the pull request from bounty hunter will be accepted.
GiteaMirror commented 2025-11-02 09:19:11 -06:00
Author
Owner
Copy Link

@Frankkkkk commented on GitHub (Dec 21, 2024):

Unless I'm mistaken, the permission way is the current Github one, but @wolfogre 's suggestion is a bit different (GUI based), and quite good (way better than mine) TBH.

Thanks for the algora tip; I'll try it out tomorrow :)

@Frankkkkk commented on GitHub (Dec 21, 2024): Unless I'm mistaken, the `permission` way is the current Github one, but @wolfogre 's suggestion is a bit different (GUI based), and quite good (way better than mine) TBH. Thanks for the algora tip; I'll try it out tomorrow :)
GiteaMirror commented 2025-11-02 09:19:12 -06:00
Author
Owner
Copy Link

@algora-pbc[bot] commented on GitHub (Dec 21, 2024):

💎 $200 bounty • Frank Villaro-Dixon

💎 $20 bounty • jibeddari

Steps to solve:

  1. Start working: Comment /attempt #24635 with your implementation plan
  2. Submit work: Create a pull request including /claim #24635 in the PR body to claim the bounty
  3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to go-gitea/gitea!

Add a bounty • Share on socials

Attempt Started (GMT+0) Solution
🔴 @Mayank77maruti Feb 14, 2025, 8:20:52 AM WIP
@algora-pbc[bot] commented on GitHub (Dec 21, 2024): ## 💎 $200 bounty [• Frank Villaro-Dixon](https://console.algora.io/org/Frankkkkk) ## 💎 $20 bounty [• jibeddari](https://console.algora.io/org/jibeddari) ### Steps to solve: 1. **Start working**: Comment `/attempt #24635` with your implementation plan 2. **Submit work**: Create a pull request including `/claim #24635` in the PR body to claim the bounty 3. **Receive payment**: 100% of the bounty is received 2-5 days post-reward. [Make sure you are eligible for payouts](https://docs.algora.io/bounties/payments#supported-countries-regions) Thank you for contributing to go-gitea/gitea! **[Add a bounty](https://console.algora.io/org/Frankkkkk/bounties/community?fund=go-gitea%2Fgitea%2324635)** • **[Share on socials](https://twitter.com/intent/tweet?text=%24220+bounty%21+%F0%9F%92%8E+https%3A%2F%2Fgithub.com%2Fgo-gitea%2Fgitea%2Fissues%2F24635&related=algoraio)** <table> <thead> <tr> <th>Attempt</th> <th>Started (GMT+0)</th> <th>Solution</th> </tr> </thead> <tbody> <tr> <td>🔴 @Mayank77maruti</td> <td>Feb 14, 2025, 8:20:52 AM</td> <td>WIP</td> </tr> </tbody> </table>
GiteaMirror commented 2025-11-02 09:19:12 -06:00
Author
Owner
Copy Link

@Mayank77maruti commented on GitHub (Feb 14, 2025):

/attempt #24635

Algora profile Completed bounties Tech Active attempts Options
@Mayank77maruti 1 bounty from 1 project
CSS, Python,
JavaScript & more
Cancel attempt
@Mayank77maruti commented on GitHub (Feb 14, 2025): /attempt #24635 <div id="algora-attempt" /> | [Algora profile](https://console.algora.io/@/Mayank77maruti) | Completed bounties | Tech | Active attempts | Options | | --- | --- | --- | --- | --- | | @Mayank77maruti | 1 bounty from 1 project | <div align="center">CSS, Python, <br />JavaScript & more</div> | <div align="center"></div> | [Cancel attempt](https://console.algora.io/api/bounties/cm624qx8o0008l403092kveb4/cancel-attempt) |
GiteaMirror commented 2025-11-02 09:19:12 -06:00
Author
Owner
Copy Link

@lolen commented on GitHub (Apr 3, 2025):

@Mayank77maruti any updates on the task?

@lolen commented on GitHub (Apr 3, 2025): @Mayank77maruti any updates on the task?
GiteaMirror commented 2025-11-02 09:19:13 -06:00
Author
Owner
Copy Link

@Renari commented on GitHub (Apr 3, 2025):

@lolen I'm not sure they're actually working on this, since they have put in an attempt on every bounty on this repo.

@Renari commented on GitHub (Apr 3, 2025): @lolen I'm not sure they're actually working on this, since they have put in an attempt on every bounty on this repo.
GiteaMirror commented 2025-11-02 09:19:13 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Apr 3, 2025):

https://gitea.com/gitea/act/pulls/133 is merged

@lunny commented on GitHub (Apr 3, 2025): https://gitea.com/gitea/act/pulls/133 is merged
GiteaMirror commented 2025-11-02 09:19:13 -06:00
Author
Owner
Copy Link

@jayantpranjal0 commented on GitHub (Jul 2, 2025):

https://gitea.com/gitea/act/pulls/133 is merged

@lunny is this issue supposed to be closed from the PR. I see bounties for this issue, would like to work on this if has not already been solved

@jayantpranjal0 commented on GitHub (Jul 2, 2025): > https://gitea.com/gitea/act/pulls/133 is merged @lunny is this issue supposed to be closed from the PR. I see bounties for this issue, would like to work on this if has not already been solved
GiteaMirror commented 2025-11-02 09:19:14 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jul 2, 2025):

I think https://gitea.com/gitea/act/pulls/133 just a necessary step to resolve this issue. Pull request is welcome. This is not an easy issue. You can have more discussion here.

@lunny commented on GitHub (Jul 2, 2025): I think https://gitea.com/gitea/act/pulls/133 just a necessary step to resolve this issue. Pull request is welcome. This is not an easy issue. You can have more discussion here.
GiteaMirror commented 2025-11-02 09:19:14 -06:00
Author
Owner
Copy Link

@algora-pbc[bot] commented on GitHub (Aug 29, 2025):

💎 $200 bounty • Michael Aldridge

💎 $20 bounty • jibeddari

💎 $200 bounty • Frank

Steps to solve:

  1. Start working: Comment /attempt #24635 with your implementation plan
  2. Submit work: Create a pull request including /claim #24635 in the PR body to claim the bounty
  3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

❗ Important guidelines:

  • To claim a bounty, you need to provide a short demo video of your changes in your pull request
  • If anything is unclear, ask for clarification before starting as this will help avoid potential rework
  • Low quality AI PRs will not receive review and will be closed
  • Do not ask to be assigned unless you've contributed before

Thank you for contributing to go-gitea/gitea!

Attempt Started (UTC) Solution Actions
🟢 @Mayank77maruti Feb 14, 2025, 08:20:52 AM WIP
@algora-pbc[bot] commented on GitHub (Aug 29, 2025): ## 💎 $200 bounty [• Michael Aldridge](https://algora.io/the-maldridge) ## 💎 $20 bounty [• jibeddari](https://algora.io/jibeddari) ## 💎 $200 bounty [• Frank](https://algora.io/Frankkkkk) ### Steps to solve: 1. **Start working**: Comment `/attempt #24635` with your implementation plan 2. **Submit work**: Create a pull request including `/claim #24635` in the PR body to claim the bounty 3. **Receive payment**: 100% of the bounty is received 2-5 days post-reward. [Make sure you are eligible for payouts](https://algora.io/docs/payments#supported-countries-regions) ### ❗ Important guidelines: - To claim a bounty, you need to **provide a short demo video** of your changes in your pull request - If anything is unclear, **ask for clarification** before starting as this will help avoid potential rework - Low quality AI PRs will not receive review and will be closed - Do not ask to be assigned unless you've contributed before Thank you for contributing to go-gitea/gitea! | Attempt | Started (UTC) | Solution | Actions | | --- | --- | --- | --- | | 🟢 @Mayank77maruti | Feb 14, 2025, 08:20:52 AM | WIP | |
GiteaMirror commented 2025-11-02 09:19:14 -06:00
Author
Owner
Copy Link

@algora-pbc[bot] commented on GitHub (Oct 1, 2025):

💎 $20 bounty • Markus Fenes

💎 $200 bounty • Michael Aldridge

💎 $20 bounty • jibeddari

💎 $200 bounty • Frank

Steps to solve:

  1. Start working: Comment /attempt #24635 with your implementation plan
  2. Submit work: Create a pull request including /claim #24635 in the PR body to claim the bounty
  3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

❗ Important guidelines:

  • To claim a bounty, you need to provide a short demo video of your changes in your pull request
  • If anything is unclear, ask for clarification before starting as this will help avoid potential rework
  • Low quality AI PRs will not receive review and will be closed
  • Do not ask to be assigned unless you've contributed before

Thank you for contributing to go-gitea/gitea!

Attempt Started (UTC) Solution Actions
🟢 @Mayank77maruti Feb 14, 2025, 08:20:52 AM WIP
@algora-pbc[bot] commented on GitHub (Oct 1, 2025): ## 💎 $20 bounty [• Markus Fenes](https://algora.io/mafen) ## 💎 $200 bounty [• Michael Aldridge](https://algora.io/the-maldridge) ## 💎 $20 bounty [• jibeddari](https://algora.io/jibeddari) ## 💎 $200 bounty [• Frank](https://algora.io/Frankkkkk) ### Steps to solve: 1. **Start working**: Comment `/attempt #24635` with your implementation plan 2. **Submit work**: Create a pull request including `/claim #24635` in the PR body to claim the bounty 3. **Receive payment**: 100% of the bounty is received 2-5 days post-reward. [Make sure you are eligible for payouts](https://algora.io/docs/payments#supported-countries-regions) ### ❗ Important guidelines: - To claim a bounty, you need to **provide a short demo video** of your changes in your pull request - If anything is unclear, **ask for clarification** before starting as this will help avoid potential rework - Low quality AI PRs will not receive review and will be closed - Do not ask to be assigned unless you've contributed before Thank you for contributing to go-gitea/gitea! | Attempt | Started (UTC) | Solution | Actions | | --- | --- | --- | --- | | 🟢 @Mayank77maruti | Feb 14, 2025, 08:20:52 AM | WIP | |
GiteaMirror commented 2025-11-02 09:19:15 -06:00
Author
Owner
Copy Link

@ChristopherHX commented on GitHub (Oct 20, 2025):

Proof of Concept job level permission key: https://github.com/ChristopherHX/gitea/tree/workflow-permissions

Missing

  • Repo/Org/User Settings and UI
  • Global workflow permissions

Just for reference to continue later.

@ChristopherHX commented on GitHub (Oct 20, 2025): Proof of Concept job level permission key: https://github.com/ChristopherHX/gitea/tree/workflow-permissions Missing - Repo/Org/User Settings and UI - Global workflow permissions --- Just for reference to continue later.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label $20 💎 Bounty topic/gitea-actions type/proposal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#10823
Delete Branch "%!s()"

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?