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

An internal CI/CD system compatible with Github actions workflow yaml syntax, action yaml syntax and most action plugins #6306

New Issue
Closed
opened 2025-11-02 06:51:45 -06:00 by GiteaMirror · 96 comments
GiteaMirror commented 2025-11-02 06:51:45 -06:00
Owner
Copy Link

Originally created by @lunny on GitHub (Nov 13, 2020).

Internal CI/CD system

I propose to implement an internal CI/CD system that is compatible with Github workflows yaml syntax, action yaml syntax, and most action plugins. And this is in fact not only a CI/CD system, but you can also choose to not check out the code for some events for example, when an issue is posted, you want to reply to them, then you don't need to check out the code. You can just reply to that issue. So the sub-system name is botsactions, if you have a better name than that, please let me know.

Pros

  • Migrated repositories from Github could easily reuse the actions workflow files
  • Plugins could be copied from https://github.com/actions or https://gitea.com/actions to your self-hosted Gitea instances or any git service repository address
  • Transparent for the CI/CD process. You can check out all workflow files and plugin codes you are using.
  • Bring version management for your CI/CD scripts and plugins
  • Customize your image. Github's image for ubuntu-latest is very big but Gitea now will use node:16-buster as the default image which is about 150MB and of course you could change it yourself.

Cons

  • Images are maybe very big for those small devices and have to be changed when you have new dependencies.
  • Many Gitea users are familiar with Drone/Woodpecker
  • More feedbacks are welcome

Reference documentation

At the moment, we lack documents, but if you want to know more details about what Github Actions looks like, please visit https://docs.github.com/en/actions.

Names chosen

Different from Github's related sub-system's name, we call the plugins action or actions. One action in fact is a repository with a file named action.yml in the root, the repository is hosted in any git service server which could be gitea.com, your self-hosted Gitea instance, and even github.com. There is a default configuration but we should also support absolute git URL as a plugin repository.

Task summary

There are many things need to do

Although we will have an internal CI/CD system Gitea will still be open to integrating external systems and will provide more features to make the integration smooth. The below tasks do not belong to the internal CI/CD system but are very important for integrating the external CI/CD system

Originally created by @lunny on GitHub (Nov 13, 2020). # Internal CI/CD system I propose to implement an internal CI/CD system that is compatible with Github workflows `yaml` syntax, action `yaml` syntax, and most action plugins. And this is in fact not only a CI/CD system, but you can also choose to not check out the code for some events for example, when an issue is posted, you want to reply to them, then you don't need to check out the code. You can just reply to that issue. So the sub-system name is ~`bots`~`actions`, if you have a better name than that, please let me know. ## Pros - Migrated repositories from Github could easily reuse the actions workflow files - Plugins could be copied from https://github.com/actions or https://gitea.com/actions to your self-hosted Gitea instances or any git service repository address - Transparent for the CI/CD process. You can check out all workflow files and plugin codes you are using. - Bring version management for your CI/CD scripts and plugins - Customize your image. Github's image for `ubuntu-latest` is very big but Gitea now will use `node:16-buster` as the default image which is about 150MB and of course you could change it yourself. ## Cons - Images are maybe very big for those small devices and have to be changed when you have new dependencies. - Many Gitea users are familiar with Drone/Woodpecker - More feedbacks are welcome # Reference documentation At the moment, we lack documents, but if you want to know more details about what Github Actions looks like, please visit https://docs.github.com/en/actions. # Names chosen Different from Github's related sub-system's name, we call the plugins `action` or `actions`. One `action` in fact is a repository with a file named `action.yml` in the root, the repository is hosted in any git service server which could be `gitea.com`, your self-hosted Gitea instance, and even github.com. There is a default configuration but we should also support absolute git URL as a plugin repository. # Task summary There are many things need to do - [x] Secrets management #22142 - [x] An event listener and task scheduler #21937 - [x] A stable communication protocol between Gitea and runners https://gitea.com/gitea/actions-proto-def - [x] A runner based on docker https://gitea.com/gitea/act_runner - [x] A UI that will show tasks and logs #21937 - [x] Some core actions are now in https://gitea.com/actions which currently are mirrors but may be changed if there are incompatible between Github API v3 and Gitea API v1 - [x] Support absolute plugin address like `uses: https://github.com/peaceiris/actions-hugo@v2` https://gitea.com/gitea/act/pulls/14 - [x] Artifact protocol compatible with Github's, some reports could be displayed in UI directly i.e. Golang standard coverage file #22738 - [x] Service support https://gitea.com/gitea/act/pulls/5 - [x] Cron support #26655 - [x] Cache action https://gitea.com/gitea/act_runner/pulls/25 - [ ] The default plugin programming language is `Javascript/Typescript`, but we need to support more programming languages - [ ] `Python` https://gitea.com/gitea/act_runner/issues/44 - [x] `Golang` - [ ] `Rust` - [ ] `PHP` - [ ] More - [ ] Check tab in the pull request to list results on the pull request page so that we don't need to go to actions page - [ ] Composite workflow, a workflow file could reference another workflow as a step. Although we will have an internal CI/CD system Gitea will still be open to integrating external systems and will provide more features to make the integration smooth. The below tasks do not belong to the internal CI/CD system but are very important for integrating the external CI/CD system - [x] A standard protocol to get tasks and get logs back https://gitea.com/gitea/actions-proto-def
GiteaMirror added the topic/gitea-actionstype/proposaltype/summary labels 2025-11-02 06:51:45 -06:00
GiteaMirror commented 2025-11-02 06:51:46 -06:00
Author
Owner
Copy Link

@a1012112796 commented on GitHub (Nov 15, 2020):

tips about api for ci tools to repot detail message:

  1. lint messages, can show them like code comment (but can marked as wrong by manager)
    the stype of data that provide by api
{
    commit: xxxxxxx
    path: "xxxxx/xxxxx",
    line: -1,
    type:  bug/ security/ codesmell/ info,
    detail: xxxxxxx,
   provider: xxxxx,
}

example in gitee
image

  1. code coverage data like codecov
{
    commit: xxxxxxx
    path: "xxxxx/xxxxx",
    group: golang,    // only data in same group will be calculate together
   provider: xxxxx,
   start_line: xx,
   start_cols: xx,
   end_line: xx,
  end_cols: xx,
  matched: 0 -- not, .>1 -- yes
}

do some calculate and show some usefull data on ui.

  1. detal log in ci steps, should show them in an individual page like gh actions.
    then user can design a sample ci tools which not need it's own ui :)
    style:
{
    commit: xxxxxxx
    step_name: aaa,
    parent_step_name: bbb,
   previous_step_name: ccc,
    log: xxxxx, or link to log data
   status: pending or runing or success ....
}

example on gh
image

@a1012112796 commented on GitHub (Nov 15, 2020): tips about api for ci tools to repot detail message: 1. lint messages, can show them like code comment (but can marked as wrong by manager) the stype of data that provide by api ```JSON { commit: xxxxxxx path: "xxxxx/xxxxx", line: -1, type: bug/ security/ codesmell/ info, detail: xxxxxxx, provider: xxxxx, } ``` example in gitee ![image](https://user-images.githubusercontent.com/25342410/99187445-a102f980-2791-11eb-83f6-a970c8ccdcfb.png) 2. code coverage data like codecov ```JSON { commit: xxxxxxx path: "xxxxx/xxxxx", group: golang, // only data in same group will be calculate together provider: xxxxx, start_line: xx, start_cols: xx, end_line: xx, end_cols: xx, matched: 0 -- not, .>1 -- yes } ``` do some calculate and show some usefull data on ui. 3. detal log in ci steps, should show them in an individual page like gh actions. then user can design a sample ci tools which not need it's own ui :) style: ```JSON { commit: xxxxxxx step_name: aaa, parent_step_name: bbb, previous_step_name: ccc, log: xxxxx, or link to log data status: pending or runing or success .... } ``` example on gh ![image](https://user-images.githubusercontent.com/25342410/99188042-eb39aa00-2794-11eb-8afe-4d2037df498d.png)
GiteaMirror commented 2025-11-02 06:51:46 -06:00
Author
Owner
Copy Link

@Be-ing commented on GitHub (Mar 12, 2021):

Support github actions files and allow external agent to execute the action via Gitea's API and returned result as above results.

Can you clarify what this will entail? Would this mean GitHub Actions could run on a github.com mirror of a repo and the results would appear on a Gitea server?

@Be-ing commented on GitHub (Mar 12, 2021): > Support github actions files and allow external agent to execute the action via Gitea's API and returned result as above results. Can you clarify what this will entail? Would this mean GitHub Actions could run on a github.com mirror of a repo and the results would appear on a Gitea server?
GiteaMirror commented 2025-11-02 06:51:46 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Mar 14, 2021):

That means Github actions could be running on Gitea(with this CI feature) servers(actually on user's agent, Gitea will only a coordinator and result saver).
Then mirrors/migrations of repositories from github/github enterprise could run the ci directly and no(or small) modification needed.

@lunny commented on GitHub (Mar 14, 2021): That means Github actions could be running on Gitea(with this CI feature) servers(actually on user's agent, Gitea will only a coordinator and result saver). Then mirrors/migrations of repositories from github/github enterprise could run the ci directly and no(or small) modification needed.
GiteaMirror commented 2025-11-02 06:51:47 -06:00
Author
Owner
Copy Link

@a1012112796 commented on GitHub (Mar 14, 2021):

see

@a1012112796 commented on GitHub (Mar 14, 2021): see - https://docs.github.com/en/rest/reference/checks - https://docs.github.com/en/rest/reference/code-scanning
GiteaMirror commented 2025-11-02 06:51:47 -06:00
Author
Owner
Copy Link

@moqmar commented on GitHub (Mar 30, 2021):

Would this be implemented by explicitly checking for a .github directory and sending those repos to the agent automatically on push using something like a global webhook? Because I think it would be great to not limit this to just GitHub Actions, but rather have a "global webhook" for pushes to an agent that can then decide what to do with that push - either using the GitHub Actions definitions, or for example running other CI implementations.

@moqmar commented on GitHub (Mar 30, 2021): Would this be implemented by explicitly checking for a `.github` directory and sending those repos to the agent automatically on push using something like a global webhook? Because I think it would be great to not limit this to just GitHub Actions, but rather have a "global webhook" for pushes to an agent that can then decide what to do with that push - either using the GitHub Actions definitions, or for example running other CI implementations.
GiteaMirror commented 2025-11-02 06:51:47 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Mar 30, 2021):

@moqmar Global webhooks have been implemented. The issue is to be compatible with actions for those migrations from github.

@lunny commented on GitHub (Mar 30, 2021): @moqmar Global webhooks have been implemented. The issue is to be compatible with actions for those migrations from github.
GiteaMirror commented 2025-11-02 06:51:47 -06:00
Author
Owner
Copy Link

@ChristopherHX commented on GitHub (May 4, 2021):

I have been working on an external webhook endpoint for github actions self-hosted runners to use with my gitea instance or locally on any pc. This is basically a fork of the runner to be able to reuse their code for a missing aspnetcore server. During my tests I was able to use gitea almost like a ghes instance, some actions like actions/checkout@v2 have had minor incompatibilities with authentication.

I would be glad to see endpoints for CI logs and have an integrated UI. Currently I have a basic react UI to display my logs, added as an external tab to gitea.

Experimental Usage
Download and extract https://github.com/ChristopherHX/runner.server/releases/latest for your system

Setup Gitea as an ghes endpoint, file bin/appsettings.json, change the url from http://localhost:5000 to a different http url / port

  "Runner.Server": {
    "GitServerUrl": "https://gitea:3042",
    "GitApiServerUrl": "https://gitea:3042/api/v1",
    "GitGraphQlServerUrl": null,
    "GITHUB_TOKEN": "Add your personal access token here",
    "ActionDownloadUrls": [
      {
        "TarballUrl": "https://gitea:3042/{0}/archive/{1}.tar.gz",
        "ZipballUrl": "https://gitea:3042/{0}/archive/{1}.zip"
      }
    ]
  }

Add <url of Runner.Server>/runner/server/_apis/v1/Message (http://localhost:5000/runner/server/_apis/v1/Message) as a webhook (select gitea) for your repo, to enable actions.

Setup https and use openid connect with gitea (Optional for Security, only working if the github actions server is using https)

  • Create an oauth2 app (User settings)
  • You will need to add the clientid and secret into bin/appsettings.json
  • You will need a pem certificate pair (cert.pem (only a single certificate will work, no cert chain) , key.pem)
"Kestrel": {
    "Endpoints": {
      "HttpsFromPem": {
        "Url": "https://*:5001",
        "Certificate": {
          "Path": "./cert.pem",
          "KeyPath": "./key.pem"
        }
      }
    }
  },
  "ClientId": "ClientId of your Oauth app",
  "ClientSecret": "Client secret of your Oauth app",
  "Authority": "https://gitea:3042",

Add <url of Runner.Server>/signin-oidc (https://localhost:5001/signin-oidc) as redirect url for the OAuth app in gitea.

Start bin/Runner.Server(.exe)
Open <url of Runner.Server> (http://localhost:5000, https://localhost:5001) to see if a job was received

Configure self-hosted runners, https://github.com/ChristopherHX/runner.server#advanced-usage

EDIT 2021/10/26
I added a ( temporary ) public test instance of runner.server connected to try.gitea.io 7ac850a3a9

Press rerun workflow to see in progress job runs
EDIT 2021/02/02
Fix openid sample config to actually have working https with pem

@ChristopherHX commented on GitHub (May 4, 2021): I have been working on an [external webhook endpoint for github actions self-hosted runners](https://github.com/ChristopherHX/runner.server) to use with my gitea instance or locally on any pc. This is basically a fork of the runner to be able to reuse their code for a missing aspnetcore server. During my tests I was able to use gitea almost like a ghes instance, some actions like `actions/checkout@v2` have had minor incompatibilities with authentication. I would be glad to see endpoints for CI logs and have an integrated UI. Currently I have a basic react UI to display my logs, added as an external tab to gitea. <p align="center"> <img src="https://github.com/ChristopherHX/runner.server/blob/main/src/Runner.Server/webpage1.png?raw=true"> </p> _Experimental Usage_ Download and extract https://github.com/ChristopherHX/runner.server/releases/latest for your system Setup Gitea as an ghes endpoint, file `bin/appsettings.json`, change the url from `http://localhost:5000` to a different http url / port ```json "Runner.Server": { "GitServerUrl": "https://gitea:3042", "GitApiServerUrl": "https://gitea:3042/api/v1", "GitGraphQlServerUrl": null, "GITHUB_TOKEN": "Add your personal access token here", "ActionDownloadUrls": [ { "TarballUrl": "https://gitea:3042/{0}/archive/{1}.tar.gz", "ZipballUrl": "https://gitea:3042/{0}/archive/{1}.zip" } ] } ``` Add `<url of Runner.Server>/runner/server/_apis/v1/Message` (`http://localhost:5000/runner/server/_apis/v1/Message`) as a webhook (select gitea) for your repo, to enable actions. Setup https and use openid connect with gitea (Optional for Security, only working if the github actions server is using https) - Create an oauth2 app (User settings) - You will need to add the clientid and secret into `bin/appsettings.json` - You will need a pem certificate pair (`cert.pem` (only a single certificate will work, no cert chain) , `key.pem`) ```json "Kestrel": { "Endpoints": { "HttpsFromPem": { "Url": "https://*:5001", "Certificate": { "Path": "./cert.pem", "KeyPath": "./key.pem" } } } }, "ClientId": "ClientId of your Oauth app", "ClientSecret": "Client secret of your Oauth app", "Authority": "https://gitea:3042", ``` Add `<url of Runner.Server>/signin-oidc` (`https://localhost:5001/signin-oidc`) as redirect url for the OAuth app in gitea. Start `bin/Runner.Server`(`.exe`) Open `<url of Runner.Server>` (`http://localhost:5000`, `https://localhost:5001`) to see if a job was received Configure self-hosted runners, https://github.com/ChristopherHX/runner.server#advanced-usage **EDIT 2021/10/26** I added a ( temporary ) public test instance of runner.server connected to try.gitea.io https://try.gitea.io/ChristopherHX/actions-on-gitea/commit/7ac850a3a96a7c60417c1306f50d49ea08d2e7d7 ~~Press rerun workflow to see in progress job runs~~ **EDIT 2021/02/02** Fix openid sample config to actually have working https with pem
GiteaMirror commented 2025-11-02 06:51:48 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (May 4, 2021):

@ChristopherHX whoa! That's amazing!!

@techknowlogick commented on GitHub (May 4, 2021): @ChristopherHX whoa! That's amazing!!
GiteaMirror commented 2025-11-02 06:51:48 -06:00
Author
Owner
Copy Link

@Bobby99as commented on GitHub (Oct 26, 2021):

This seems nice

@Bobby99as commented on GitHub (Oct 26, 2021): This seems nice
GiteaMirror commented 2025-11-02 06:51:48 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Nov 25, 2022):

Regarding the name: I think "bot(s)" is too confusing with "robot(s)" which are automated user accounts. How about naming it "step(s)"? Most of the terminology that relates to "action(s)" would also apply to "step(s)".

@silverwind commented on GitHub (Nov 25, 2022): Regarding the name: I think "bot(s)" is too confusing with "robot(s)" which are automated user accounts. How about naming it "step(s)"? Most of the terminology that relates to "action(s)" would also apply to "step(s)".
GiteaMirror commented 2025-11-02 06:51:48 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Nov 25, 2022):

Regarding the name: I think "bot(s)" is too confusing with "robot(s)" which are automated user accounts. How about naming it "step(s)"? Most of the terminology that relates to "action(s)" would also apply to "step(s)".

To diff from Github Actions, I don't think we should use actions as name. Bots might means automatical but not robot, I'm not English native speaker and maybe there is a better name for it. This is really not only a CI/CD system, you can do more like below yml file.

name: Issue post

on:
  issue_comment:
    types: [created]

jobs:
  comment_created:
    runs-on: ubuntu-latest
    steps:
      - run: env
      - name: Create comment
        uses: peter-evans/create-or-update-comment@v2
        with:
          issue-number: ${{github.event.issue.number}}
          body: |
            This is a multi-line test comment
            - With GitHub **Markdown** :sparkles:
            - Created by [create-or-update-comment][1]

            [1]: https://gitea.com/peter-evans/create-or-update-comment
          reactions: '+1'

But I think maybe step(s) is too small for this feature?

@lunny commented on GitHub (Nov 25, 2022): > Regarding the name: I think "bot(s)" is too confusing with "robot(s)" which are automated user accounts. How about naming it "step(s)"? Most of the terminology that relates to "action(s)" would also apply to "step(s)". To diff from Github Actions, I don't think we should use actions as name. `Bots` might means `automatical` but not `robot`, I'm not English native speaker and maybe there is a better name for it. This is really not only a CI/CD system, you can do more like below yml file. ```yaml name: Issue post on: issue_comment: types: [created] jobs: comment_created: runs-on: ubuntu-latest steps: - run: env - name: Create comment uses: peter-evans/create-or-update-comment@v2 with: issue-number: ${{github.event.issue.number}} body: | This is a multi-line test comment - With GitHub **Markdown** :sparkles: - Created by [create-or-update-comment][1] [1]: https://gitea.com/peter-evans/create-or-update-comment reactions: '+1' ``` But I think maybe `step(s)` is too small for this feature?
GiteaMirror commented 2025-11-02 06:51:48 -06:00
Author
Owner
Copy Link

@eeyrjmr commented on GitHub (Nov 25, 2022):

how about automate

@eeyrjmr commented on GitHub (Nov 25, 2022): how about `automate`
GiteaMirror commented 2025-11-02 06:51:49 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Nov 25, 2022):

I'm not English native speaker and maybe there is a better name for it

It's well established even in non-english languages that bot is a program that impersonates a human.

So we are looking for a noun that signifies something being done. "Build" does qualify but is already occupied in the sense of it meaning to construct software. Some ideas maybe here.

@silverwind commented on GitHub (Nov 25, 2022): > I'm not English native speaker and maybe there is a better name for it It's well established even in non-english languages that [bot](https://en.wikipedia.org/wiki/Bot) is a program that impersonates a human. So we are looking for a noun that signifies something being done. "Build" does qualify but is already occupied in the sense of it meaning to construct software. Some ideas maybe [here](https://www.thesaurus.com/browse/action).
GiteaMirror commented 2025-11-02 06:51:49 -06:00
Author
Owner
Copy Link

@JakobDev commented on GitHub (Nov 25, 2022):

I personal think developing this makes no sense. As said in the start post, there are already working CI systems. It would make more sense to integrate e,.g. Woodpecker directly in Gitea instead of wasting a lot of development resources to develop something that already exists.

@JakobDev commented on GitHub (Nov 25, 2022): I personal think developing this makes no sense. As said in the start post, there are already working CI systems. It would make more sense to integrate e,.g. Woodpecker directly in Gitea instead of wasting a lot of development resources to develop something that already exists.
GiteaMirror commented 2025-11-02 06:51:49 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Nov 25, 2022):

How about Task(s) or Job(s)? E.g. signifying a unit of work.

@silverwind commented on GitHub (Nov 25, 2022): How about Task(s) or Job(s)? E.g. signifying a unit of work.
GiteaMirror commented 2025-11-02 06:51:49 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Nov 25, 2022):

I personal think developing this makes no sense. As said in the start post, there are already working CI systems. It would make more sense to integrate e,.g. Woodpecker directly in Gitea instead of wasting a lot of development resources to develop something that already exists.

They are different systems. Gitea could support both.

@lunny commented on GitHub (Nov 25, 2022): > I personal think developing this makes no sense. As said in the start post, there are already working CI systems. It would make more sense to integrate e,.g. Woodpecker directly in Gitea instead of wasting a lot of development resources to develop something that already exists. They are different systems. Gitea could support both.
GiteaMirror commented 2025-11-02 06:51:49 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Nov 25, 2022):

well before merge we should make sure https://github.com/woodpecker-ci/woodpecker/issues/1385 is ready and gitea do support both equally

@6543 commented on GitHub (Nov 25, 2022): well before merge we should make **sure** https://github.com/woodpecker-ci/woodpecker/issues/1385 is ready and gitea **do** support both **equally**
GiteaMirror commented 2025-11-02 06:51:50 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Nov 25, 2022):

As I pointed out, I don't like the feature-creep but as long as it is possible to disable it completely, I won't block this but also wont focus on fix it either ...

@6543 commented on GitHub (Nov 25, 2022): As I pointed out, I don't like the feature-creep but as long as it is possible to disable it **completely**, I won't block this but also wont focus on fix it either ...
GiteaMirror commented 2025-11-02 06:51:50 -06:00
Author
Owner
Copy Link

@markusamshove commented on GitHub (Nov 25, 2022):

What about Auteamate? 😋
Contains tea, a friendly mate and suggests automation

@markusamshove commented on GitHub (Nov 25, 2022): What about Auteamate? 😋 Contains tea, a friendly mate and suggests automation
GiteaMirror commented 2025-11-02 06:51:51 -06:00
Author
Owner
Copy Link

@kmk3 commented on GitHub (Nov 25, 2022):

Suggestions of boring and obvious names:

  • Gitea Automation (looks relatively similar to "GitHub Actions")
  • Gitea CI (like GitLab CI and countless others)
@kmk3 commented on GitHub (Nov 25, 2022): Suggestions of boring and obvious names: * Gitea Automation (looks relatively similar to "GitHub Actions") * Gitea CI (like GitLab CI and countless others)
GiteaMirror commented 2025-11-02 06:51:51 -06:00
Author
Owner
Copy Link

@kmk3 commented on GitHub (Nov 25, 2022):

Suggestions of tea-related names:

  • Boba CI (as in boba tea)
  • Bubble CI
  • Gitea Brew
  • Gitea Chai Infusion (Gitea CI)
  • Gitea Continuous Infusion (Gitea CI)
  • Teabot
  • Teamagic
@kmk3 commented on GitHub (Nov 25, 2022): Suggestions of tea-related names: * Boba CI (as in boba tea) * Bubble CI * Gitea Brew * Gitea Chai Infusion (Gitea CI) * Gitea Continuous Infusion (Gitea CI) * Teabot * Teamagic
GiteaMirror commented 2025-11-02 06:51:51 -06:00
Author
Owner
Copy Link

@williamdes commented on GitHub (Nov 25, 2022):

Suggestions of boring and obvious names:

  • Gitea Automation (looks relatively similar to "GitHub Actions")

I would put this one first because the name is easy and stays in mind

  • Gitea CI (like GitLab CI and countless others)

Boring but just perfect for what it is 😄

@williamdes commented on GitHub (Nov 25, 2022): > Suggestions of boring and obvious names: > > * Gitea Automation (looks relatively similar to "GitHub Actions") I would put this one first because the name is easy and stays in mind > * Gitea CI (like GitLab CI and countless others) Boring but just perfect for what it is 😄
GiteaMirror commented 2025-11-02 06:51:51 -06:00
Author
Owner
Copy Link

@tobiasBora commented on GitHub (Nov 25, 2022):

Can't we stick to a vocabulary as close as possible to github's when possible? This would allow a faster transition from people coming from github, and ideally easy migrations. Of course, if they do incompatible things we should get a new name. I prefer the "boring" but descriptive terms like "task" compared to fancy unclear terms.

I agree that it would be awesome to have native gitea integration. But if it takes ressources, I agree it would be good to disable it to run it on low-end devices (I still want gitea to run on my raspberry pi).

@tobiasBora commented on GitHub (Nov 25, 2022): Can't we stick to a vocabulary as close as possible to github's when possible? This would allow a faster transition from people coming from github, and ideally easy migrations. Of course, if they do incompatible things we should get a new name. I prefer the "boring" but descriptive terms like "task" compared to fancy unclear terms. I agree that it would be awesome to have native gitea integration. But if it takes ressources, I agree it would be good to disable it to run it on low-end devices (I still want gitea to run on my raspberry pi).
GiteaMirror commented 2025-11-02 06:51:51 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Nov 26, 2022):

How about motions which is close to actions and short enough.

Or autos ?

@lunny commented on GitHub (Nov 26, 2022): How about motions which is close to actions and short enough. Or autos ?
GiteaMirror commented 2025-11-02 06:51:52 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Nov 26, 2022):

I just tried it and wrote a note:

https://gist.github.com/xin-u/f459c4805b348595e4981000b75443fe

@ghost commented on GitHub (Nov 26, 2022): I just tried it and wrote a note: https://gist.github.com/xin-u/f459c4805b348595e4981000b75443fe
GiteaMirror commented 2025-11-02 06:51:52 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Nov 26, 2022):

feature-creep

I don't think it's a feature-creep. The issue has been opened for 2 years and I have announced I'm working on that in discord for many times. And I think a PR should be created when it's basically ready but not from the day 1.

And I think Gitea should create a standard protocol and other external CI/CD tools could implement that to reuse Gitea's UI. Not only woodpecker, but also drone/jenkins and others could also implement the protocols to upload logs and etc. But I think that could be a standalone PR after a solid proposal.

@lunny commented on GitHub (Nov 26, 2022): > feature-creep I don't think it's a `feature-creep`. The issue has been opened for 2 years and I have announced I'm working on that in discord for many times. And I think a PR should be created when it's basically ready but not from the day 1. And I think Gitea should create a standard protocol and other external CI/CD tools could implement that to reuse Gitea's UI. Not only woodpecker, but also drone/jenkins and others could also implement the protocols to upload logs and etc. But I think that could be a standalone PR after a solid proposal.
GiteaMirror commented 2025-11-02 06:51:52 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Nov 26, 2022):

Yes would be nice if ui had some kind of abstraction to allow implement other runners inside gitea (something ui wise I started once but had no time to finish)

https://github.com/go-gitea/gitea/compare/main...lafriks-fork:gitea:feat/gitea_builds?expand=1

This way you would not have to enable it specifically, you would have to just add global/org/user/repo runners and use them

@lafriks commented on GitHub (Nov 26, 2022): Yes would be nice if ui had some kind of abstraction to allow implement other runners inside gitea (something ui wise I started once but had no time to finish) https://github.com/go-gitea/gitea/compare/main...lafriks-fork:gitea:feat/gitea_builds?expand=1 This way you would not have to enable it specifically, you would have to just add global/org/user/repo runners and use them
GiteaMirror commented 2025-11-02 06:51:52 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Nov 26, 2022):

Yes would be nice if ui had some kind of abstraction to allow implement other runners inside gitea (something ui wise I started once but had no time to finish)

https://github.com/go-gitea/gitea/compare/main...lafriks-fork:gitea:feat/gitea_builds?expand=1

This way you would not have to enable it specifically, you would have to just add global/org/user/repo runners and use them

Looks like in your design, every runner type has his protocol and Gitea will implement different protocol for different runners?

@lunny commented on GitHub (Nov 26, 2022): > Yes would be nice if ui had some kind of abstraction to allow implement other runners inside gitea (something ui wise I started once but had no time to finish) > > https://github.com/go-gitea/gitea/compare/main...lafriks-fork:gitea:feat/gitea_builds?expand=1 > > This way you would not have to enable it specifically, you would have to just add global/org/user/repo runners and use them Looks like in your design, every runner type has his protocol and Gitea will implement different protocol for different runners?
GiteaMirror commented 2025-11-02 06:51:53 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Nov 30, 2022):

For the name, I think we can have a vote.

We have several choices here(sorry this is not the whole suggested names because I think we haven't so many emojis :))

  • 🚀 Actions
  • 👀 Automate
  • ❤️ Motions
  • 👍 Bots
  • 🎉 Auteamate
  • 😄 Builds

continue in https://github.com/go-gitea/gitea/issues/13539#issuecomment-1332985355

@lunny commented on GitHub (Nov 30, 2022): For the name, I think we can have a vote. We have several choices here(sorry this is not the whole suggested names because I think we haven't so many emojis :)) - 🚀 Actions - 👀 Automate - ❤️ Motions - 👍 Bots - 🎉 Auteamate - 😄 Builds continue in https://github.com/go-gitea/gitea/issues/13539#issuecomment-1332985355
GiteaMirror commented 2025-11-02 06:51:53 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Nov 30, 2022):

Yes would be nice if ui had some kind of abstraction to allow implement other runners inside gitea (something ui wise I started once but had no time to finish)
https://github.com/go-gitea/gitea/compare/main...lafriks-fork:gitea:feat/gitea_builds?expand=1
This way you would not have to enable it specifically, you would have to just add global/org/user/repo runners and use them

Looks like in your design, every runner type has his protocol and Gitea will implement different protocol for different runners?

yes but with common interface that needs to be implemented (like we have for webhooks or packages)

@lafriks commented on GitHub (Nov 30, 2022): > > Yes would be nice if ui had some kind of abstraction to allow implement other runners inside gitea (something ui wise I started once but had no time to finish) > > https://github.com/go-gitea/gitea/compare/main...lafriks-fork:gitea:feat/gitea_builds?expand=1 > > This way you would not have to enable it specifically, you would have to just add global/org/user/repo runners and use them > > Looks like in your design, every runner type has his protocol and Gitea will implement different protocol for different runners? yes but with common interface that needs to be implemented (like we have for webhooks or packages)
GiteaMirror commented 2025-11-02 06:51:53 -06:00
Author
Owner
Copy Link

@BySempron commented on GitHub (Nov 30, 2022):

Is there only going to be one docker runner? Docker isn't the best in all setups, so I think we must have a "bare metal" runner which works without docker.

Just like AppVeyor default runner. Simply execute the commands you specify in your action file.

@BySempron commented on GitHub (Nov 30, 2022): Is there only going to be one docker runner? Docker isn't the best in all setups, so I think we must have a "bare metal" runner which works without docker. Just like AppVeyor default runner. Simply execute the commands you specify in your action file.
GiteaMirror commented 2025-11-02 06:51:53 -06:00
Author
Owner
Copy Link

@ChristopherHX commented on GitHub (Nov 30, 2022):

@BySempron The fork of gitea I saw didn't include my PR for a native execution environment
https://github.com/nektos/act/pull/1293. I hope that this change will be pulled and made available.

@ChristopherHX commented on GitHub (Nov 30, 2022): @BySempron The fork of gitea I saw didn't include my PR for a native execution environment https://github.com/nektos/act/pull/1293. I hope that this change will be pulled and made available.
GiteaMirror commented 2025-11-02 06:51:54 -06:00
Author
Owner
Copy Link

@tobiasBora commented on GitHub (Nov 30, 2022):

If I can give maybe another application of bare runners proposed by @BySempron, it would be for Nix (actually a gitea-native Nix runner would be also really cool… and maybe even simpler to implement as compiling in nix is just a matter of providing build instructions in some flake.nix file at the root of the repository and typing nix build path-of-repo#name-program to compile… you can also add tests and more). This makes sense when compiling softwares "packaged" using Nix as Nix already provides a sandbox restricting the scope of the building process (for security purpose and purity). And it also gives for free some sort of cache sharing among builds (like if my first software packages a package A, and my second software uses A, when the CI builds A, it will automatically be available when compiling software B without any need of recompiling software A). Also, it shares the dependencies between completely unrelated repository automatically (like if two repositories build some LaTeX documentation using the same LaTeX version, LaTeX will be downloaded just once and automatically shared among builders).

@tobiasBora commented on GitHub (Nov 30, 2022): If I can give maybe another application of bare runners proposed by @BySempron, it would be for [Nix](https://nixos.org/) (actually a gitea-native Nix runner would be also really cool… and maybe even simpler to implement as compiling in nix is just a matter of providing build instructions in some `flake.nix` file at the root of the repository and typing `nix build path-of-repo#name-program` to compile… you can also add tests and more). This makes sense when compiling softwares "packaged" using Nix as Nix already provides a sandbox restricting the scope of the building process (for security purpose and purity). And it also gives for free some sort of cache sharing among builds (like if my first software packages a package A, and my second software uses A, when the CI builds A, it will automatically be available when compiling software B without any need of recompiling software A). Also, it shares the dependencies between completely unrelated repository automatically (like if two repositories build some LaTeX documentation using the same LaTeX version, LaTeX will be downloaded just once and automatically shared among builders).
GiteaMirror commented 2025-11-02 06:51:54 -06:00
Author
Owner
Copy Link

@eeyrjmr commented on GitHub (Nov 30, 2022):

fyi "Actions" already refers to a Gitea UI and thus to name the worker scripts "actions" can raise some ambiguity if someone refers to them.

2022-11-30_22-11-1669847491

@eeyrjmr commented on GitHub (Nov 30, 2022): fyi "Actions" already refers to a Gitea UI and thus to name the worker scripts "actions" can raise some ambiguity if someone refers to them. ![2022-11-30_22-11-1669847491](https://user-images.githubusercontent.com/4564448/204922381-e5bbcfd5-c471-4235-9ebc-90b25ee1082f.jpg)
GiteaMirror commented 2025-11-02 06:51:54 -06:00
Author
Owner
Copy Link

@TheBrokenRail commented on GitHub (Nov 30, 2022):

Name-wise, what about Teapots, Pots, or Kettles? (You know, because teapot/tea kettle?)

I also like "Sips" which was suggested on the Discord.

@TheBrokenRail commented on GitHub (Nov 30, 2022): Name-wise, what about Teapots, Pots, or Kettles? (You know, because teapot/tea kettle?) I also like "Sips" which was suggested [on the Discord](https://discord.com/channels/322538954119184384/322910365237248000/1047542245387157594).
GiteaMirror commented 2025-11-02 06:51:54 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 1, 2022):

@BySempron The fork of gitea I saw didn't include my PR for a native execution environment nektos/act#1293. I hope that this change will be pulled and made available.

I think we can pull upstream code again in https://gitea.com/gitea/act and maybe you can help to send more PRs to these repositories.

@lunny commented on GitHub (Dec 1, 2022): > @BySempron The fork of gitea I saw didn't include my PR for a native execution environment [nektos/act#1293](https://github.com/nektos/act/pull/1293). I hope that this change will be pulled and made available. I think we can pull upstream code again in https://gitea.com/gitea/act and maybe you can help to send more PRs to these repositories.
GiteaMirror commented 2025-11-02 06:51:55 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 1, 2022):

Pots

Ah, right. I think we have to change the menu name if Actions win.

@lunny commented on GitHub (Dec 1, 2022): > Pots Ah, right. I think we have to change the menu name if `Actions` win.
GiteaMirror commented 2025-11-02 06:51:55 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 1, 2022):

  • 👍 Sips
  • ❤️ Pots
  • 🚀 Kettles
@lunny commented on GitHub (Dec 1, 2022): - 👍 Sips - ❤️ Pots - 🚀 Kettles
GiteaMirror commented 2025-11-02 06:51:55 -06:00
Author
Owner
Copy Link

@wolfogre commented on GitHub (Dec 1, 2022):

The fork of gitea I saw didn't include my PR for a native execution environment nektos/act#1293. I hope that this change will be pulled and made available.

@ChristopherHX It's amazing! The forked act is trying to track the latest release of nektos/act, so I will follow up once a new version including the commit is released.

@wolfogre commented on GitHub (Dec 1, 2022): > The fork of gitea I saw didn't include my PR for a native execution environment [nektos/act#1293](https://github.com/nektos/act/pull/1293). I hope that this change will be pulled and made available. @ChristopherHX It's amazing! The forked act is trying to track the latest release of nektos/act, so I will follow up once a new version including the commit is released.
GiteaMirror commented 2025-11-02 06:51:55 -06:00
Author
Owner
Copy Link

@kmk3 commented on GitHub (Dec 1, 2022):

@lunny Suggestion to add to the above list:

  • 🎉 Brews

(It works both as a noun and as a verb, so you could have a [Brew] button)

@kmk3 commented on GitHub (Dec 1, 2022): @lunny Suggestion to add to the above list: * :tada: Brews (It works both as a noun and as a verb, so you could have a `[Brew]` button)
GiteaMirror commented 2025-11-02 06:51:55 -06:00
Author
Owner
Copy Link

@wolfogre commented on GitHub (Dec 1, 2022):

@lunny Suggestion to add to the above list:

  • 🎉 Brews

(It works both as a noun and as a verb, so you could have a [Brew] button)

@kmk3 Excuse me, don't do that, please! 😂 I'm a user of homebrew, and typing brew install ... brew upgrade ... everyday.

@wolfogre commented on GitHub (Dec 1, 2022): > @lunny Suggestion to add to the above list: > > * 🎉 Brews > > (It works both as a noun and as a verb, so you could have a `[Brew]` button) @kmk3 Excuse me, don't do that, please! 😂 I'm a user of [homebrew](https://brew.sh/), and typing `brew install ... brew upgrade ...` everyday.
GiteaMirror commented 2025-11-02 06:51:56 -06:00
Author
Owner
Copy Link

@kmk3 commented on GitHub (Dec 1, 2022):

@kmk3 Excuse me, don't do that, please! joy I'm a user of
homebrew, and typing brew install ... brew upgrade ...
everyday.

Ah yes, maybe the CLI usage could be different then, like tea brew, gtb or
something (in which case the binary name for "Gitea Actions" could be rather
amusing).

Though would there even be a dedicated binary for this?

@kmk3 commented on GitHub (Dec 1, 2022): > @kmk3 Excuse me, don't do that, please! joy I'm a user of > [homebrew](https://brew.sh/), and typing `brew install ... brew upgrade ...` > everyday. Ah yes, maybe the CLI usage could be different then, like `tea brew`, `gtb` or something (in which case the binary name for "Gitea Actions" could be rather amusing). Though would there even be a dedicated binary for this?
GiteaMirror commented 2025-11-02 06:51:56 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Dec 1, 2022):

I think naming should be kept in UI as generic as possible to be able to integrate under that other CI information (Woodpecker CI, Jenkins etc) under it so imho Workflows would be generic enough not to hint to any exact product but be recognizable enough. CI/CD tool that is being developed as one of integration can be named than in some more specific name.

@lafriks commented on GitHub (Dec 1, 2022): I think naming should be kept in UI as generic as possible to be able to integrate under that other CI information (Woodpecker CI, Jenkins etc) under it so imho Workflows would be generic enough not to hint to any exact product but be recognizable enough. CI/CD tool that is being developed as one of integration can be named than in some more specific name.
GiteaMirror commented 2025-11-02 06:51:56 -06:00
Author
Owner
Copy Link

@wolfogre commented on GitHub (Dec 5, 2022):

I believe Actions is the final result. I know it's not perfect, but it's probably good enough for now.

image image
@wolfogre commented on GitHub (Dec 5, 2022): I believe `Actions` is the final result. I know it's not perfect, but it's probably good enough for now. <img width="845" alt="image" src="https://user-images.githubusercontent.com/9418365/205548586-b5a20a67-e31c-44b7-80eb-0a71544560d4.png"> <img width="842" alt="image" src="https://user-images.githubusercontent.com/9418365/205548652-2170acd9-7384-4d19-a888-b9e16e29e777.png">
GiteaMirror commented 2025-11-02 06:51:56 -06:00
Author
Owner
Copy Link

@gnat commented on GitHub (Dec 6, 2022):

Just rename the existing button to Manage (or whatever) and use Actions for this.

@gnat commented on GitHub (Dec 6, 2022): > <img src="https://user-images.githubusercontent.com/4564448/204922381-e5bbcfd5-c471-4235-9ebc-90b25ee1082f.jpg"></img> Just rename the existing button to Manage (or whatever) and use Actions for this.
GiteaMirror commented 2025-11-02 06:51:57 -06:00
Author
Owner
Copy Link

@ChristopherHX commented on GitHub (Dec 8, 2022):

It's amazing! The forked act is trying to track the latest release of nektos/act, so I will follow up once a new version including the commit is released.

@wolfogre Thank you for syncing nektos/act, however releases are currently just a monthly snapshot of master

You can now use this platform config self-hosted:docker://-self-hosted to get a native execution environment. The name docker:// is now confusing in this specfic case, because this specfic platform tag is not using docker at all.

@ChristopherHX commented on GitHub (Dec 8, 2022): > It's amazing! The forked act is trying to track the latest release of nektos/act, so I will follow up once a new version including the commit is released. @wolfogre Thank you for syncing nektos/act, however releases are currently just a monthly snapshot of master You can now use this platform config `self-hosted:docker://-self-hosted` to get a native execution environment. The name docker:// is now confusing in this specfic case, because this specfic platform tag is not using docker at all.
GiteaMirror commented 2025-11-02 06:51:57 -06:00
Author
Owner
Copy Link

@gnat commented on GitHub (Dec 18, 2022):

Wanted to say, as someone who uses a ton of Drone, it's going to be amazing to migrate to this new system and standardize on the Github actions format instead. Really looking forward to this.

@gnat commented on GitHub (Dec 18, 2022): Wanted to say, as someone who uses a ton of Drone, it's going to be amazing to migrate to this new system and standardize on the Github actions format instead. Really looking forward to this.
GiteaMirror commented 2025-11-02 06:51:57 -06:00
Author
Owner
Copy Link

@ibotty commented on GitHub (Jan 5, 2023):

As mentioned before, I'd really like to see different runners than only ones based on docker. There is a reason that the whole red hat influenced world moved away from docker.

But more importantly, I'd like to have a runner that runs the containers in a Kubernetes cluster. Will it be possible to use a different runner or is there tight integration? Is there some preliminary documentation besides the source on the api contract between gitea and the actions runner?

@ibotty commented on GitHub (Jan 5, 2023): As mentioned before, I'd really like to see different runners than only ones based on docker. There is a reason that the whole red hat influenced world moved away from docker. But more importantly, I'd like to have a runner that runs the containers in a Kubernetes cluster. Will it be possible to use a different runner or is there tight integration? Is there some preliminary documentation besides the source on the api contract between gitea and the actions runner?
GiteaMirror commented 2025-11-02 06:51:57 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jan 5, 2023):

As mentioned before, I'd really like to see different runners than only ones based on docker. There is a reason that the whole red hat influenced world moved away from docker.

But more importantly, I'd like to have a runner that runs the containers in a Kubernetes cluster. Will it be possible to use a different runner or is there tight integration? Is there some preliminary documentation besides the source on the api contract between gitea and the actions runner?

The protocol repository is https://gitea.com/gitea/actions-proto-def. I think we can have more runners in future, but let's have one at first. A runner based on act should be the easiest way to make one.

@lunny commented on GitHub (Jan 5, 2023): > As mentioned before, I'd really like to see different runners than only ones based on docker. There is a reason that the whole red hat influenced world moved away from docker. > > But more importantly, I'd like to have a runner that runs the containers in a Kubernetes cluster. Will it be possible to use a different runner or is there tight integration? Is there some preliminary documentation besides the source on the api contract between gitea and the actions runner? The protocol repository is https://gitea.com/gitea/actions-proto-def. I think we can have more runners in future, but let's have one at first. A runner based on `act` should be the easiest way to make one.
GiteaMirror commented 2025-11-02 06:51:58 -06:00
Author
Owner
Copy Link

@sschuberth commented on GitHub (Jan 5, 2023):

Cache action

I guess support for that would require to address https://github.com/nektos/act/issues/989#issuecomment-1156768547, which would be a great step towards running actions that leverage caches locally.

@sschuberth commented on GitHub (Jan 5, 2023): > Cache action I guess support for that would require to address https://github.com/nektos/act/issues/989#issuecomment-1156768547, which would be a great step towards running actions that leverage caches locally.
GiteaMirror commented 2025-11-02 06:51:58 -06:00
Author
Owner
Copy Link

@ChristopherHX commented on GitHub (Jan 7, 2023):

I made a POC gitea actions runner proxy based on actions/runner, this doesn't use nektos/act for action execution and doesn't require docker.
https://gitea.com/ChristopherHX/actions_runner

Now two runner implementations for gitea actions.

Things, which act doesn't support, but are possible with this proxy runner

  • service container
  • timeout-minutes

Bugs caused by the runnerv1 protocol, but are ok since it's experimental

  • actions/runner's live logs are skipping lines, but it is not possible to upload the full log without breaking live logs after the steps are finished
  • job outputs cannot be sent back https://gitea.com/gitea/actions-proto-def/issues/4
  • Not possible to update display name of steps from runner
    Pre and Post steps are part of setup and complete job, steps not in the job are ignored by the server
@ChristopherHX commented on GitHub (Jan 7, 2023): I made a POC gitea actions runner proxy based on actions/runner, this doesn't use nektos/act for action execution and doesn't require docker. https://gitea.com/ChristopherHX/actions_runner Now two runner implementations for gitea actions. Things, which act doesn't support, but are possible with this proxy runner - service container - timeout-minutes Bugs caused by the runnerv1 protocol, but are ok since it's experimental - actions/runner's live logs are skipping lines, but it is not possible to upload the full log without breaking live logs after the steps are finished - job outputs cannot be sent back https://gitea.com/gitea/actions-proto-def/issues/4 - Not possible to update display name of steps from runner Pre and Post steps are part of setup and complete job, steps not in the job are ignored by the server
GiteaMirror commented 2025-11-02 06:51:58 -06:00
Author
Owner
Copy Link

@yekanchi commented on GitHub (Jan 17, 2023):

Great Job,
I feel most of the people using Gitea over Gitlab and Github enterprise use it because it does not need Linux/WSL/docker stuff.
Then I think actions runner being native is crucial for real cross platform support.

@yekanchi commented on GitHub (Jan 17, 2023): Great Job, I feel most of the people using Gitea over Gitlab and Github enterprise use it because it does not need Linux/WSL/docker stuff. Then I think actions runner being native is crucial for real cross platform support.
GiteaMirror commented 2025-11-02 06:51:58 -06:00
Author
Owner
Copy Link

@MrHaroldA commented on GitHub (Jan 19, 2023):

Great Job, I feel most of the people using Gitea over Gitlab and Github enterprise use it because it does not need Linux/WSL/docker stuff. Then I think actions runner being native is crucial for real cross platform support.

I don't have the numbers, but why would anyone run Gitea on Windows instead of a server OS like Linux? I know it can run on Windows, but especially if you allow outside access you don't want a Windows machine connected to the "evil" internet.

Then again, I can understand the need for native runners for those who haven't containerized their services yet.

@MrHaroldA commented on GitHub (Jan 19, 2023): > Great Job, I feel most of the people using Gitea over Gitlab and Github enterprise use it because it does not need Linux/WSL/docker stuff. Then I think actions runner being native is crucial for real cross platform support. I don't have the numbers, but why would anyone run Gitea on Windows instead of a server OS like Linux? I know it _can_ run on Windows, but especially if you allow outside access you don't want a Windows machine connected to the "evil" internet. Then again, I can understand the need for native runners for those who haven't containerized their services yet.
GiteaMirror commented 2025-11-02 06:51:58 -06:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Jan 19, 2023):

I don't have the numbers, but why would anyone run Gitea on Windows instead of a server OS like Linux? I know it can run on Windows, but especially if you allow outside access you don't want a Windows machine connected to the "evil" internet.

There's software you can only build on windows, like tauri (at least for now). I have worked on a project where you could only deploy the software by pushing it to a server in the client's internal network and the vpn they were using was only available on Windows. With a Windows runner it's possible to build pipelines for these use cases which otherwise would be not possible.

@kolaente commented on GitHub (Jan 19, 2023): > I don't have the numbers, but why would anyone run Gitea on Windows instead of a server OS like Linux? I know it can run on Windows, but especially if you allow outside access you don't want a Windows machine connected to the "evil" internet. There's software you can only build on windows, like tauri (at least for now). I have worked on a project where you could only deploy the software by pushing it to a server in the client's internal network and the vpn they were using was only available on Windows. With a Windows runner it's possible to build pipelines for these use cases which otherwise would be not possible.
GiteaMirror commented 2025-11-02 06:51:59 -06:00
Author
Owner
Copy Link

@MrHaroldA commented on GitHub (Jan 19, 2023):

Ah, Windows native runners and not "Gitea on Windows"; didn't think about that ;)

Carry on!

@MrHaroldA commented on GitHub (Jan 19, 2023): Ah, Windows native runners and not "Gitea on Windows"; didn't think about that ;) Carry on!
GiteaMirror commented 2025-11-02 06:51:59 -06:00
Author
Owner
Copy Link

@jmg2k commented on GitHub (Jan 19, 2023):

but why would anyone run Gitea on Windows instead of a server OS like Linux?

Guess you've never heard about Windows Server then and probably also don't know how much easier it is to find administrators who know what they're doing.

@jmg2k commented on GitHub (Jan 19, 2023): > but why would anyone run Gitea on Windows instead of a server OS like Linux? Guess you've never heard about Windows Server then and probably also don't know how much easier it is to find administrators who know what they're doing.
GiteaMirror commented 2025-11-02 06:51:59 -06:00
Author
Owner
Copy Link

@yekanchi commented on GitHub (Jan 19, 2023):

Great Job, I feel most of the people using Gitea over Gitlab and Github enterprise use it because it does not need Linux/WSL/docker stuff. Then I think actions runner being native is crucial for real cross platform support.

I don't have the numbers, but why would anyone run Gitea on Windows instead of a server OS like Linux? I know it can run on Windows, but especially if you allow outside access you don't want a Windows machine connected to the "evil" internet.

Then again, I can understand the need for native runners for those who haven't containerized their services yet.

Linux servers are more popular over Windows server on the internet but there are many Enterprise Environments that reply on Active Directory stuff and and use Windows Servers, By the way my purpose was that among Gitea/Github/Gitlab, The Gitea is the only one support Deploying to Windows Servers. so all individuals or companies who stick with windows have no option but Gitea.

@yekanchi commented on GitHub (Jan 19, 2023): > > Great Job, I feel most of the people using Gitea over Gitlab and Github enterprise use it because it does not need Linux/WSL/docker stuff. Then I think actions runner being native is crucial for real cross platform support. > > I don't have the numbers, but why would anyone run Gitea on Windows instead of a server OS like Linux? I know it _can_ run on Windows, but especially if you allow outside access you don't want a Windows machine connected to the "evil" internet. > > Then again, I can understand the need for native runners for those who haven't containerized their services yet. Linux servers are more popular over Windows server on the internet but there are many Enterprise Environments that reply on Active Directory stuff and and use Windows Servers, By the way my purpose was that among Gitea/Github/Gitlab, The Gitea is the only one support Deploying to Windows Servers. so all individuals or companies who stick with windows have no option but Gitea.
GiteaMirror commented 2025-11-02 06:51:59 -06:00
Author
Owner
Copy Link

@ChristopherHX commented on GitHub (Jan 20, 2023):

Regarding absolute plugin address, please consider requiring to write a http:// / https:// prefix for absolute addess plugins.

Support absolute plugin address like uses: github.com/peaceiris/actions-hugo@v2

In my opinion is github.com/peaceiris/actions-hugo@v2 ambigious due to the following reasons:

  • For example the cache action (https://github.com/actions/cache/blob/main/restore/README.md) has child plugins in subfolders, which nektos/act does support.
    uses: actions/cache/restore@v3 is valid in github action, you cannot count slashes to resolve this parsing problem
  • Imagine you create a user or org called github.com, gitea (1.17.2, I'm too lazy to apply updates) doesn't forbid to use dot in names.
    What will happen if the DEFAULT_ACTION_URL is that gitea instance? I couldn't tell the difference of user github.com and a dns name.

I have no concerns regarding the following notation: uses: https://github.com/peaceiris/actions-hugo@v2, it's very uncommon to repeat a / in a uses statement and easy to parse.

@ChristopherHX commented on GitHub (Jan 20, 2023): Regarding absolute plugin address, please consider requiring to write a `http://` / `https://` prefix for absolute addess plugins. > Support absolute plugin address like uses: `github.com/peaceiris/actions-hugo@v2` In my opinion is `github.com/peaceiris/actions-hugo@v2` ambigious due to the following reasons: - For example the cache action (https://github.com/actions/cache/blob/main/restore/README.md) has child plugins in subfolders, which nektos/act does support. `uses: actions/cache/restore@v3` is valid in github action, you cannot count slashes to resolve this parsing problem - Imagine you create a user or org called `github.com`, gitea (1.17.2, I'm too lazy to apply updates) doesn't forbid to use dot in names. What will happen if the DEFAULT_ACTION_URL is that gitea instance? I couldn't tell the difference of user `github.com` and a dns name. I have no concerns regarding the following notation: uses: `https://github.com/peaceiris/actions-hugo@v2`, it's very uncommon to repeat a `/` in a uses statement and easy to parse.
GiteaMirror commented 2025-11-02 06:52:00 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (Jan 20, 2023):

@ChristopherHX those are very good points. To confirm, your suggestion is to treat anything that doesn't start with http/s as relative plugin to the default action url, but if it starts with http/s then use absolute? As I think that is a very reasonable suggestion.

@techknowlogick commented on GitHub (Jan 20, 2023): @ChristopherHX those are very good points. To confirm, your suggestion is to treat anything that doesn't start with http/s as relative plugin to the default action url, but if it starts with http/s then use absolute? As I think that is a very reasonable suggestion.
GiteaMirror commented 2025-11-02 06:52:00 -06:00
Author
Owner
Copy Link

@ChristopherHX commented on GitHub (Jan 20, 2023):

your suggestion is to treat anything that doesn't start with http/s as relative plugin to the default action url, but if it starts with http/s then use absolute?

Yes exactly.

@ChristopherHX commented on GitHub (Jan 20, 2023): > your suggestion is to treat anything that doesn't start with http/s as relative plugin to the default action url, but if it starts with http/s then use absolute? Yes exactly.
GiteaMirror commented 2025-11-02 06:52:00 -06:00
Author
Owner
Copy Link

@ragnaros2046 commented on GitHub (Jan 22, 2023):

Will Gitea CI support buildpacks? https://buildpacks.io/

Cloud Native Buildpacks
transform your application source code into images that can run on any cloud.

@ragnaros2046 commented on GitHub (Jan 22, 2023): Will Gitea CI support buildpacks? [https://buildpacks.io/](url) Cloud Native Buildpacks transform your application source code into images that can run on any cloud.
GiteaMirror commented 2025-11-02 06:52:00 -06:00
Author
Owner
Copy Link

@genofire commented on GitHub (Feb 25, 2023):

Why was not used the protocol between gitlab and there runner? this runner could be runned everywhere and start jobs in virtualbox, shell, kubernetes, docker ....

@genofire commented on GitHub (Feb 25, 2023): Why was not used the protocol between gitlab and there runner? this runner could be runned everywhere and start jobs in virtualbox, shell, kubernetes, docker ....
GiteaMirror commented 2025-11-02 06:52:01 -06:00
Author
Owner
Copy Link

@wolfogre commented on GitHub (Feb 27, 2023):

Why was not used the protocol between gitlab and there runner? this runner could be runned everywhere and start jobs in virtualbox, shell, kubernetes, docker ....

GitLab runners are designed for .gitlab-ci.yml, however, what Gitea wants is Actions.

@wolfogre commented on GitHub (Feb 27, 2023): > Why was not used the protocol between gitlab and there runner? this runner could be runned everywhere and start jobs in virtualbox, shell, kubernetes, docker .... GitLab runners are designed for [.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/), however, what Gitea wants is [Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions).
GiteaMirror commented 2025-11-02 06:52:01 -06:00
Author
Owner
Copy Link

@genofire commented on GitHub (Feb 27, 2023):

But for Actions does not exists an good runner, with service, running in kubernetes and so on.
Why has gitea the same API then github?

@genofire commented on GitHub (Feb 27, 2023): But for Actions does not exists an good runner, with `service`, running in kubernetes and so on. Why has gitea the same API then github?
GiteaMirror commented 2025-11-02 06:52:01 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Feb 28, 2023):

Why was not used the protocol between gitlab and there runner? this runner could be runned everywhere and start jobs in virtualbox, shell, kubernetes, docker ....

I think we can discuss the possibility of whether we can support that protocol and GitLab runners.

@lunny commented on GitHub (Feb 28, 2023): > Why was not used the protocol between gitlab and there runner? this runner could be runned everywhere and start jobs in virtualbox, shell, kubernetes, docker .... I think we can discuss the possibility of whether we can support that protocol and GitLab runners.
GiteaMirror commented 2025-11-02 06:52:01 -06:00
Author
Owner
Copy Link

@ChristopherHX commented on GitHub (Feb 28, 2023):

An overview how Gitea Actions are different compared to GitHub Actions, bugs are included.

From act side

  • concurrency is ignored
  • run-name is ignored
  • context availability is not checked, so you can use the env context on more places
  • service container not implemented Available in latest builds of act_runner (Update 19. April 2023, no release yet)
  • step summary not processed
  • problem matcher ignored
  • annotations ignored
  • no vars context (Work in Progress) (Update 19. April 2023)
  • incomplete github context
  • run steps on cancellation not implemented
  • depending if act_runner runs as a service a tty is present or not for container jobs, always a tty if supported on native runner (GitHub has never a tty available)
  • job.permissions block ignored
  • timeout-minutes ignored
  • job.continue-on-error ignored (idk what gitea is doing)
  • PATH of container / of act must contain node for nodejs actions, github runner has their own copy for both container and host
  • Openid Connect url is not defined
  • job.environment ignored and scoping secrets by deployment environment is not supported
  • No support for new runs-on syntax 
    runs-on: # Setting this to `{}` doesn't work reliable on github.com, an self-hosted runner may pick this up regardless of assigned labels or runner group
  labels: a, b # Optional
  group: somegroup # Optional

From gitea side

  • Job conditions are evaluated on the runner not on gitea
  • needs context not available (job results are not yet part of the protocol) (Work in Progress) (Update 19. April 2023)
  • only static matrix strategy, cannot use json from previous job output. I'm not shure if the expressions are evaluated, confirmed that only runs-on is evaluated on gitea side as of now
  • no reusable workflows (on act only partially implemented, not checked) partial reusable workflow support on the act_runner side (needs latest builds of gitea to pass with and secrets), GitHub does it on their server (Update 19. April 2023)
  • max job time for container jobs has a hardcoded limit below 6hours, native runner has no timeout
  • job cancellation request not sent to runner
  • step.ContinueOnError cannot be an expression, model is a copy in jobparser pkg of act fork

Non functional differences

  • pre and post steps don't have their own section in the job log ui
  • workflow (syntax) errors are not reported in the webui

Things gitea have github don't

  • absolute actions via http(s):// protocol, similar to docker://
  • go actions (GitHub requires to use composite actions to do the same)

This list has been originally posted in the gitea discord channel
EDIT last update 19. April 2023

@ChristopherHX commented on GitHub (Feb 28, 2023): An overview how Gitea Actions are different compared to GitHub Actions, bugs are included. ## From act side - concurrency is ignored - run-name is ignored - context availability is not checked, so you can use the env context on more places - ~~service container not implemented~~ Available in latest builds of act_runner (Update 19. April 2023, no release yet) - step summary not processed - problem matcher ignored - annotations ignored - no vars context (Work in Progress) (Update 19. April 2023) - incomplete github context - run steps on cancellation not implemented - depending if act_runner runs as a service a tty is present or not for container jobs, always a tty if supported on native runner (GitHub has never a tty available) - job.permissions block ignored - timeout-minutes ignored - job.continue-on-error ignored (idk what gitea is doing) - `PATH` of container / of act must contain `node` for nodejs actions, github runner has their own copy for both container and host - Openid Connect url is not defined - job.environment ignored and scoping secrets by deployment environment is not supported - No support for new `runs-on` syntax ```yaml runs-on: # Setting this to `{}` doesn't work reliable on github.com, an self-hosted runner may pick this up regardless of assigned labels or runner group labels: a, b # Optional group: somegroup # Optional ``` ## From gitea side - Job conditions are evaluated on the runner not on gitea - needs context not available (~~job results are not yet part of the protocol~~) (Work in Progress) (Update 19. April 2023) - only static matrix strategy, cannot use json from previous job output. I'm not shure if the expressions are evaluated, confirmed that only runs-on is evaluated on gitea side as of now - ~~no reusable workflows (on act only partially implemented, not checked)~~ partial reusable workflow support on the act_runner side (needs latest builds of gitea to pass with and secrets), GitHub does it on their server (Update 19. April 2023) - max job time for container jobs has a hardcoded limit below 6hours, native runner has no timeout - job cancellation request not sent to runner - `step.ContinueOnError` cannot be an expression, model is a copy in jobparser pkg of act fork ### Non functional differences - pre and post steps don't have their own section in the job log ui - workflow (syntax) errors are not reported in the webui ### Things gitea have github don't - absolute actions via `http(s)://` protocol, similar to `docker://` - go actions (GitHub requires to use composite actions to do the same) _This list has been originally posted in the gitea discord channel_ **EDIT last update 19. April 2023**
GiteaMirror commented 2025-11-02 06:52:01 -06:00
Author
Owner
Copy Link

@gnat commented on GitHub (Mar 10, 2023):

Encouraging for the "standardising on Actions" story for Gitea... from Django Developers Survey 2022.

I'm already converting many of my projects over for the Gitea transition to Actions.

image

@gnat commented on GitHub (Mar 10, 2023): Encouraging for the "standardising on Actions" story for Gitea... from Django Developers Survey 2022. I'm already converting many of my projects over for the Gitea transition to Actions. ![image](https://user-images.githubusercontent.com/24665/224265641-a38bc3c8-30a8-4b3f-a327-e0a6202aeb78.png)
GiteaMirror commented 2025-11-02 06:52:01 -06:00
Author
Owner
Copy Link

@newbenji commented on GitHub (Mar 10, 2023):

but you still need build it yourself to test it?

@newbenji commented on GitHub (Mar 10, 2023): but you still need build it yourself to test it?
GiteaMirror commented 2025-11-02 06:52:02 -06:00
Author
Owner
Copy Link

@balki commented on GitHub (Mar 20, 2023):

For a mirror repository, Will it be possible to use different action instead of the one in the original repository?

For example, lets say the github action in https://github.com/go-gitea/gitea compiles gitea when a new tag is created with TAGS="bindata sqlite sqlite_unlock_notify" make build.

I set up a mirror repository at https://git.mydomain.com/me/gitea and in my gitea action, I would like to it to compile without sqlite support, TAGS="bindata" make build.

For this to work, the config cannot be inside .github or .gitea folder as that will cause conflict with original repository. Instead, we can have in a custom branch called .gitea-actions-branch which only contains the yaml config file for 'gitea action'.

@balki commented on GitHub (Mar 20, 2023): For a mirror repository, Will it be possible to use different action instead of the one in the original repository? For example, lets say the github action in https://github.com/go-gitea/gitea compiles gitea when a new tag is created with `TAGS="bindata sqlite sqlite_unlock_notify" make build`. I set up a mirror repository at https://git.mydomain.com/me/gitea and in my gitea action, I would like to it to compile without sqlite support, `TAGS="bindata" make build`. For this to work, the config cannot be inside `.github` or `.gitea` folder as that will cause conflict with original repository. Instead, we can have in a custom branch called `.gitea-actions-branch` which only contains the yaml config file for 'gitea action'.
GiteaMirror commented 2025-11-02 06:52:02 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Mar 20, 2023):

For this to work, the config cannot be inside .github or .gitea folder as that will cause conflict with original repository. Instead, we can have in a custom branch called .gitea-actions-branch which only contains the yaml config file for 'gitea action'.

I think it would be nice to be able to select which folder to use for Gitea Actions via a global and project level flag, with the project level flag taking priority.

That way Gitea Actions can ignore the .github folder in favor of the .gitea folder.

@ghost commented on GitHub (Mar 20, 2023): > For this to work, the config cannot be inside `.github` or `.gitea` folder as that will cause conflict with original repository. Instead, we can have in a custom branch called `.gitea-actions-branch` which only contains the yaml config file for 'gitea action'. I think it would be nice to be able to select which folder to use for Gitea Actions via a global and project level flag, with the project level flag taking priority. That way Gitea Actions can ignore the `.github` folder in favor of the `.gitea` folder.
GiteaMirror commented 2025-11-02 06:52:02 -06:00
Author
Owner
Copy Link

@panekj commented on GitHub (Mar 20, 2023):

You can't modify files in mirrored repository.

For this to work, the config cannot be inside .github or .gitea folder as that will cause conflict with original repository. Instead, we can have in a custom branch called .gitea-actions-branch which only contains the yaml config file for 'gitea action'.

It will be better to have a event hook that will trigger actions in another repository, so mirror would trigger a hook, that hook triggers an actions run in another repository which will allow you to specify whatever you want.

@panekj commented on GitHub (Mar 20, 2023): You can't modify files in mirrored repository. > For this to work, the config cannot be inside `.github` or `.gitea` folder as that will cause conflict with original repository. Instead, we can have in a custom branch called `.gitea-actions-branch` which only contains the yaml config file for 'gitea action'. It will be better to have a event hook that will trigger actions in another repository, so mirror would trigger a hook, that hook triggers an actions run in another repository which will allow you to specify whatever you want.
GiteaMirror commented 2025-11-02 06:52:02 -06:00
Author
Owner
Copy Link

@nodiscc commented on GitHub (Mar 21, 2023):

Gitea 1.19.0 was released with the initial actions implementation, but I do not see any mention of it at https://docs.gitea.io/. So maybe a new task should be added to the checklist in the issue description?

  • Document Gitea actions setup and configuration
@nodiscc commented on GitHub (Mar 21, 2023): Gitea [1.19.0](https://github.com/go-gitea/gitea/releases/tag/v1.19.0) was released with the initial actions implementation, but I do not see any mention of it at https://docs.gitea.io/. So maybe a new task should be added to the checklist in the issue description? - Document Gitea actions setup and configuration
GiteaMirror commented 2025-11-02 06:52:02 -06:00
Author
Owner
Copy Link

@wizpresso-steve-cy-fan commented on GitHub (Mar 22, 2023):

It is also well noted we will also need to add Helm chart for act

@wizpresso-steve-cy-fan commented on GitHub (Mar 22, 2023): It is also well noted we will also need to add Helm chart for act
GiteaMirror commented 2025-11-02 06:52:03 -06:00
Author
Owner
Copy Link

@kbingham commented on GitHub (Mar 30, 2023):

For this to work, the config cannot be inside .github or .gitea folder as that will cause conflict with original repository. Instead, we can have in a custom branch called .gitea-actions-branch which only contains the yaml config file for 'gitea action'.

Being able to store the configuration in a custom branch would help a lot for adding automation to open source projects that don't want to have specific CI files added to the core repo. The linux kernel for instance.

@kbingham commented on GitHub (Mar 30, 2023): > For this to work, the config cannot be inside `.github` or `.gitea` folder as that will cause conflict with original repository. Instead, we can have in a custom branch called `.gitea-actions-branch` which only contains the yaml config file for 'gitea action'. Being able to store the configuration in a custom branch would help a lot for adding automation to open source projects that don't want to have specific CI files added to the core repo. The linux kernel for instance.
GiteaMirror commented 2025-11-02 06:52:03 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Mar 30, 2023):

For this to work, the config cannot be inside .github or .gitea folder as that will cause conflict with original repository. Instead, we can have in a custom branch called .gitea-actions-branch which only contains the yaml config file for 'gitea action'.

Being able to store the configuration in a custom branch would help a lot for adding automation to open source projects that don't want to have specific CI files added to the core repo. The linux kernel for instance.

Maybe we can have some options:

  1. .github/workflows or .gitea/workflows
  2. <repo_name>.actions.git like <repo_name>.wiki.git
  3. A setting of the repository to store multiple workflow files.
  4. A global workflows feature, which you can create a workflow to includes files and repositories.
@lunny commented on GitHub (Mar 30, 2023): > > For this to work, the config cannot be inside `.github` or `.gitea` folder as that will cause conflict with original repository. Instead, we can have in a custom branch called `.gitea-actions-branch` which only contains the yaml config file for 'gitea action'. > > Being able to store the configuration in a custom branch would help a lot for adding automation to open source projects that don't want to have specific CI files added to the core repo. The linux kernel for instance. Maybe we can have some options: 1) `.github/workflows` or `.gitea/workflows` 2) <repo_name>.actions.git like <repo_name>.wiki.git 3) A setting of the repository to store multiple workflow files. 4) A global workflows feature, which you can create a workflow to includes files and repositories.
GiteaMirror commented 2025-11-02 06:52:03 -06:00
Author
Owner
Copy Link

@siegenthalerroger commented on GitHub (Mar 30, 2023):

I actually really like the idea of having a seperate repo analogous to the wiki repository for this. Would be interesting to explore other functionality that could be implemented in this way.

@siegenthalerroger commented on GitHub (Mar 30, 2023): I actually really like the idea of having a seperate repo analogous to the wiki repository for this. Would be interesting to explore other functionality that could be implemented in this way.
GiteaMirror commented 2025-11-02 06:52:03 -06:00
Author
Owner
Copy Link

@kbingham commented on GitHub (Apr 1, 2023):

Yup now I've been exploring more, I can see a separated repo for the workflows could be a very helpful way of doing this too. Then multiple repos (mirrors, forks, or separate repos for separate developers) can point to common workflow actions.

@kbingham commented on GitHub (Apr 1, 2023): Yup now I've been exploring more, I can see a separated repo for the workflows could be a very helpful way of doing this too. Then multiple repos (mirrors, forks, or separate repos for separate developers) can point to common workflow actions.
GiteaMirror commented 2025-11-02 06:52:04 -06:00
Author
Owner
Copy Link

@dsseng commented on GitHub (Apr 8, 2023):

Maybe after artifact upload is done, basic code intelligence (not as powerful as SourceGraph, but just goto definitions/references + browse file symbols) could be implemented. After finishing builds/tests the action might do something like rust-analyzer lsif . and upload it as a special artifact Gitea will build navigation from. This approach gives the most detailed code navigation, just as in IDE using the same language server as used to generate LSIF. See https://lsif.dev/ for more details regarding the format.

Didn't open a new issue because of dependency on artifacts

@dsseng commented on GitHub (Apr 8, 2023): Maybe after artifact upload is done, basic code intelligence (not as powerful as SourceGraph, but just goto definitions/references + browse file symbols) could be implemented. After finishing builds/tests the action might do something like `rust-analyzer lsif .` and upload it as a special artifact Gitea will build navigation from. This approach gives the most detailed code navigation, just as in IDE using the same language server as used to generate LSIF. See https://lsif.dev/ for more details regarding the format. Didn't open a new issue because of dependency on artifacts
GiteaMirror commented 2025-11-02 06:52:04 -06:00
Author
Owner
Copy Link

@prologic commented on GitHub (Apr 10, 2023):

Are there any docs on built-in actions in 1.19.0? Even just a quick bullet point here in this thread? 🙏

@prologic commented on GitHub (Apr 10, 2023): Are there any docs on built-in actions in 1.19.0? Even just a quick bullet point here in this thread? 🙏
GiteaMirror commented 2025-11-02 06:52:04 -06:00
Author
Owner
Copy Link

@prologic commented on GitHub (Apr 10, 2023):

Answering my own question, getting this up and running with Gitea v1.19.0 (from upstream Docker images) was pretty straight forward:

  1. Add the following to your app.ini config (since if you're running an older version, it won't be there by default and disable by default?):
[actions]
ENABLED = true
  1. Restart Gitea
  2. Go to Site Administration -> Runners
  3. Create new Runner and Copy the token
  4. Setup and register a Runner
$ git clone https://gitea.com/gitea/act_runner.git
$ cd act_runner
$ make build
$ ./act_runner register
# follow the instructions
$ ./act_runner daemon

That's it! 🥳 Now just add workflows in .gitea/workflows/build.yml which use the same syntax as Github actions? (I guess so since the runner being used is the act_runner).

@prologic commented on GitHub (Apr 10, 2023): Answering my own question, getting this up and running with Gitea v1.19.0 (from upstream Docker images) was pretty straight forward: 1. Add the following to your `app.ini` config (since if you're running an older version, it won't be there by default and disable by default?): ```ini [actions] ENABLED = true ``` 2. Restart Gitea 3. Go to Site Administration -> Runners 4. Create new Runner and Copy the token 5. Setup and register a Runner ```console $ git clone https://gitea.com/gitea/act_runner.git $ cd act_runner $ make build $ ./act_runner register # follow the instructions $ ./act_runner daemon ``` That's it! 🥳 Now just add workflows in `.gitea/workflows/build.yml` which use the same syntax as Github actions? (I guess so since the runner being used is the `act_runner`).
GiteaMirror commented 2025-11-02 06:52:05 -06:00
Author
Owner
Copy Link

@prologic commented on GitHub (Apr 10, 2023):

Happy to continue beta testing this (I also run an older Drone CI setup too!) and provide feedback.

One thing that springs to mind (which I'm hoping one of the developers can answer):

  • How do I set-up Gitea + actions in a way where I can spawn runners on demand? (like Github does)

Basically, instead of having a static pool of runners (however I choose to run them), it would be nice to have a webhook (globally) that I can listen on and spawn a new runner on demand (say in a virtual machine or similar). Thanks! 🙏

@prologic commented on GitHub (Apr 10, 2023): Happy to continue beta testing this (I also run an older Drone CI setup too!) and provide feedback. One thing that springs to mind (which I'm hoping one of the developers can answer): - How do I set-up Gitea + actions in a way where I can spawn runners on demand? (like Github does) Basically, instead of having a static pool of runners (however I choose to run them), it would be nice to have a webhook (globally) that I can listen on and spawn a new runner on demand (say in a virtual machine or similar). Thanks! 🙏
GiteaMirror commented 2025-11-02 06:52:05 -06:00
Author
Owner
Copy Link

@aminify commented on GitHub (Apr 18, 2023):

Apparently in version 19.0.1 we should put something different in the app.ini file. Can someone help with that?
I put the below in it and actions weren't enabled. I used docker image by the way... I don't know if that's the source of issue. Really poor documentation so far...

[repo.actions]
ENABLED = true
@aminify commented on GitHub (Apr 18, 2023): Apparently in version 19.0.1 we should put something different in the `app.ini` file. Can someone help with that? I put the below in it and actions weren't enabled. I used docker image by the way... I don't know if that's the source of issue. Really poor documentation so far... ``` [repo.actions] ENABLED = true ```
GiteaMirror commented 2025-11-02 06:52:05 -06:00
Author
Owner
Copy Link

@jimafisk commented on GitHub (Apr 18, 2023):

@aminify I think it's just:

[actions]
ENABLED = true

https://docs.gitea.io/en-us/config-cheat-sheet/#actions-actions

@jimafisk commented on GitHub (Apr 18, 2023): @aminify I think it's just: ``` [actions] ENABLED = true ``` https://docs.gitea.io/en-us/config-cheat-sheet/#actions-actions
GiteaMirror commented 2025-11-02 06:52:05 -06:00
Author
Owner
Copy Link

@delvh commented on GitHub (Apr 18, 2023):

No, the cheatsheet is still true.
You simply misunderstood something here:
the key DEFAULT_REPO_UNITS/DEFAULT_FORK_REPO_UNITS in the [repository] section used the value actions instead of repo.actions.
The section to enable actions is [actions].

@delvh commented on GitHub (Apr 18, 2023): No, the cheatsheet is still true. You simply misunderstood something here: the key `DEFAULT_REPO_UNITS`/`DEFAULT_FORK_REPO_UNITS` in the [[repository]](https://docs.gitea.io/en-us/config-cheat-sheet/#repository-repository) section used the value `actions` instead of `repo.actions`. The section to enable actions is [[actions]](https://docs.gitea.io/en-us/config-cheat-sheet/#actions-actions).
GiteaMirror commented 2025-11-02 06:52:06 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Apr 18, 2023):

All units configuration should use repo.actions, but the ini section is [actions].

@lunny commented on GitHub (Apr 18, 2023): All units configuration should use `repo.actions`, but the ini section is `[actions]`.
GiteaMirror commented 2025-11-02 06:52:06 -06:00
Author
Owner
Copy Link

@RynoM commented on GitHub (Apr 18, 2023):

  • How do I set-up Gitea + actions in a way where I can spawn runners on demand? (like Github does)

This would be nice! I've been tinkering with using it to deploy/restart my docker services. Would be nice if it could just do dynamic generation / access from outside for runner tokens. That way the container is more ephemeral.

Also its probably been said before, but an environment variable for enabling actions would be nice, instead of having to update app.ini.

@RynoM commented on GitHub (Apr 18, 2023): > * How do I set-up Gitea + actions in a way where I can spawn runners on demand? (like Github does) This would be nice! I've been [tinkering with using it](https://github.com/RynoM/self-hosted-deployment) to deploy/restart my docker services. Would be nice if it could just do dynamic generation / access from outside for runner tokens. That way the container is more ephemeral. Also its probably been said before, but an environment variable for enabling actions would be nice, instead of having to update `app.ini`.
GiteaMirror commented 2025-11-02 06:52:06 -06:00
Author
Owner
Copy Link

@aminify commented on GitHub (Apr 19, 2023):

I have setup the runner and everything and I have a docker build command to run in my action. Unfortunately I get /var/run/act/workflow/1: line 2: docker: command not found. Anyone knows the best way to enable docker inside the runner?

@aminify commented on GitHub (Apr 19, 2023): I have setup the runner and everything and I have a `docker build` command to run in my action. Unfortunately I get `/var/run/act/workflow/1: line 2: docker: command not found`. Anyone knows the best way to enable docker inside the runner?
GiteaMirror commented 2025-11-02 06:52:07 -06:00
Author
Owner
Copy Link

@panekj commented on GitHub (Apr 19, 2023):

I have setup the runner and everything and I have a docker build command to run in my action. Unfortunately I get /var/run/act/workflow/1: line 2: docker: command not found. Anyone knows the best way to enable docker inside the runner?

You need to install it or use a docker image runner that has it installed

@panekj commented on GitHub (Apr 19, 2023): > I have setup the runner and everything and I have a `docker build` command to run in my action. Unfortunately I get `/var/run/act/workflow/1: line 2: docker: command not found`. Anyone knows the best way to enable docker inside the runner? You need to install it or use a docker image runner that has it installed
GiteaMirror commented 2025-11-02 06:52:07 -06:00
Author
Owner
Copy Link

@aminify commented on GitHub (Apr 20, 2023):

thanks @panekj
for others facing the same issue. I managed to fix this docker: command not found issue using ubuntu-latest:docker://catthehacker/ubuntu:act-22.04 as label argument for act-runner (in register phase)

@aminify commented on GitHub (Apr 20, 2023): thanks @panekj for others facing the same issue. I managed to fix this `docker: command not found` issue using `ubuntu-latest:docker://catthehacker/ubuntu:act-22.04` as label argument for `act-runner` (in register phase)
GiteaMirror commented 2025-11-02 06:52:07 -06:00
Author
Owner
Copy Link

@sorenisanerd commented on GitHub (Apr 21, 2023):

Another missing part of Gitea's implementation of Github Actions is workflow commands in general, but most critically the add-mask command. My logs are riddled with secrets that anyone can see and steal.

@sorenisanerd commented on GitHub (Apr 21, 2023): Another missing part of Gitea's implementation of Github Actions is workflow commands in general, but most critically the `add-mask` command. My logs are riddled with secrets that anyone can see and steal.
GiteaMirror commented 2025-11-02 06:52:07 -06:00
Author
Owner
Copy Link

@prologic commented on GitHub (Apr 21, 2023):

Another missing part of Gitea's implementation of Github Actions is workflow commands in general, but most critically the add-mask command. My logs are riddled with secrets that anyone can see and steal.

Wait?! Why are you logging secrets in the first place? 🤔

@prologic commented on GitHub (Apr 21, 2023): > Another missing part of Gitea's implementation of Github Actions is workflow commands in general, but most critically the `add-mask` command. My logs are riddled with secrets that anyone can see and steal. Wait?! Why are you logging secrets in the first place? 🤔
GiteaMirror commented 2025-11-02 06:52:07 -06:00
Author
Owner
Copy Link

@vquie commented on GitHub (Apr 21, 2023):

Another missing part of Gitea's implementation of Github Actions is workflow commands in general, but most critically the add-mask command. My logs are riddled with secrets that anyone can see and steal.

I can confirm this. I use the 1password action to retrieve passwords. They are logged in all their beauty. Their code says add-mask though.

@vquie commented on GitHub (Apr 21, 2023): > Another missing part of Gitea's implementation of Github Actions is workflow commands in general, but most critically the `add-mask` command. My logs are riddled with secrets that anyone can see and steal. I can confirm this. I use the 1password action to retrieve passwords. They are logged in all their beauty. Their code says `add-mask` though.
GiteaMirror commented 2025-11-02 06:52:08 -06:00
Author
Owner
Copy Link

@JakobDev commented on GitHub (Apr 21, 2023):

Wait?! Why are you logging secrets in the first place?

There are Programs who print API Keys for debug reasons with no Way to disable it. It also possible, that this may be leaked in a error message when something crashes, so it's generally a good Idea to mask this, just in case.

@JakobDev commented on GitHub (Apr 21, 2023): > Wait?! Why are you logging secrets in the first place? There are Programs who print API Keys for debug reasons with no Way to disable it. It also possible, that this may be leaked in a error message when something crashes, so it's generally a good Idea to mask this, just in case.
GiteaMirror commented 2025-11-02 06:52:08 -06:00
Author
Owner
Copy Link

@kbingham commented on GitHub (Apr 21, 2023):

Yup now I've been exploring more, I can see a separated repo for the workflows could be a very helpful way of doing this too. Then multiple repos (mirrors, forks, or separate repos for separate developers) can point to common workflow actions.

FWIW - Today I discovered gitlab can do this and it's all documented here:

@kbingham commented on GitHub (Apr 21, 2023): > Yup now I've been exploring more, I can see a separated repo for the workflows could be a very helpful way of doing this too. Then multiple repos (mirrors, forks, or separate repos for separate developers) can point to common workflow actions. FWIW - Today I discovered gitlab can do this and it's all documented here: - https://docs.gitlab.com/ee/ci/pipelines/settings.html#specify-a-custom-cicd-configuration-file - https://gitlab.com/gitlab-org/gitlab/-/issues/14376
GiteaMirror commented 2025-11-02 06:52:08 -06:00
Author
Owner
Copy Link

@prologic commented on GitHub (Apr 21, 2023):

Wait?! Why are you logging secrets in the first place?

There are Programs who print API Keys for debug reasons with no Way to disable it. It also possible, that this may be leaked in a error message when something crashes, so it's generally a good Idea to mask this, just in case.

Those programs should be loaded up on a rocket and shot into sun! 😆 talk about security law practice 🤦‍♂️

@prologic commented on GitHub (Apr 21, 2023): > > Wait?! Why are you logging secrets in the first place? > > > > There are Programs who print API Keys for debug reasons with no Way to disable it. It also possible, that this may be leaked in a error message when something crashes, so it's generally a good Idea to mask this, just in case. Those programs should be loaded up on a rocket and shot into sun! 😆 talk about security law practice 🤦‍♂️
GiteaMirror commented 2025-11-02 06:52:08 -06:00
Author
Owner
Copy Link

@delvh commented on GitHub (Apr 30, 2023):

I wonder how much more we want to abuse this one issue?
As far as I'm concerned the basic functionality exists, and the remains should be extracted into separate issues.
I don't think it's good that this issue is still open despite the main functionality being implemented already.
Issues should focus on one specific thing, otherwise they'll be pretty much never closed.

@delvh commented on GitHub (Apr 30, 2023): I wonder how much more we want to abuse this one issue? As far as I'm concerned the basic functionality exists, and the remains should be extracted into separate issues. I don't think it's good that this issue is still open despite the main functionality being implemented already. Issues should focus on one specific thing, otherwise they'll be pretty much never closed.
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 topic/gitea-actions type/proposal type/summary
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#6306
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?