Add project workflow feature so users can define how to execute steps when project related events fired by lunny · Pull Request #30205 · go-gitea/gitea

lunny · 2024-03-31T04:03:30Z

This PR introduces project workflows, allowing users to configure event-based automations directly from the UI.
Users can define filters and actions for each workflow event, and duplicate existing events when needed.

Concepts

Every workflow is composed of event, filters, and actions.

Event - An Event defines when a workflow should be triggered. It represents specific activities such as an issue being opened, a pull request being merged, or a project column being changed.
Filter - A Filter refines when an event should take effect. It allows users to specify conditions like issue type, labels, or project columns to ensure actions only run in targeted scenarios.
Action - An Action defines what happens when the event and filters match. It performs operations such as adding labels, moving issues between columns, or changing the issue or pull request state.

Available Events

Currently, the following nine events are supported:

On issues/pull requests opened
On issues/pull requests closed
On issues/pull requests reopened
On issues/pull requests was added to the project
On issues/pull requests was removed to the project
On issues/pull requests' column was changed
On code changes requested
On code review approved
On pull request merged

Each event type supports its own set of filters and actions.

Available Filters

There are four types of filters that can be configured for an event:

Apply to - Specify the target type: issues only, pull requests only, or issues and pull requests.
Labels - Trigger the event only if the issue or pull request contains one or more specified labels.
Move from column - Filter events based on the original project column.
Move to column - Filter events based on the destination project column.

Available Actions

There are four types of actions that can be executed when an event is triggered:

Add labels - Automatically add one or more labels to the issue or pull request.
Remove labels - Remove one or more specified labels.
Move to column - Move the issue or pull request to a designated project column.
Issue state - Change the state by closing or reopening the issue or pull request.

Enable/Disable an event workflow

Each event workflow can be individually enabled or disabled. When disabled, the workflow will be ignored even if the event occurs. This feature is useful when you want to temporarily stop certain automated actions without deleting the workflow configuration.

Clone an event workflow

When you need multiple workflows for the same event, you can clone an existing event to create a new one with different filters and actions. This allows you to customize how the same event behaves under different conditions, making workflows more flexible and powerful.

Screen shots

View mode

Edit mode

Dark theme

Issue comments triggered by project workflow

Resolve [Feature] Add automated project board #14359
Resolve Allow kanban/project board to set labels on column switch #26704
Resolve [Feature] Kanban automation using labels #27990
Replace add/remove label on kanban column change #28745

Documentation PR https://gitea.com/gitea/docs/pulls/308

… when project related events fired

lunny · 2024-04-19T04:40:52Z

I'm now hesitate to add this feature because looks like some actions can do the same things. Like https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions and more third-party actions can do it easier.

rohrschacht · 2024-04-25T15:06:08Z

I would really like to see this merged, I am waiting for the ability to automatically set a project for a new issue via the issue template (#25028). GitHub provides this through an "org-name/BOARD_ID" syntax as announced here. I think having to set up an action for that (which would also require to set up a runner?) is quite cumbersome for such a simple feature.

silkentrance · 2024-05-31T22:13:41Z

I'm now hesitate to add this feature because looks like some actions can do the same things. Like https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions and more third-party actions can do it easier.

@lunny

I do not know, but firing up multiple containers to just set a specific label or remove a label, or even re-open or close an issue as part of the workflow seems to be overkill to me, what do you think?

thekk1 · 2024-08-01T08:20:20Z

I'm now hesitate to add this feature because looks like some actions can do the same things. Like https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions and more third-party actions can do it easier.

What's the status here now? This is quite a wanted feature.
Do you have just a feeling about this or a specific good reason?
Running multiple containers for just moving around a Issue is for sure not the best practice.

lunny · 2024-08-01T16:22:36Z

I'm now hesitate to add this feature because looks like some actions can do the same things. Like https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions and more third-party actions can do it easier.

What's the status here now? This is quite a wanted feature. Do you have just a feeling about this or a specific good reason? Running multiple containers for just moving around a Issue is for sure not the best practice.

Yes, this is a good reason to use the internal implementation rather than CI/CD. I will continue this work.

thekk1 · 2024-08-01T17:05:16Z

I'm now hesitate to add this feature because looks like some actions can do the same things. Like https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions and more third-party actions can do it easier.

What's the status here now? This is quite a wanted feature. Do you have just a feeling about this or a specific good reason? Running multiple containers for just moving around a Issue is for sure not the best practice.

Yes, this is a good reason to use the internal implementation rather than CI/CD. I will continue this work.

Great, thx for your feedback. I am really looking forward to it.

thekk1 · 2024-09-03T14:08:43Z

As far as I understand the description, this will depend on Workflows?
So Actions has to be enabled?
This would be a problem for us, because the workflows in our repos are for the environment of our customers and Actions are always disabled because they will not work in our environment.

lunny · 2024-09-03T16:57:10Z

As far as I understand the description, this will depend on Workflows? So Actions has to be enabled? This would be a problem for us, because the workflows in our repos are for the environment of our customers and Actions are always disabled because they will not work in our environment.

No. This is project workflow which is different from Actions workflow.

lunny · 2024-09-12T19:11:31Z

And what's better? Storing the workflows in the special YAML files on the default branch or storing them in the database? This is a block to prevent me from continuing the work.

thekk1 · 2024-09-12T19:20:25Z

I would purpose to store them in the database. Branches are for code changes and depending stuff but this is a projekt management feature that is specific for gitea. i.e.: If you mirror your code to an other git system like github the projekt workflows are only garbage there.

eeyrjmr · 2024-09-12T20:29:19Z

I would purpose to store them in the database. Branches are for code changes and depending stuff but this is a projekt management feature that is specific for gitea. i.e.: If you mirror your code to an other git system like github the projekt workflows are only garbage there.

but storing in the db will require some form of UI to create/edit.
Right now .gitea/* is used to store issue templates and all of that is "garbage" if you were to mirror into github since github only looks in .github thus that objection is moot.

thekk1 · 2024-09-12T21:01:31Z

but storing in the db will require some form of UI to create/edit. Right now .gitea/* is used to store issue templates and all of that is "garbage" if you were to mirror into github since github only looks in .github thus that objection is moot.

For my defence I didn't know about the templates and the storage path. In that case I would agree to that argument.

Woonhyung59 · 2024-10-11T08:19:14Z

Thank you for working on this important feature. Many users, including myself, are eagerly anticipating the addition of project workflows to Gitea. This functionality would greatly enhance project management capabilities within the platform.

lunny · 2026-02-21T05:03:30Z

services/issue/label.go

 // RemoveLabel removes a label from issue by given ID.
 func RemoveLabel(ctx context.Context, issue *issues_model.Issue, doer *user_model.User, label *issues_model.Label) error {
 	if err := db.WithTx(ctx, func(ctx context.Context) error {
-		if err := issue.LoadRepo(ctx); err != nil {


The permission has been checked outside of this function. So that the duplicated permission check could be removed.

models/issues/comment.go

web_src/js/components/projects/ProjectWorkflow.vue

templates/repo/projects/workflows.tmpl

templates/repo/issue/view_content/comments.tmpl

services/projects/workflow_notifier.go

models/issues/comment.go

templates/repo/issue/view_content/comments_authorlink.tmpl

models/issues/comment.go

models/migrations/v1_26/v326.go

Add project workflow feature so users can define how to execute steps…

64e0ba1

… when project related events fired

lunny added the type/feature Completely new functionality. Can only be merged if feature freeze is not active. label Mar 31, 2024

GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Mar 31, 2024

pull-request-size bot added the size/L label Mar 31, 2024

github-actions bot added the modifies/go Pull requests that update Go code label Mar 31, 2024

This was referenced Apr 2, 2024

[Feature] Add automated project board #14359

Open

add close issue on move flag to board and add a cron to remove closed issues from board with that flag #28800

Open

Plans for Gitea 1.23 #30261

Closed

Add NewIssue events

95cecbb

lunny added the topic/projects label May 7, 2024

lunny added this to the 1.23.0 milestone May 7, 2024

Merge branch 'main' into lunny/project_workflow

5d78be4

lunny mentioned this pull request May 29, 2024

add custom fields/attribute to issues #18210

Open

lunny removed this from the 1.23.0 milestone Sep 7, 2024

lunny added this to the 1.24.0 milestone Dec 17, 2024

lunny mentioned this pull request Dec 17, 2024

Plans for Gitea 1.24 #32877

Closed

Merge branch 'main' into lunny/project_workflow

9d0a599

lunny added 4 commits December 29, 2025 17:42

Use const instead of string

3d5241a

permission check when save filters and actions

ce37554

Fix test

a6eb361

Use camel case in typescript

1a045fa

github-actions bot added the modifies/dependencies label Dec 30, 2025

wxiaoguang mentioned this pull request Jan 11, 2026

Fix CODEOWNERS review request attribution using comment metadata #36348

Merged

2 tasks

lunny added 3 commits February 20, 2026 16:14

Merge branch 'main' into lunny/project_workflow

726c510

Remove unnecessary project workflow virtual user

60ca53d

Fix lint

512365a

lunny commented Feb 21, 2026

View reviewed changes