code.gitea.io/gitea@v1.22.3/docs/content/usage/actions/faq.en-us.md (about)

     1  ---
     2  date: "2023-04-27T15:00:00+08:00"
     3  title: "Frequently Asked Questions of Gitea Actions"
     4  slug: "faq"
     5  sidebar_position: 100
     6  draft: false
     7  toc: false
     8  menu:
     9    sidebar:
    10      parent: "actions"
    11      name: "FAQ"
    12      sidebar_position: 100
    13      identifier: "actions-faq"
    14  ---
    15  
    16  # Frequently Asked Questions of Gitea Actions
    17  
    18  This page contains some common questions and answers about Gitea Actions.
    19  
    20  ## Why is Actions not enabled by default?
    21  
    22  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.
    23  We believe that more work needs to be done to improve Gitea Actions before it deserves any further special treatment.
    24  
    25  ## Is it possible to enable Actions for new repositories by default for my own instance?
    26  
    27  Yes, when you enable Actions for the instance, you can choose to enable the `actions` unit for all new repositories by default.
    28  
    29  ```ini
    30  [repository]
    31  DEFAULT_REPO_UNITS = ...,repo.actions
    32  ```
    33  
    34  ## Should we use `${{ github.xyz }}` or `${{ gitea.xyz }}`  in workflow files?
    35  
    36  You can use `github.xyz` and Gitea will work fine.
    37  As mentioned, Gitea Actions is designed to be compatible with GitHub Actions.
    38  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).
    39  Still, this is completely optional since both options have the same effect at the moment.
    40  
    41  ## Is it possible to register runners for a specific user (not organization)?
    42  
    43  Not yet.
    44  It is technically possible to implement, but we need to discuss whether it is necessary.
    45  
    46  ## Where will the runner download scripts when using actions such as `actions/checkout@v4`?
    47  
    48  There are tens of thousands of [actions scripts](https://github.com/marketplace?type=actions) in GitHub, and when you write `uses: actions/checkout@v4`, it downloads the scripts from [github.com/actions/checkout](http://github.com/actions/checkout) by default.
    49  But what if you want to use actions from other places such as gitea.com instead of GitHub?
    50  
    51  The good news is that you can specify the URL prefix to use actions from anywhere.
    52  This is an extra syntax in Gitea Actions.
    53  For example:
    54  
    55  - `uses: https://gitea.com/xxx/xxx@xxx`
    56  - `uses: https://github.com/xxx/xxx@xxx`
    57  - `uses: http://your_gitea_instance.com/xxx@xxx`
    58  
    59  Be careful, the `https://` or `http://` prefix is necessary!
    60  
    61  This is one of the differences from GitHub Actions which supports actions scripts only from GitHub.
    62  But it should allow users much more flexibility in how they run Actions.
    63  
    64  Alternatively, if you want your runners to download actions from your own Gitea instance by default, you can configure it by setting `[actions].DEFAULT_ACTIONS_URL`.
    65  See [Configuration Cheat Sheet](administration/config-cheat-sheet.md#actions-actions).
    66  
    67  ## How to limit the permission of the runners?
    68  
    69  Runners have no more permissions than simply connecting to your Gitea instance.
    70  When any runner receives a job to run, it will temporarily gain limited permission to the repository associated with the job.
    71  If you want to give more permissions to the runner, allowing it to access more private repositories or external systems, you can pass [secrets](usage/secrets.md) to it.
    72  
    73  Refined permission control to Actions is a complicated job.
    74  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.
    75  
    76  ## How to avoid being hacked?
    77  
    78  There are two types of possible attacks: unknown runner stealing the code or secrets from your repository, or malicious scripts controlling your runner.
    79  
    80  Avoiding the former means not allowing people you don't know to register runners for your repository, organization, or instance.
    81  
    82  The latter is a bit more complicated.
    83  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.
    84  
    85  For public instances, things are a little different.
    86  Here's how we do it on [gitea.com](http://gitea.com/):
    87  
    88  - We only register runners for the "gitea" organization, so our runners will not execute jobs from other repositories.
    89  - 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.
    90  - To run actions for fork pull requests, approval is required. See [#22803](https://github.com/go-gitea/gitea/pull/22803).
    91  - 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.
    92  
    93  ## Which operating systems are supported by act runner?
    94  
    95  It works well on Linux, macOS, and Windows.
    96  While other operating systems are theoretically supported, they require further testing.
    97  
    98  One thing to note is that if you choose to run jobs directly on the host instead of in job containers, the environmental differences between operating systems may cause unexpected failures.
    99  
   100  For example, bash is not available on Windows in most cases, while act tries to use bash to run scripts by default.
   101  Therefore, you need to specify `powershell` as the default shell in your workflow file, see [defaults.run](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun).
   102  
   103  ```yaml
   104  defaults:
   105    run:
   106      shell: powershell
   107  ```
   108  
   109  ## Why choose GitHub Actions? Why not something compatible with GitLab CI/CD?
   110  
   111  [@lunny](https://gitea.com/lunny) has explained this in the [issue to implement actions](https://github.com/go-gitea/gitea/issues/13539).
   112  Furthermore, Actions is not only a CI/CD system but also an automation tool.
   113  
   114  There have also been numerous [marketplace actions](https://github.com/marketplace?type=actions) implemented in the open-source world.
   115  It is exciting to be able to reuse them.
   116  
   117  ## What if it runs on multiple labels, such as `runs-on: [label_a, label_b]`?
   118  
   119  This is valid syntax.
   120  It means that it should run on runners that have both the `label_a` **and** `label_b` labels, see [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on).
   121  Unfortunately, act runner does not work this way.
   122  As mentioned, we map labels to environments:
   123  
   124  - `ubuntu` → `ubuntu:22.04`
   125  - `centos` → `centos:8`
   126  
   127  But we need to map label groups to environments instead, like so:
   128  
   129  - `[ubuntu]` → `ubuntu:22.04`
   130  - `[with-gpu]` → `linux:with-gpu`
   131  - `[ubuntu, with-gpu]` → `ubuntu:22.04_with-gpu`
   132  
   133  We also need to re-design how tasks are assigned to runners.
   134  A runner with `ubuntu`, `centos`, or `with-gpu` does not necessarily indicate that it can accept jobs with `[centos, with-gpu]`.
   135  Therefore, the runner should inform the Gitea instance that it can only accept jobs with `[ubuntu]`, `[centos]`, `[with-gpu]`, and `[ubuntu, with-gpu]`.
   136  This is not a technical problem, it was just overlooked in the early design.
   137  See [runtime.go#L65](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L65).
   138  
   139  Currently, the act runner attempts to match everyone in the labels and uses the first match it finds.
   140  
   141  ## What is the difference between agent labels and custom labels for a runner?
   142  
   143  ![labels](/images/usage/actions/labels.png)
   144  
   145  Agent labels are reported to the Gitea instance by the runner during registration.
   146  Custom labels, on the other hand, are added manually by a Gitea administrator or owners of the organization or repository (depending on the level of the runner).
   147  
   148  However, the design here needs improvement, as it currently has some rough edges.
   149  You can add a custom label such as `centos` to a registered runner, which means the runner will receive jobs with `runs-on: centos`.
   150  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.
   151  This default may not match user expectations.
   152  See [runtime.go#L71](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L71).
   153  
   154  In the meantime, we suggest that you re-register your runner if you want to change its labels.
   155  
   156  ## Will there be more implementations for Gitea Actions runner?
   157  
   158  Although we would like to provide more options, our limited manpower means that act runner will be the only officially supported runner.
   159  However, both Gitea and act runner are completely open source, so anyone can create a new/better implementation.
   160  We support your choice, no matter how you decide.
   161  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.
   162  
   163  ## What workflow trigger events does Gitea support?
   164  
   165  All events listed in this table are supported events and are compatible with GitHub.
   166  For events supported only by GitHub, see GitHub's [documentation](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows).
   167  
   168  | trigger event               | activity types                                                                                                           |
   169  |-----------------------------|--------------------------------------------------------------------------------------------------------------------------|
   170  | create                      | not applicable                                                                                                           |
   171  | delete                      | not applicable                                                                                                           |
   172  | fork                        | not applicable                                                                                                           |
   173  | gollum                      | not applicable                                                                                                           |
   174  | push                        | not applicable                                                                                                           |
   175  | issues                      | `opened`, `edited`, `closed`, `reopened`, `assigned`, `unassigned`, `milestoned`, `demilestoned`, `labeled`, `unlabeled` |
   176  | issue_comment               | `created`, `edited`, `deleted`                                                                                           |
   177  | pull_request                | `opened`, `edited`, `closed`, `reopened`, `assigned`, `unassigned`, `synchronize`, `labeled`, `unlabeled`                |
   178  | pull_request_review         | `submitted`, `edited`                                                                                                    |
   179  | pull_request_review_comment | `created`, `edited`                                                                                                      |
   180  | release                     | `published`, `edited`                                                                                                    |
   181  | registry_package            | `published`                                                                                                              |
   182  
   183  > For `pull_request` events, in [GitHub Actions](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request), the `ref` is `refs/pull/:prNumber/merge`, which is a reference to the merge commit preview. However, Gitea has no such reference.
   184  > Therefore, the `ref` in Gitea Actions is `refs/pull/:prNumber/head`, which points to the head of pull request rather than the preview of the merge commit.