mirror of
https://gitea.com/gitea/blog.git
synced 2024-06-02 04:01:24 +05:30
This commit is contained in:
Jason Song
parent
7b74926c43
commit
8e03b6a346
|
|
@ -6,21 +6,25 @@ tags: ["actions"]
|
|||
draft: false
|
||||
---
|
||||
|
||||
A few days ago, we released Gitea 1.19.0, which includes a new feature called Gitea Actions. This is a built-in CI system of Gitea, similar and compatible to GitHub Actions.
|
||||
Gitea 1.19.0 includes a new feature called Gitea Actions. This is a built-in CI system of Gitea, similar and compatible to GitHub Actions.
|
||||
|
||||
This blog will explain some details of Gitea Actions, not only about how to use it, but also about how it works. Therefore, it will be divided into two parts: usage and design. It should be noted that the information presented pertains to the current situation, and some of it may become outdated in the future.
|
||||
This blog will explain some details about Gitea Actions, including how to use it and how it works.
|
||||
It should be noted that the information presented pertains to the current situation, and may become outdated in the future.
|
||||
|
||||
<!--more-->
|
||||
|
||||
## Usage
|
||||
|
||||
In [Feature Preview: Gitea Actions](https://blog.gitea.io/2022/12/feature-preview-gitea-actions/), we discussed how to try it out. However, as development progressed, some descriptions became inapplicable. Therefore, let's go over them again.
|
||||
In [Feature Preview: Gitea Actions](https://blog.gitea.io/2022/12/feature-preview-gitea-actions/), we discussed how to try it out.
|
||||
However, some things have changed since then, so let's go over it again.
|
||||
|
||||
### Set up Gitea
|
||||
|
||||
First of all, you should have a Gitea instance with a version of 1.19 or higher. You can follow the [documentation](https://docs.gitea.io/en-us/) to set up a new instance or upgrade your existing one. It doesn't matter how you run Gitea if you want to enable Actions.
|
||||
First of all, you need a Gitea instance with a version of 1.19.0 or higher.
|
||||
You can follow the [documentation](https://docs.gitea.io/en-us/) to set up a new instance or upgrade your existing one.
|
||||
It doesn't matter how you run Gitea if you want to enable Actions.
|
||||
|
||||
Actions are disabled by default, so you need to add extra configuration to the configuration file to enable it. The minimum change you should make is to add the following:
|
||||
Actions are disabled by default (as they are still an feature-in-progress), so you need to add the following to the configuration file to enable it:
|
||||
|
||||
```ini
|
||||
[actions]
|
||||
|
|
@ -31,13 +35,18 @@ If you want to learn more or encounter any problems while configuring it, please
|
|||
|
||||
### Set up runner
|
||||
|
||||
We have a basic implementation of a Gitea Actions runner called act runner. It is based on the act project.
|
||||
We have a basic implementation of a Gitea Actions runner called [act runner](https://gitea.com/gitea/act_runner).
|
||||
It is based on the [act](https://github.com/nektos/act) project.
|
||||
|
||||
Currently, we do not offer a Docker image or RPM package to install a runner yet. Instead, you can either compile the runner from source or download a pre-built binary from [dl.gitea.com/act_runner](http://dl.gitea.com/act_runner), and then run it as a command line. You can also wrap it with something like a system service, supervisord, or Docker container.
|
||||
Currently, the only way to install act runner is by compiling it yourself, or by using one of the [pre-built binaries](http://dl.gitea.com/act_runner).
|
||||
There is no Docker image or other type of package management yet.
|
||||
At the moment, act runner should be run from the command line.
|
||||
Of course, you can also wrap this binary in something like a system service, supervisord, or Docker container.
|
||||
|
||||
Before proceeding any further, I suggest running it as a command line to ensure that it works with your environment, especially if you are running a runner on your local host. By the way, to avoid consuming too many resources and affecting the Gitea instance, it is recommended to start runners on separate machines from the Gitea instance.
|
||||
Before proceeding any further, we suggest running it as a command line to ensure that it works with your environment, especially if you are running a runner on your local host.
|
||||
In order to avoid consuming too many resources and affecting the Gitea instance, it is also recommended to start runners on separate machines from the Gitea instance.
|
||||
|
||||
Also, make sure that Docker is installed. While it is not strictly necessary, it is common practice. We will discuss this later.
|
||||
Also, make sure that Docker is installed. While it is not strictly necessary, it is common usage. We will discuss this later.
|
||||
|
||||
Before running a runner, you should first register it to your Gitea instance using the following command:
|
||||
|
||||
|
|
@ -45,17 +54,20 @@ Before running a runner, you should first register it to your Gitea instance usi
|
|||
./act_runner register --no-interactive --instance <instance> --token <token>
|
||||
```
|
||||
|
||||
There are two arguments required, `instance` and `token` .
|
||||
There are two arguments required, `instance` and `token`.
|
||||
|
||||
`instance` refers to the address of your Gitea instance, like `http://192.168.8.8:3000` or `https://gitea.com` . The runner and job containers (which are started by the runner to execute jobs) will connect to this address. This means that it could be different from the `ROOT_URL` of your Gitea instance, which is configured for web access. It is always a bad idea to use a loopback address such as `127.0.0.1` or `localhost`. We will discuss the reason later. If you are unsure which address to use, the LAN address is usually the right choice.
|
||||
`instance` refers to the address of your Gitea instance, like `http://192.168.8.8:3000` or `https://gitea.com`.
|
||||
The runner and job containers (which are started by the runner to execute jobs) will connect to this address.
|
||||
This means that it could be different from the `ROOT_URL` of your Gitea instance, which is configured for web access. It is always a bad idea to use a loopback address such as `127.0.0.1` or `localhost`, as we will discuss later. If you are unsure which address to use, the LAN address is usually the right choice.
|
||||
|
||||
`token` is used for authentication and identification, such as `P2U1U0oB4XaRCi8azcngmPCLbRpUGapalhmddh23`. It is for one-time use only and cannot be used to register multiple runners. You can obtain tokens from `your_gitea.com/admin/runners`.
|
||||
`token` is used for authentication and identification, such as `P2U1U0oB4XaRCi8azcngmPCLbRpUGapalhmddh23`. It is one-time use only and cannot be used to register multiple runners.
|
||||
You can obtain tokens from `your_gitea.com/admin/runners`.
|
||||
|
||||
|
||||
|
||||
If you cannot find this page, it is probably because you have a wrong version of Gitea or have not enabled Actions. Please check the steps above.
|
||||
If you cannot find this page, it is likely that you have a wrong version of Gitea or have not enabled Actions. Please check the steps above.
|
||||
|
||||
After registering, a new file named `.runner` will appear in the current directory. This file stores the registration information. Please do not edit it unless you know what you are doing. If this file is missing or corrupted, you can simply remove it and register again.
|
||||
After registering, a new file named `.runner` will appear in the current directory. This file stores the registration information. Please do not edit it manually. If this file is missing or corrupted, you can simply remove it and register again.
|
||||
|
||||
Finally, it's time to start the runner.
|
||||
|
||||
|
|
@ -71,13 +83,14 @@ You can find more information by visiting [gitea/act_runner](https://gitea.com/g
|
|||
|
||||
### Use Actions
|
||||
|
||||
Even if Actions is enabled for the Gitea instance, the repository still has Actions disabled by default.
|
||||
Even if Actions is enabled for the Gitea instance, repositories still disable Actions by default.
|
||||
|
||||
To enable it, go to the settings page of your repository and check it on:
|
||||
To enable it, go to the settings page of your repository and enable it:
|
||||
|
||||
|
||||
|
||||
The next steps may be rather complicated. You will need to study [the workflow syntax](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) for Actions and write the workflow files you want.
|
||||
The next steps may be rather complicated.
|
||||
You will need to study [the workflow syntax](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) for Actions and write the workflow files you want.
|
||||
|
||||
However, we can just start from a simple demo:
|
||||
|
||||
|
|
@ -102,7 +115,9 @@ jobs:
|
|||
- run: echo "🍏 This job's status is ${{ gitea.status }}."
|
||||
```
|
||||
|
||||
You can upload it as a file with the extension `.yaml` in the directory `.gitea/workflows/` of the repository, perhaps `.gitea/workflows/demo.yaml`. You may notice that this is almost copied from [Quickstart for GitHub Actions](https://docs.github.com/en/actions/quickstart), yes, Gitea Actions is designed to be compatible with GitHub Actions.
|
||||
You can upload it as a file with the extension `.yaml` in the directory `.gitea/workflows/` of the repository, for example `.gitea/workflows/demo.yaml`.
|
||||
You might notice that this is fairly similar from the [Quickstart for GitHub Actions](https://docs.github.com/en/actions/quickstart).
|
||||
That is because Gitea Actions is designed to be compatible with GitHub Actions wherever possible.
|
||||
|
||||
Be careful, the demo file contains some emojis. Please make sure your database supports them, especially when using MySQL. If the charset is not `utf8mb4`, errors will occur, such as `Error 1366 (HY000): Incorrect string value: '\\xF0\\x9F\\x8E\\x89 T...' for column 'name' at row 1`. See [Database Preparation](https://docs.gitea.io/en-us/database-prep/#mysql). Alternatively, you can use this demo without emojis:
|
||||
|
||||
|
|
@ -131,17 +146,20 @@ The line `on: [push]` indicates that the workflow will be triggered when you pus
|
|||
|
||||
|
||||
|
||||
Great job! You have successfully understood working with Actions. And there are some Q&As for this part.
|
||||
Great job! You have successfully started working with Actions.
|
||||
|
||||
### Q&A
|
||||
|
||||
#### Why is Actions not enabled by default?
|
||||
|
||||
I know it's annoying to enable Actions for the whole instance and each repository one by one, but not everyone likes or needs this feature. I believe that more work needs to be done to improve Gitea Actions before it deserves any further special treatment.
|
||||
We know it's annoying to enable Actions for the whole instance and each repository one by one, but not everyone likes or needs this feature. We believe that more work needs to be done to improve Gitea Actions before it deserves any further special treatment.
|
||||
|
||||
#### Should we use `${{ github.xxx }}` or `${{ gitea.xxx }}` in workflow files?
|
||||
#### Should we use `${{ github.xyz }}` or `${{ gitea.xyz }}` in workflow files?
|
||||
|
||||
You can use `github.xxx` and Gitea will work fine. As I mentioned, Gitea Actions is designed to be compatible with GitHub Actions. Alternatively, you can use `gitea.xxx` to match Gitea's style. However, this is entirely optional since both options have the same effect.
|
||||
You can use `github.xyz` and Gitea will work fine.
|
||||
As mentioned, Gitea Actions is designed to be compatible with GitHub Actions.
|
||||
However, we recommend using `gitea.xyz` in case Gitea adds something that GitHub does not have to avoid different kinds of secrets in your workflow file (and because you are using this workflow on Gitea, not GitHub).
|
||||
Still, this is completely optional since both options have the same effect at the moment.
|
||||
|
||||
#### Is it possible to register runners for a specific organization or a repository?
|
||||
|
||||
|
|
@ -167,44 +185,49 @@ For example, `runs-on: ubuntu-latest` in a workflow file means that the job will
|
|||
|
||||
#### Where will the runner download scripts when using actions such as `actions/checkout@v3`?
|
||||
|
||||
You may be aware that there are tens of thousands of [actions](https://github.com/marketplace?type=actions) in GitHub. However, when you write `uses: actions/checkout@v3`, it actually downloads the scripts from [gitea.com/actions/checkout](http://gitea.com/actions/checkout) by default (not GitHub). This is a mirror of [github.com/actions/checkout](http://github.com/actions/checkout), but it's impossible to mirror all of them. That's why you may encounter failures when trying to use some actions that haven't been mirrored.
|
||||
You may be aware that there are tens of thousands of [marketplace actions](https://github.com/marketplace?type=actions) in GitHub.
|
||||
However, when you write `uses: actions/checkout@v3`, it actually downloads the scripts from [gitea.com/actions/checkout](http://gitea.com/actions/checkout) by default (not GitHub).
|
||||
This is a mirror of [github.com/actions/checkout](http://github.com/actions/checkout), but it's impossible to mirror all of them. That's why you may encounter failures when trying to use some actions that haven't been mirrored.
|
||||
|
||||
The good news is that you can specify the URL prefix to use any actions in any place. This is an extra syntax in Gitea Actions. For example:
|
||||
The good news is that you can specify the URL prefix to use actions from anywhere.
|
||||
This is an extra syntax in Gitea Actions. For example:
|
||||
|
||||
- `uses: https://github.com/xxx/xxx@xxx`
|
||||
- `uses: https://gitea.com/xxx/xxx@xxx`
|
||||
- `uses: http://your_gitea_instance.com/xxx@xxx`
|
||||
|
||||
Be careful, the `https://` or `http://` prefix is necessary.
|
||||
Be careful, the `https://` or `http://` prefix is necessary!
|
||||
|
||||
Alternatively, if you want your runners to download actions from GitHub or your own Gitea instance by default, you can configure it by setting `DEFAULT_ACTIONS_URL`. See [Configuration Cheat Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/#actions-actions).
|
||||
Alternatively, if you want your runners to download actions from GitHub or your own Gitea instance by default, you can configure it by setting `[actions].DEFAULT_ACTIONS_URL`. See [Configuration Cheat Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/#actions-actions).
|
||||
|
||||
This is one of the differences from GitHub Actions, but it should allow users much more flexibility in how they run Actions.
|
||||
|
||||
#### How to limit the permission of the runners?
|
||||
|
||||
In fact, runners have no more permissions than simply connecting to your Gitea instance. And when any runner receives a job to run, it will temporarily gain limited permission to the repository associated with the job. If you want to give more permissions to the runner, allowing it to access more private repositories or external systems, you can pass [secrets](https://github.com/go-gitea/gitea/pull/22142) to it.
|
||||
Runners have no more permissions than simply connecting to your Gitea instance. When any runner receives a job to run, it will temporarily gain limited permission to the repository associated with the job. If you want to give more permissions to the runner, allowing it to access more private repositories or external systems, you can pass [secrets](https://docs.gitea.io/en-us/usage/secrets/) to it.
|
||||
|
||||
Refined permission control to Actions is a complicated job. In the future, we will add more options to Gitea to make it more configurable, such as allowing more write access to repositories or read access to all repositories in the same organization.
|
||||
|
||||
#### How to avoid being hacked?
|
||||
|
||||
There are two types of attacks: unknown runner stealing the code or secrets from your repository, or malicious scripts controlling your runner.
|
||||
There are two types of possible attacks: unknown runner stealing the code or secrets from your repository, or malicious scripts controlling your runner.
|
||||
|
||||
It's easy to avoid the former. Simply don't allow people you don't know to register runners for your repository, organization, or instance.
|
||||
Avoiding the former means not allowing people you don't know to register runners for your repository, organization, or instance.
|
||||
|
||||
The latter is a complex topic. In my opinion, it's always possible to hack a server if you can execute scripts on it without limitations.
|
||||
The latter is a bit more complicated.
|
||||
If you're using a private Gitea instance for your company, you may not need to worry about security since you trust your colleagues and can hold them accountable.
|
||||
|
||||
If you're using a private Gitea instance for your company, you may not need to worry about security since you trust your colleagues. And you can hold them accountable if anyone does something bad.
|
||||
|
||||
For public instances, things can get a little complicated. Let me show you how we do it in [gitea.com](http://gitea.com/):
|
||||
For public instances, things are a little different.
|
||||
Here's how we do it on [gitea.com](http://gitea.com/):
|
||||
|
||||
- We only register runners for the "gitea" organization, so our runners will not execute jobs from other repositories.
|
||||
- Our runners always run jobs with isolated containers. While it is possible to do this directly on the host, we will discuss this later.
|
||||
- Our runners always run jobs with isolated containers. While it is possible to do this directly on the host, we choose not to for more security.
|
||||
- To run actions for fork pull requests, approval is required. See [#22803](https://github.com/go-gitea/gitea/pull/22803).
|
||||
- If someone registers their own runner for their repository or organization on [gitea.com](http://gitea.com/), we have no objections and will not use it. However, they should take care to ensure that the runner is not used by other users they do not know.
|
||||
- If someone registers their own runner for their repository or organization on [gitea.com](http://gitea.com/), we have no objections and will just not use it in our org. However, they should take care to ensure that the runner is not used by other users they do not know.
|
||||
|
||||
## Design
|
||||
|
||||
Gitea Actions has multiple parts. Let's explain them one by one. It's a long story.
|
||||
Gitea Actions has multiple parts. Let's explain them one by one.
|
||||
|
||||
### Act
|
||||
|
||||
|
|
@ -214,7 +237,7 @@ However, while [nektos/act](https://github.com/nektos/act) is designed as a comm
|
|||
|
||||
This is a soft fork that will periodically follow the upstream. Although some custom commits have been added, we will try our best to avoid changing too much of the original code.
|
||||
|
||||
The forked act is just a shim or adapter for specific usage of Gitea. There are some additional commits that have been made, such as:
|
||||
The forked act is just a shim or adapter for Gitea's specific usage. There are some additional commits that have been made, such as:
|
||||
|
||||
- Outputting execution logs to logger hook so they can be reported to Gitea
|
||||
- Disabling the GraphQL URL, since Gitea doesn't support it
|
||||
|
|
@ -226,15 +249,19 @@ However, there may be overlaps in the future, such as a required bug fix or new
|
|||
|
||||
### Act runner
|
||||
|
||||
So now you know why Gitea's runner is called act runner, because it's based on act.
|
||||
Gitea's runner is called act runner because it's based on act.
|
||||
|
||||
Like other CI runners, we design it as an external part of Gitea, which means it should run on a different server than Gitea.
|
||||
Like other CI runners, we designed it as an external part of Gitea, which means it should run on a different server than Gitea.
|
||||
|
||||
To ensure that the runner connects to the correct Gitea instance, we need to register it with a token. Additionally, the runner will introduce itself to Gitea and declare what kind of jobs it can run by reporting its labels.
|
||||
|
||||
Earlier, we mentioned that `runs-on: ubuntu-latest` in a workflow file means that the job will be run on a runner with the `ubuntu-latest` label. But how does the runner know to run `ubuntu-latest`? The answer lies in mapping the label to an environment. That's why when you add custom labels during registration, you should input some complex content like `my_custom_label:docker://centos:7`. This means that the runner can take the job which needs to run on `my_custom_label`, and it will run it via a docker container with the image `centos:7`.
|
||||
Earlier, we mentioned that `runs-on: ubuntu-latest` in a workflow file means that the job will be run on a runner with the `ubuntu-latest` label.
|
||||
But how does the runner know to run `ubuntu-latest`? The answer lies in mapping the label to an environment.
|
||||
That's why when you add custom labels during registration, you will need to input some complex content like `my_custom_label:docker://centos:7`.
|
||||
This means that the runner can take the job which needs to run on `my_custom_label`, and it will run it via a docker container with the image `centos:7`.
|
||||
|
||||
In fact, Docker is not the only option. act also supports running jobs directly on the host. This is achieved through labels like `linux_arm:host`. This label indicates that the runner can take a job that needs to run on `linux_arm` and run it directly on the host.
|
||||
Docker isn't the only option, though. The act also supports running jobs directly on the host.
|
||||
This is achieved through labels like `linux_arm:host`. This label indicates that the runner can take a job that needs to run on `linux_arm` and run it directly on the host.
|
||||
|
||||
The label's design follows the format `label[:schema[:args]]`. If the schema is omitted, it defaults to `host`. So,
|
||||
|
||||
|
|
@ -245,15 +272,17 @@ The label's design follows the format `label[:schema[:args]]`. If the schema is
|
|||
|
||||
### Communication protocol
|
||||
|
||||
As act runner is an independent part of Gitea, we need a protocol for runners to communicate with the Gitea instance. However, we do not think it is a good idea to have Gitea listen on a new port. Instead, we should reuse the HTTP port. This means we should use a protocol that is compatible with HTTP. Therefore, we use gRPC over HTTP.
|
||||
As act runner is an independent part of Gitea, we needed a protocol for runners to communicate with the Gitea instance.
|
||||
However, we did not think it was a good idea to have Gitea listen on a new port.
|
||||
Instead, we wanted to reuse the HTTP port, which means we needed a protocol that is compatible with HTTP.
|
||||
We chose to use gRPC over HTTP.
|
||||
|
||||
And then there's [actions-proto-def](https://gitea.com/gitea/actions-proto-def) and [actions-proto-go](https://gitea.com/gitea/actions-proto-go). If you are familiar with gRPC, you should know what they are for. I won't go into the details here. It doesn't really matter. They just provide a way to make communication easier.
|
||||
|
||||
To be honest, I cannot answer why we couldn't use the original HTTP or WebSocket protocols. However, I can say that gRPC saved us some time early on in the project. If you come up with a better solution one day, I think we can easily switch to it and abandon the old one.
|
||||
We use [actions-proto-def](https://gitea.com/gitea/actions-proto-def) and [actions-proto-go](https://gitea.com/gitea/actions-proto-go) to wire them up. More information about gRPC can be found on [its website](https://grpc.io/).
|
||||
|
||||
### Network architecture
|
||||
|
||||
Let's examine the overall network architecture. This will help you troubleshoot some problems and explain why it's a bad idea to register a runner with a loopback address of the Gitea instance.
|
||||
Let's examine the overall network architecture.
|
||||
This will help you troubleshoot some problems and explain why it's a bad idea to register a runner with a loopback address of the Gitea instance.
|
||||
|
||||
|
||||
|
||||
|
|
@ -265,47 +294,57 @@ The act runner must be able to connect to Gitea to receive tasks and send back t
|
|||
|
||||
#### Connection 2, job containers to Gitea instance
|
||||
|
||||
The job containers have different network namespaces than the runner, even if they are on the same machine. They need to connect to Gitea to fetch codes if there is `actions/checkout@v3` in the workflow. Fetching code is not always necessary to run some jobs, but it is required in most cases.
|
||||
The job containers have different network namespaces than the runner, even if they are on the same machine. They need to connect to Gitea to fetch codes if there is `actions/checkout@v3` in the workflow, for example. Fetching code is not always necessary to run some jobs, but it is required in most cases.
|
||||
|
||||
If you use a loopback address to register a runner, the runner can connect to Gitea when it is on the same machine. However, if a job container tries to fetch code from localhost, it will fail because Gitea is not in the same container.
|
||||
If you use a loopback address to register a runner, the runner can connect to Gitea when it is on the same machine.
|
||||
However, if a job container tries to fetch code from localhost, it will fail because Gitea is not in the same container.
|
||||
|
||||
#### Connection 3, act runner to internet
|
||||
|
||||
When you use some actions like `actions/checkout@v3`, the act runner downloads the scripts, not the job containers. By default, it downloads from [gitea.com](http://gitea.com/), so it requires access to the Internet. It also downloads some docker images from Docker Hub by default, which also requires Internet access.
|
||||
When you use some actions like `actions/checkout@v3`, the act runner downloads the scripts, not the job containers.
|
||||
By default, it downloads from [gitea.com](http://gitea.com/), so it requires access to the internet.
|
||||
It also downloads some docker images from Docker Hub by default, which also requires internet access.
|
||||
|
||||
However, internet access is not strictly necessary.
|
||||
You can configure your Gitea instance to fetch actions or images from your intranet facilities.
|
||||
In fact, your Gitea instance can serve as both the actions marketplace and the image registry.
|
||||
<!-- TODO: how? https://discord.com/channels/322538954119184384/323701541297192961/1088945511639289937 -->
|
||||
|
||||
However, Internet access is not strictly necessary. You can configure your Gitea instance to fetch actions or images from your intranet facilities. In fact, your Gitea instance can serve as both the actions marketplace and the image registry.
|
||||
|
||||
#### Connection 4, job containers to internet
|
||||
|
||||
When using actions such as `actions/setup-go@v4`, it may be necessary to download resources from the internet to set up the Go language environment in job containers. Therefore, access to the internet is required for the successful completion of these actions.
|
||||
|
||||
However, I would say that it is also optional. You can use your own custom actions to avoid relying on internet access, or you can use your packaged Docker image to run jobs with all dependencies installed.
|
||||
However, it is optional as well. You can use your own custom actions to avoid relying on internet access, or you can use your packaged Docker image to run jobs with all dependencies installed.
|
||||
|
||||
#### Summary
|
||||
|
||||
In summary, using Gitea Actions only requires ensuring that the runner can connect to the Gitea instance. Internet access is optional, but not having it will require some additional work.
|
||||
Using Gitea Actions only requires ensuring that the runner can connect to the Gitea instance.
|
||||
Internet access is optional, but not having it will require some additional work.
|
||||
In other words: The runner works best when it can query the internet itself, but you don't need to expose it to the internet (in either direction).
|
||||
|
||||
If you encounter any network issues while using Gitea Actions, I hope the picture above can help you troubleshoot them.
|
||||
If you encounter any network issues while using Gitea Actions, hopefully the image above can help you troubleshoot them.
|
||||
|
||||
### Q&A
|
||||
|
||||
#### Why are we keen on GitHub Actions? Why not something compatible with GitLab CI/CD?
|
||||
#### Why choose GitHub Actions? Why not something compatible with GitLab CI/CD?
|
||||
|
||||
Lunny has explained this in [#13539](https://github.com/go-gitea/gitea/issues/13539), and I think the point is that Actions is not only a CI/CD system but also an automated tool.
|
||||
[@lunny](https://gitea.com/lunny) has explained this in the [issue to implement actions](https://github.com/go-gitea/gitea/issues/13539). Furthermore, Actions is not only a CI/CD system but also an automation tool.
|
||||
|
||||
On the other hand, there have been numerous [actions](https://github.com/marketplace?type=actions) implemented in the open-source world. It is exciting to be able to reuse them.
|
||||
There have also been numerous [marketplace actions](https://github.com/marketplace?type=actions) implemented in the open-source world. It is exciting to be able to reuse them.
|
||||
|
||||
#### Has Gitea Actions completed compatibility with GitHub Actions?
|
||||
#### Has Gitea Actions achieved full compatibility with GitHub Actions?
|
||||
|
||||
Not yet, We will try to achieve it.
|
||||
Not yet, we are working on it.
|
||||
|
||||
[ChristopherHX](https://github.com/ChristopherHX) has provided an excellent overview of the differences between Gitea Actions and GitHub Actions in [#13539/comment](https://github.com/go-gitea/gitea/issues/13539#issuecomment-1448888850).
|
||||
[@ChristopherHX](https://github.com/ChristopherHX) has provided an excellent overview of the differences between Gitea Actions and GitHub Actions in [this comment](https://github.com/go-gitea/gitea/issues/13539#issuecomment-1448888850).
|
||||
|
||||
#### What if it runs on multiple labels, such as `runs-on: [label_a, label_b]`?
|
||||
|
||||
This is correct grammar. It means that it should run on the runners that have both the `label_a` and `label_b` labels.
|
||||
|
||||
Unfortunately, act runner does not work in this way. As I mentioned, we map labels to environments:
|
||||
This is valid syntax.
|
||||
It means that it should run on runners that have both the `label_a` **and** `label_b` labels.
|
||||
<!-- TODO: https://discord.com/channels/322538954119184384/323701541297192961/1088938879039570001 -->
|
||||
Unfortunately, act runner does not work this way. As mentioned, we map labels to environments:
|
||||
|
||||
- `ubuntu` → `ubuntu:22.04`
|
||||
- `centos` → `centos:8`
|
||||
|
|
@ -316,7 +355,10 @@ But we need to map label groups to environments instead, like so:
|
|||
- `[with-gpu]` → `linux:with-gpu`
|
||||
- `[ubuntu, with-gpu]` → `ubuntu:22.04_with-gpu`
|
||||
|
||||
We also need to redesign how tasks are assigned to runners. A runner with `ubuntu`, `centos`, or `with-gpu` does not necessarily indicate that it can accept jobs with `[centos, with-gpu]`. Therefore, the runner should inform the Gitea instance that it can only accept jobs with `[ubuntu]`, `[centos]`, `[with-gpu]`, and `[ubuntu, with-gpu]`.This is not a technical problem, we just neglected this part of the design in the early days. See [runtime.go#L65](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L65).
|
||||
We also need to re-design how tasks are assigned to runners.
|
||||
A runner with `ubuntu`, `centos`, or `with-gpu` does not necessarily indicate that it can accept jobs with `[centos, with-gpu]`.
|
||||
Therefore, the runner should inform the Gitea instance that it can only accept jobs with `[ubuntu]`, `[centos]`, `[with-gpu]`, and `[ubuntu, with-gpu]`.
|
||||
This is not a technical problem, it was just overlooked in the early design. See [runtime.go#L65](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L65).
|
||||
|
||||
Currently, the act runner attempts to match everyone in the labels and uses the first match it finds.
|
||||
|
||||
|
|
@ -324,16 +366,27 @@ Currently, the act runner attempts to match everyone in the labels and uses the
|
|||
|
||||
|
||||
|
||||
Agent labels are reported to the Gitea instance by the runner during registration. Custom labels, on the other hand, are added manually by an administrator.
|
||||
Agent labels are reported to the Gitea instance by the runner during registration.
|
||||
Custom labels, on the other hand, are added manually by a Gitea admin/<!-- TODO: Repo owners as well? -->.
|
||||
|
||||
However, the design here needs improvement, as it is not currently functioning well. You can add a custom label such as `centos` to a registered runner, which means the runner will receive jobs with `runs-on: centos`. However, the runner may not know which environment to use for this label, resulting in it using a default image or leading to a logical dead end. This default may not match user expectations. See [runtime.go#L71](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L71).
|
||||
However, the design here needs improvement, as it currently has some rough edges.
|
||||
You can add a custom label such as `centos` to a registered runner, which means the runner will receive jobs with `runs-on: centos`.
|
||||
However, the runner may not know which environment to use for this label, resulting in it using a default image or leading to a logical dead end.
|
||||
This default may not match user expectations.
|
||||
See [runtime.go#L71](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L71).
|
||||
|
||||
Before making improvements, I suggest that you reregister your runner if you want to change its labels.
|
||||
In the meantime, we suggest that you re-register your runner if you want to change its labels.
|
||||
|
||||
#### Will there be more implementations for Gitea Actions runner?
|
||||
|
||||
Although I would like to provide more implementation options, our limited manpower means we can only offer act runner as an open-source implementation in the near future. Since Gitea and act runner are completely open source, anyone can create a new implementation. We will support the developer's choice, just as we always do.
|
||||
Although we would like to provide more options, our limited manpower means that act runner will be the only officially supported runner.
|
||||
However, both Gitea and act runner are completely open source, so anyone can create a new/better implementation.
|
||||
We support your choice, no matter how you decide.
|
||||
In case you fork act runner to create your own version: Please contribute the changes back if you can and if you think your changes will help others as well.
|
||||
|
||||
### **Going further**
|
||||
|
||||
Have fun with Gitea Actions! Although it may not be perfect yet, we can work together to improve it. You can report bugs or propose ideas by submitting issues and joining our chatroom to discuss them. And of course, pull requests are welcome!
|
||||
Have fun with Gitea Actions!
|
||||
Although it may not be perfect yet, we can work together to improve it.
|
||||
You can report bugs or propose ideas by submitting issues and joining our chat to discuss them.
|
||||
And as always, pull requests are welcome!
|
||||
Loading…
Reference in a new issue