gitea
gitea copied to clipboard
go-gitea
Add project workflow feature so users can define how to execute steps when project related events fired
This PR supports repository workflow files under .gitea/projects/ to response to projects related events and do some actions. For org project, maybe we can read orgname/.profile repository.
Resolve #13498 Resolve #14359 Resolve #26704 Resolve #27990 Resolve #25028 Replace #28745
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
