Client-side CI runs #11362

New Issue

GiteaMirror · 2025-11-02T09:35:32-06:00

GiteaMirror commented

2025-11-02 09:35:32 -06:00

Originally created by @rikhuijzer on GitHub (Jul 29, 2023).

Feature Description

Thanks for making Gitea. I'm a big fan.

I would like to make a feature request for Gitea. Currently, Gitea has implemented CI similarly to GitHub, GitLab and others. For each commit, when one or more CI jobs are attached, the dot will color red, orange, or green when jobs respectively fail, didn't start, or pass. Would it be possible to configure my environment in such a way that I can run the tests locally in a Git Hook (for example, in the pre-commit hook) and send this information to Gitea? This would allow people to get an idea of the status of their tests (fail, didn't start, or pass) without having to setup a separate CI server. Also, for people who do have a separate CI server, this could avoid the need to run tests twice.

And yes, there are drawbacks to this approach. Of course, the nice thing about CI is that it is reasonably stateless and therefore can avoid issues caused by hidden state. However, some development environments are pretty robust against hidden state. Also, there could be situations where hidden state is less of a problem than setting up CI or re-running tests.

Screenshots

No response

Originally created by @rikhuijzer on GitHub (Jul 29, 2023). ### Feature Description Thanks for making Gitea. I'm a big fan. I would like to make a feature request for Gitea. Currently, Gitea has implemented CI similarly to GitHub, GitLab and others. For each commit, when one or more CI jobs are attached, the dot will color red, orange, or green when jobs respectively fail, didn't start, or pass. Would it be possible to configure my environment in such a way that I can run the tests locally in a Git Hook (for example, in the pre-commit hook) and send this information to Gitea? This would allow people to get an idea of the status of their tests (fail, didn't start, or pass) without having to setup a separate CI server. Also, for people who do have a separate CI server, this could avoid the need to run tests twice. And yes, there are drawbacks to this approach. Of course, the nice thing about CI is that it is reasonably stateless and therefore can avoid issues caused by hidden state. However, some development environments are pretty robust against hidden state. Also, there could be situations where hidden state is less of a problem than setting up CI or re-running tests. ### Screenshots _No response_

GiteaMirror added the type/proposal label 2025-11-02 09:35:32 -06:00

GiteaMirror closed this issue

2025-11-02 09:35:32 -06:00

GiteaMirror commented

2025-11-02 09:35:33 -06:00

@delvh commented on GitHub (Jul 29, 2023):

I am not quite sure what you want, or how that is a Gitea issue.
Here's what I understood:
You want to run the CI in the pre-commit hook of the client

While that is possible for you yourself, it is impossible for anyone else: It's a security measure of Git that you cannot upload hooks of a repository. You can only offer it as a normal file in the repository and hope that everyone reads your documentation and enables the hook, but you cannot enforce it.

To me, it sounds like you want branch protection as in people can only push to restricted branches by using a PR.
That way, you can enforce that the CI passes before enabling the merge.

Please correct me if I understood you incorrectly.

@delvh commented on GitHub (Jul 29, 2023): I am not quite sure what you want, or how that is a Gitea issue. Here's what I understood: You want to run the CI in the pre-commit hook of the client While that is possible for you yourself, it is impossible for anyone else: It's a security measure of Git that you cannot upload hooks of a repository. You can only offer it as a normal file in the repository and hope that everyone reads your documentation and enables the hook, but you cannot enforce it. To me, it sounds like you want branch protection as in people can only push to restricted branches by using a PR. That way, you can enforce that the CI passes before enabling the merge. Please correct me if I understood you incorrectly.

GiteaMirror commented

2025-11-02 09:35:33 -06:00

@rikhuijzer commented on GitHub (Jul 29, 2023):

Okay. Apologies for being unclear. That was not what I meant at all.

I meant to allow people to run CI locally and send the outcome of the run to the Gitea server together with the code. For example, if I'm working on a Rust project (tests take about 10 seconds locally), I just want Git to run the tests when I push the code and let the server know "everything ran fine locally; you can add the green checkmark to this commit".

Sounds like a silly feature request, but I do think that this could really help out some people.

@rikhuijzer commented on GitHub (Jul 29, 2023): Okay. Apologies for being unclear. That was not what I meant at all. I meant to allow people to run CI locally and send the outcome of the run to the Gitea server together with the code. For example, if I'm working on a Rust project (tests take about 10 seconds locally), I just want Git to run the tests when I push the code and let the server know "everything ran fine locally; you can add the green checkmark to this commit". Sounds like a silly feature request, but I do think that this could really help out some people.

GiteaMirror commented

2025-11-02 09:35:33 -06:00

@rikhuijzer commented on GitHub (Jul 29, 2023):

While that is possible for you yourself, it is impossible for anyone else: It's a security measure of Git that you cannot upload hooks of a repository. You can only offer it as a normal file in the repository and hope that everyone reads your documentation and enables the hook, but you cannot enforce it.

So this is not an issue. Local running would be optional. You can add a hook when you want it, or not if you prefer server-side CI runs.

@rikhuijzer commented on GitHub (Jul 29, 2023): > While that is possible for you yourself, it is impossible for anyone else: It's a security measure of Git that you cannot upload hooks of a repository. You can only offer it as a normal file in the repository and hope that everyone reads your documentation and enables the hook, but you cannot enforce it. So this is not an issue. Local running would be optional. You can add a hook when you want it, or not if you prefer server-side CI runs.

GiteaMirror commented

2025-11-02 09:35:33 -06:00

@lunny commented on GitHub (Jul 29, 2023):

Maybe you want ./act_runner exec?

@lunny commented on GitHub (Jul 29, 2023): Maybe you want `./act_runner exec`?

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#11362