Support pre-built actions #11526

New Issue

GiteaMirror · 2025-11-02T09:40:15-06:00

GiteaMirror commented

2025-11-02 09:40:15 -06:00

Originally created by @plinss on GitHub (Aug 24, 2023).

Feature Description

Not sure if this is a Gitea or an act_runner issue, but it would be nice to allow actions that are pre-built and downloaded to the act runner as simple binary files.

For example, as I understand the current state, if I were to develop a custom action in Go, currently I need a Go build environment in the Docker image running the action. If the action could be pre-compiled, the binary could be downloaded and executed on any (compatible) Docker image.

This would make it much easier to use existing Docker images for CI jobs.

Screenshots

No response

Originally created by @plinss on GitHub (Aug 24, 2023). ### Feature Description Not sure if this is a Gitea or an act_runner issue, but it would be nice to allow actions that are pre-built and downloaded to the act runner as simple binary files. For example, as I understand the current state, if I were to develop a custom action in Go, currently I need a Go build environment in the Docker image running the action. If the action could be pre-compiled, the binary could be downloaded and executed on any (compatible) Docker image. This would make it much easier to use existing Docker images for CI jobs. ### Screenshots _No response_

GiteaMirror added the topic/gitea-actions type/proposal labels 2025-11-02 09:40:15 -06:00

GiteaMirror commented

2025-11-02 09:40:16 -06:00

@wolfogre commented on GitHub (Sep 4, 2023):

I don't think it's really necessary.

The same question could be asked to actions built with nodejs.

"If I were to develop a custom action in NodeJS, currently I need a NodeJS runtime environment in the Docker image running the action. If the action could be pre-packaged with nodejs interpreters, the package could be downloaded and executed on any (compatible) Docker image."

@wolfogre commented on GitHub (Sep 4, 2023): I don't think it's really necessary. The same question could be asked to actions built with nodejs. "If I were to develop a custom action in ***NodeJS***, currently I need a ***NodeJS runtime environment*** in the Docker image running the action. If the action could be ***pre-packaged with nodejs interpreters***, the package could be downloaded and executed on any (compatible) Docker image."

GiteaMirror commented

2025-11-02 09:40:16 -06:00

@plinss commented on GitHub (Sep 4, 2023):

I'm not sure you're understanding my ask, or why it's useful.

For example, I have a job step that I really want to run in an image from Docker Hub, this image has everything I need for my build step (say I'm compiling some code in an uncommon language and there's a large build tool chain). Except first I need to checkout my repo before I can build my code. In order to run the checkout action, I need a NodeJS runtime, which isn't included on that Docker image, so that image from Docker Hub isn't actually usable.

What I'm asking for are binary actions, (or potentially prepackaged actions as you describe) something that the act runner can download and run without requiring any special run time environment so it can be used on any Docker image (with a compatible OS, of course). This way the action can be used on any Docker image.

When I first saw the ability to create Go based actions, I was hoping the act runner would be able to compile the action once (locally, or in an image with a go compiler), or just include a downloadable binary in the action's repo, and then use the build action in any image. But unfortunately it just swaps the NodeJS dependency for a Go dependency, which doesn't solve this problem.

@plinss commented on GitHub (Sep 4, 2023): I'm not sure you're understanding my ask, or why it's useful. For example, I have a job step that I really want to run in an image from Docker Hub, this image has everything I need for my build step (say I'm compiling some code in an uncommon language and there's a large build tool chain). Except first I need to checkout my repo before I can build my code. In order to run the checkout action, I need a NodeJS runtime, which isn't included on that Docker image, so that image from Docker Hub isn't actually usable. What I'm asking for are *binary actions*, (or potentially prepackaged actions as you describe) something that the act runner can download and run without requiring any special run time environment so it can be used on any Docker image (with a compatible OS, of course). This way the action can be used on any Docker image. When I first saw the ability to create Go based actions, I was hoping the act runner would be able to compile the action once (locally, or in an image with a go compiler), or just include a downloadable binary in the action's repo, and then use the build action in any image. But unfortunately it just swaps the NodeJS dependency for a Go dependency, which doesn't solve this problem.

GiteaMirror commented

2025-11-02 09:40:16 -06:00

@wolfogre commented on GitHub (Sep 4, 2023):

I fully understand your requirement, but the point is that Go based actions are not designed as binary actions to achieve dependency removal.

I understand binary actions will bring a lot of convenience to users, however, they will bring a lot of risks too, we cannot see the internal logic of binary files, which means we would need a set of protective measures to ensure that binary files are compiled from open-source code. This goes beyond the design architecture of actions.

So I'm not saying it's useless, but considering the risks and complexity it brings, I don't think it's necessary. Just my opinion.

@wolfogre commented on GitHub (Sep 4, 2023): I fully understand your requirement, but the point is that Go based actions are not designed as binary actions to achieve dependency removal. I understand binary actions will bring a lot of convenience to users, however, they will bring a lot of risks too, we cannot see the internal logic of binary files, which means we would need a set of protective measures to ensure that binary files are compiled from open-source code. This goes beyond the design architecture of actions. So I'm not saying it's useless, but considering the risks and complexity it brings, I don't think it's necessary. Just my opinion.

GiteaMirror commented

2025-11-02 09:40:17 -06:00

@plinss commented on GitHub (Sep 4, 2023):

I understand that Go based actions are not designed as binaries, it was just my initial hope when seeing them.

I also understand the risks of using binaries. My thinking was that there could be a set of known, trusted binaries hosted by Gitea (which would be compiled from open-source) for the most common actions, like checkout, artifact upload/download, etc, and a configuration option to trust a given repository of binaries which one could self-host (ideally served by the user's own Gitea instance as a package).

Frankly, given the number of custom actions out there and their dependency chains, I suspect many of them could be compromised for some time before detection, so they're not exactly risk free either.

The complexity of supporting this could be minimal, a list of locations where binary actions can be downloaded from (likely with some URL path for os, architecture, etc, e.g. /linux/amd64/checkout), and the risks can be mitigated by only allowing a small set of sources. The value to users would be vastly increased number of Docker images available to run jobs in (without having to build custom images to add all the action dependencies).

Necessary? Of course not, one could argue half of Gitea's features aren't necessary because there are work-arounds. Useful? Absolutely. Every work-around you force a user to have to do is a pain point. I for one am already building a number of custom Docker images purely to add dependencies for basic actions that I shouldn't need to do.

FWIW, I have a lot of experience with GitLab's CI/CD system, and it has features like checking out your repo and managing artifacts built in. The fact that these basic operations require a NodeJS runtime in every Docker image is a bit absurd.

@plinss commented on GitHub (Sep 4, 2023): I understand that Go based actions are not designed as binaries, it was just my initial hope when seeing them. I also understand the risks of using binaries. My thinking was that there could be a set of known, trusted binaries hosted by Gitea (which would be compiled from open-source) for the most common actions, like checkout, artifact upload/download, etc, and a configuration option to trust a given repository of binaries which one could self-host (ideally served by the user's own Gitea instance as a package). Frankly, given the number of custom actions out there and their dependency chains, I suspect many of them could be compromised for some time before detection, so they're not exactly risk free either. The complexity of supporting this could be minimal, a list of locations where binary actions can be downloaded from (likely with some URL path for os, architecture, etc, e.g. /linux/amd64/checkout), and the risks can be mitigated by only allowing a small set of sources. The value to users would be vastly increased number of Docker images available to run jobs in (without having to build custom images to add all the action dependencies). Necessary? Of course not, one could argue half of Gitea's features aren't *necessary* because there are work-arounds. Useful? Absolutely. Every work-around you force a user to have to do is a pain point. I for one am already building a number of custom Docker images purely to add dependencies for basic actions that I shouldn't need to do. FWIW, I have a lot of experience with GitLab's CI/CD system, and it has features like checking out your repo and managing artifacts built in. The fact that these basic operations require a NodeJS runtime in every Docker image is a bit absurd.

GiteaMirror commented

2025-11-02 09:40:17 -06:00

@wolfogre commented on GitHub (Sep 4, 2023):

I apologize if anything I said offended you. I simply expressed my viewpoint on this feature and its reasons directly. It's just my personal opinion and doesn't mean that the proposal has been rejected. I didn't closed this issue and I added a new label, indicating that I think it can be further discussed.

I for one am already building a number of custom Docker images purely to add dependencies for basic actions that I shouldn't need to do.

I think you could use some actons like setup go or setup nodejs to add dependencies. Maybe you think it's a little heavy to set dependencies everytime, however, I would say that's why Gitea/Gitea Actions workflow files are easily reusable, and it's a main difference from GitLab CI/CD.

The fact that these basic operations require a NodeJS runtime in every Docker image is a bit absurd.

Hmm, I would say it's not absurd, that's how GitHub Actions work, Gitea Actions is designed to be compatible with GitHub Actions.

@wolfogre commented on GitHub (Sep 4, 2023): I apologize if anything I said offended you. I simply expressed my viewpoint on this feature and its reasons directly. It's just my personal opinion and doesn't mean that the proposal has been rejected. I didn't closed this issue and I added a new label, indicating that I think it can be further discussed. > I for one am already building a number of custom Docker images purely to add dependencies for basic actions that I shouldn't need to do. I think you could use some actons like `setup go` or `setup nodejs` to add dependencies. Maybe you think it's a little heavy to set dependencies everytime, however, I would say that's why Gitea/Gitea Actions workflow files are easily reusable, and it's a main difference from GitLab CI/CD. > The fact that these basic operations require a NodeJS runtime in every Docker image is a bit absurd. Hmm, I would say it's not absurd, that's how GitHub Actions work, Gitea Actions is designed to be compatible with GitHub Actions.

GiteaMirror commented

2025-11-02 09:40:17 -06:00

@plinss commented on GitHub (Sep 4, 2023):

I apologize if anything I said offended you. I simply expressed my viewpoint on this feature and its reasons directly. It's just my personal opinion and doesn't mean that the proposal has been rejected. I didn't closed this issue and I added a new label, indicating that I think it can be further discussed.

I wasn't offended, and you're entitled to your opinion. I was just making sure my reasoning (and my opinion) is clearly captured for any future discussions.

I think you could use some actons like setup go or setup nodejs to add dependencies. Maybe you think it's a little heavy to set dependencies everytime, however, I would say that's why Gitea/Gitea Actions workflow files are easily reusable, and it's a main difference from GitLab CI/CD.

I do think it's a bit too heavy to re-download and install an entire NodeJS runtime. The main point (IMO) of using a pre-built (and likely locally cached) Docker image is to save bandwidth and CPU costs of setting up a CI environment for every run (as well as saving the additional steps in the workflow file).

And as I understand it, setup-node is primarily used to setup a different NodeJS runtime than what's already on the image, given that it itself is a Typescript action it requires NodeJS to be pre-installed.

Hmm, I would say it's not absurd, that's how GitHub Actions work, Gitea Actions is designed to be compatible with GitHub Actions.

I'm not saying the absurdity was from Gitea, and I get the benefits of compatibility with GitHub. I think GitHub Actions are absurd to essentially require NodeJS in every Docker image. Every project doesn't revolve around JS.

@plinss commented on GitHub (Sep 4, 2023): > I apologize if anything I said offended you. I simply expressed my viewpoint on this feature and its reasons directly. It's just my personal opinion and doesn't mean that the proposal has been rejected. I didn't closed this issue and I added a new label, indicating that I think it can be further discussed. I wasn't offended, and you're entitled to your opinion. I was just making sure my reasoning (and my opinion) is clearly captured for any future discussions. > I think you could use some actons like setup go or setup nodejs to add dependencies. Maybe you think it's a little heavy to set dependencies everytime, however, I would say that's why Gitea/Gitea Actions workflow files are easily reusable, and it's a main difference from GitLab CI/CD. I do think it's a bit too heavy to re-download and install an entire NodeJS runtime. The main point (IMO) of using a pre-built (and likely locally cached) Docker image is to save bandwidth and CPU costs of setting up a CI environment for every run (as well as saving the additional steps in the workflow file). And as I understand it, `setup-node` is primarily used to setup a *different* NodeJS runtime than what's already on the image, given that it itself is a Typescript action it requires NodeJS to be pre-installed. > Hmm, I would say it's not absurd, that's how GitHub Actions work, Gitea Actions is designed to be compatible with GitHub Actions. I'm not saying the absurdity was from Gitea, and I get the benefits of compatibility with GitHub. I think GitHub Actions are absurd to essentially require NodeJS in every Docker image. Every project doesn't revolve around JS.

GiteaMirror commented

2025-11-02 09:40:17 -06:00

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

Not about go actions, since they are an Gitea Actions Extension, but about nodejs actions

For context that is how "nektos/act" works with nodejs actions and that tool is not "GitHub Actions". It seems to me that some people become to think they are the same as long they only use deriviates of that third party tool like embedded in act_runner.

The fact that these basic operations require a NodeJS runtime in every Docker image is a bit absurd.

Hmm, I would say it's not absurd, that's how GitHub Actions work, Gitea Actions is designed to be compatible with GitHub Actions.

I'm not saying the absurdity was from Gitea, and I get the benefits of compatibility with GitHub. I think GitHub Actions are absurd to essentially require NodeJS in every Docker image. Every project doesn't revolve around JS.

"GitHub Actions" aka "actions/runner" bind mounts node into the container so even "ubuntu:latest" (doesn't have node installed, but is glibc based) can uses setup-node

E.g. my custom actions runner for Gitea Actions can use glibc containers without node preinstalled powered by GitHub's opensource runner

@ChristopherHX commented on GitHub (Feb 28, 2024): _Not about go actions, since they are an Gitea Actions Extension, but about nodejs actions_ For context that is how "nektos/act" works with nodejs actions and that tool is not "GitHub Actions". It seems to me that some people become to think they are the same as long they only use deriviates of that third party tool like embedded in act_runner. > > > The fact that these basic operations require a NodeJS runtime in every Docker image is a bit absurd. > > > > Hmm, I would say it's not absurd, that's how GitHub Actions work, Gitea Actions is designed to be compatible with GitHub Actions. > > I'm not saying the absurdity was from Gitea, and I get the benefits of compatibility with GitHub. I think GitHub Actions are absurd to essentially require NodeJS in every Docker image. Every project doesn't revolve around JS. "GitHub Actions" aka "actions/runner" bind mounts node into the container so even "ubuntu:latest" (doesn't have node installed, but is glibc based) can uses setup-node E.g. [my custom actions runner for Gitea Actions](https://github.com/ChristopherHX/gitea-actions-runner/blob/main/examples/docker-compose-dind/docker-compose.yml) can use glibc containers without node preinstalled powered by GitHub's opensource runner

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#11526