gitea/act_runner
61
107
Fork 81
Code Issues 139 Pull Requests 9 Actions Releases 21 Activity

Using Docker Run inside of Gitea Actions #189

New Issue
Open
opened 2023-05-16 14:55:26 +00:00 by qihangnet · 14 comments
qihangnet commented 2023-05-16 14:55:26 +00:00
Copy Link

Previously, I used drone and woodpecker to collaborate with Gitea for CI/CD. Now, I'm trying to replace it with Gitea Actions.My Actions steps require some pre-environment installations, such as specific versions of .NET Core and Node.js, etc. Of course, these installations can be implemented with actions like step-dotnet, step-nodejs, etc. However, these setup-xxx actions are already very slow in themselves, especially in the Chinese network environment. Therefore, we prefer to use Docker containers with pre-installed environment as the Step execution environment.

I found an action on GitHub called docker-run-action that met my needs. It allows you to specify an image, options and a list of commands to run during the build process.

jobs:
    compile:
        name: Compile site assets
        runs-on: ubuntu-latest
        steps:
          - name: Check out the repo
            uses: actions/checkout@v2
          - name: Run the build process with Docker
            uses: addnab/docker-run-action@v3
            with:
                image: aschmelyun/cleaver:latest
                options: -v ${{ github.workspace }}:/var/www
                run: |
                    composer install
                    npm install
                    npm run production

It works normally in Github Actions, but there are some issues in Gitea Actions.

Test found that the container can start normally in this docker-run-action, but the mount specified in options: -v ${{ github.workspace }}:/var/www did not appear in the container, so it was impossible to run the command after run.

I think this may be an issue caused by some mechanism of act_runner. Can you check and fix it? It would be a great help for users like us.

Previously, I used drone and woodpecker to collaborate with Gitea for CI/CD. Now, I'm trying to replace it with Gitea Actions.My Actions steps require some pre-environment installations, such as specific versions of `.NET Core` and `Node.js`, etc. Of course, these installations can be implemented with actions like `step-dotnet`, `step-nodejs`, etc. However, these `setup-xxx` actions are already very slow in themselves, especially in the Chinese network environment. Therefore, we prefer to use Docker containers with pre-installed environment as the Step execution environment. I found an action on GitHub called [docker-run-action](https://github.com/addnab/docker-run-action) that met my needs. It allows you to specify an image, options and a list of commands to run during the build process. ``` yaml jobs: compile: name: Compile site assets runs-on: ubuntu-latest steps: - name: Check out the repo uses: actions/checkout@v2 - name: Run the build process with Docker uses: addnab/docker-run-action@v3 with: image: aschmelyun/cleaver:latest options: -v ${{ github.workspace }}:/var/www run: | composer install npm install npm run production ``` It works normally in Github Actions, but there are some issues in Gitea Actions. Test found that the container can start normally in this `docker-run-action`, but the mount specified in `options: -v ${{ github.workspace }}:/var/www` did not appear in the container, so it was impossible to run the command after `run`. I think this may be an issue caused by some mechanism of act_runner. Can you check and fix it? It would be a great help for users like us.
wolfogre added the
kind
bug
related
workflow
 labels 2023-05-17 06:16:10 +00:00
sillyguodong commented 2023-05-17 06:18:42 +00:00
Member
Copy Link

If you want to specify the image of enviornment, there are two ways:

  1. specify container image in workflow file
jobs:
  compile:
    name: Compile site assets
    runs-on: ubuntu-latest
    container:
      image: aschmelyun/cleaver:latest
  1. register with labels

you can specify labels when register runner, like this:

./act_runner register --no-interactive [other flags] --labels cleaver-latest:docker://aschmelyun/cleaver:latest[,other labels]

then specify what kind of runner will execute the action in workflow file:

jobs:
  compile:
        name: Compile site assets
        runs-on: cleaver-latest
If you want to specify the image of enviornment, there are two ways: 1. specify container image in workflow file ```yaml jobs: compile: name: Compile site assets runs-on: ubuntu-latest container: image: aschmelyun/cleaver:latest ``` 2. register with labels you can specify labels when [register runner](https://docs.gitea.com/next/usage/actions/usage/actions/act-runner#register-the-runner), like this: ``` ./act_runner register --no-interactive [other flags] --labels cleaver-latest:docker://aschmelyun/cleaver:latest[,other labels] ``` then specify what kind of runner will execute the action in workflow file: ``` jobs: compile: name: Compile site assets runs-on: cleaver-latest ```
👍 3
qihangnet commented 2023-05-18 02:15:26 +00:00
Author
Copy Link

@sillyguodong Sorry, you misunderstood or I may not have expressed it clearly. The scenario I was referring to is not the running environment of act_run jobs, but the running environment of a specific step.
20230518101440VGkk8ipW

@sillyguodong Sorry, you misunderstood or I may not have expressed it clearly. The scenario I was referring to is not the running environment of act_run jobs, but the running environment of a specific step. ![20230518101440VGkk8ipW](/attachments/ec6dfb33-554b-4cbe-a592-ae2e0c98e877)
20230518101440VGkk8ipW.png
424 KiB
sillyguodong commented 2023-05-19 02:11:33 +00:00
Member
Copy Link

@sillyguodong Sorry, you misunderstood or I may not have expressed it clearly. The scenario I was referring to is not the running environment of act_run jobs, but the running environment of a specific step.

Oh I see, sorry for misunderstood.

The first thing to clarify is that there is a difference between Github Actions and Gitea Actions. The Gitahub Actions run jobs directly on the runner machine by default (unless using jobs.job-id.contianer to specify contianer). And Gitea Actions run jobs on containers by default, it depends on the labels that you defined when regitering act_runner.

but the mount specified in options: -v ${{ github.workspace }}:/var/www did not appear in the container

As mentioned above, Due to Gitea Actions run jobs on containers by default, so ${{github.workspace}} is actually a directory within the container. But the flag of -v should mount a host directory into the container directory. So there should be an error.
And Github Actions run jobs directly on the host, so it works well.

Gitea Actions also can run jobs directly on the host. I suggest you refer to the document, add a host label to the runner, and re-register it.

> @sillyguodong Sorry, you misunderstood or I may not have expressed it clearly. The scenario I was referring to is not the running environment of act_run jobs, but the running environment of a specific step. Oh I see, sorry for misunderstood. The first thing to clarify is that there is a difference between `Github Actions` and `Gitea Actions`. The `Gitahub Actions` run jobs directly on the runner machine by default (unless using [jobs.job-id.contianer](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-running-a-job-within-a-container) to specify contianer). And `Gitea Actions` run jobs on containers by default, it depends on the [labels](https://docs.gitea.com/next/usage/actions/usage/actions/act-runner#labels) that you defined when regitering `act_runner`. > but the mount specified in options: -v ${{ github.workspace }}:/var/www did not appear in the container As mentioned above, Due to `Gitea Actions` run jobs on containers by default, so `${{github.workspace}}` is actually a directory within the container. But the flag of `-v` should mount a **host directory** into the container directory. So there should be an error. And `Github Actions` run jobs directly on the host, so it works well. `Gitea Actions` also can run jobs directly on the host. I suggest you refer to the [document](https://docs.gitea.com/next/usage/actions/usage/actions/act-runner#labels), add a host label to the runner, and re-register it.
qihangnet commented 2023-05-24 02:24:50 +00:00
Author
Copy Link

Thank you for your reply. However, I believe that solving this problem can bring at least two benefits:

  • People who previously used drone or woodpecker can easily switch to Gitea Actions.
  • In the context of the network conditions in China, it can effectively avoid the problem of slow performance caused by setup-xxx.

So, if possible, I hope you can fix this problem and allow a container to mount a directory in another container.

Thank you for your reply. However, I believe that solving this problem can bring at least two benefits: - People who previously used `drone` or `woodpecker` can easily switch to `Gitea Actions`. - In the context of the network conditions in China, it can effectively avoid the problem of slow performance caused by `setup-xxx`. So, if possible, I hope you can fix this problem and allow a container to mount a directory in another container.
sillyguodong commented 2023-05-26 04:33:35 +00:00
Member
Copy Link

Maybe --volumes-from will meet your needs.

- name: Run the build process with Docker
   uses: https://github.com/addnab/docker-run-action@v3
   with:
      image: aschmelyun/cleaver:latest
      # ${{ env.JOB_CONTAINER_NAME }}:   I've only added this environment variable locally for now.
      options: --volumes-from ${{ env.JOB_CONTAINER_NAME }} 
      run: |
        npm -v
        cd ${{ github.workspace }}
        ls -la

And it works.
image

But I think there are some issues of the action(docker-run-action) that need to be fixed:

  1. The step container was not removed at the end:
    image
  2. issuse 1 also causes some volumes not to be removed:
    image
Maybe [--volumes-from](https://docs.docker.com/engine/reference/commandline/run/#volumes-from) will meet your needs. ```yaml - name: Run the build process with Docker uses: https://github.com/addnab/docker-run-action@v3 with: image: aschmelyun/cleaver:latest # ${{ env.JOB_CONTAINER_NAME }}: I've only added this environment variable locally for now. options: --volumes-from ${{ env.JOB_CONTAINER_NAME }} run: | npm -v cd ${{ github.workspace }} ls -la ``` And it works. ![image](/attachments/dba5ff87-dc6a-4864-a900-301c4bd8573e) But I think there are some issues of the action(`docker-run-action`) that need to be fixed: 1. The step container was not removed at the end: ![image](/attachments/9279fa7f-8f08-444f-80d5-db50023edebc) 2. issuse 1 also causes some volumes not to be removed: ![image](/attachments/ae36c630-e686-46cf-bbc2-62d038c51249)
image.png
158 KiB
image.png
55 KiB
image.png
116 KiB
silverwind commented 2023-05-28 18:56:33 +00:00
Member
Copy Link

I think running specific steps in specific containers is something that goes against the principles of actions. I see it as a huge benefit over woodpecker/drone that actions is designed to run everything in one shared environment as it makes use cases that rely on state outside the working directory possible.

There is no per-step isolation like in woodpecker/drone, so all steps run in the same environment, which simplifies a lot of tasks that were previously hard do to with isolated steps where global state like GOCACHE or npm cache would be lost between steps.

So I suggest we close this. If you want different images per step and per-step isolation, woodpecker/drone are better suited for that.

I think running specific steps in specific containers is something that goes against the principles of actions. I see it as a huge benefit over woodpecker/drone that actions is designed to run everything in one shared environment as it makes use cases that rely on state outside the working directory possible. There is no per-step isolation like in woodpecker/drone, so all steps run in the same environment, which simplifies a lot of tasks that were previously hard do to with isolated steps where global state like GOCACHE or npm cache would be lost between steps. So I suggest we close this. If you want different images per step and per-step isolation, woodpecker/drone are better suited for that.
ChristopherHX commented 2023-05-28 19:25:04 +00:00
Contributor
Copy Link

all steps run in the same environment

Not all steps, docker actions get their own container

- uses: docker://image:tag
  with:
    entrypoint: sh
    args: myscript.sh
> all steps run in the same environment Not all steps, docker actions get their own container ```yaml - uses: docker://image:tag with: entrypoint: sh args: myscript.sh ```
qihangnet commented 2023-05-29 06:13:01 +00:00
Author
Copy Link

The goal is to simplify some building steps, but not all can be done in one step. For more information, please refer to this blog post:
https://aschmelyun.com/blog/using-docker-run-inside-of-github-actions/

The goal is to simplify some building steps, but not all can be done in one step. For more information, please refer to this blog post: https://aschmelyun.com/blog/using-docker-run-inside-of-github-actions/
sillyguodong commented 2023-05-30 05:57:38 +00:00
Member
Copy Link

Maybe --volumes-from will meet your needs.

- name: Run the build process with Docker
   uses: https://github.com/addnab/docker-run-action@v3
   with:
      image: aschmelyun/cleaver:latest
      # ${{ env.JOB_CONTAINER_NAME }}:   I've only added this environment variable locally for now.
      options: --volumes-from ${{ env.JOB_CONTAINER_NAME }} 
      run: |
        npm -v
        cd ${{ github.workspace }}
        ls -la

And it works.
image

But I think there are some issues of the action(docker-run-action) that need to be fixed:

  1. The step container was not removed at the end:
    image
  2. issuse 1 also causes some volumes not to be removed:
    image

@qihangnet can you try that?

> Maybe [--volumes-from](https://docs.docker.com/engine/reference/commandline/run/#volumes-from) will meet your needs. > > ```yaml > - name: Run the build process with Docker > uses: https://github.com/addnab/docker-run-action@v3 > with: > image: aschmelyun/cleaver:latest > # ${{ env.JOB_CONTAINER_NAME }}: I've only added this environment variable locally for now. > options: --volumes-from ${{ env.JOB_CONTAINER_NAME }} > run: | > npm -v > cd ${{ github.workspace }} > ls -la > ``` > > And it works. > ![image](/attachments/dba5ff87-dc6a-4864-a900-301c4bd8573e) > > But I think there are some issues of the action(`docker-run-action`) that need to be fixed: > 1. The step container was not removed at the end: > ![image](/attachments/9279fa7f-8f08-444f-80d5-db50023edebc) > 2. issuse 1 also causes some volumes not to be removed: > ![image](/attachments/ae36c630-e686-46cf-bbc2-62d038c51249) > @qihangnet can you try that?
dynek commented 2023-08-30 10:02:54 +00:00
Copy Link

Hello, I am using this solution as well, thanks for documenting it!

Now I am wondering, how did you find this env variable ? I am unable to find any reference, e.g. to other available/built-in variables.

Thank you

Hello, I am using this solution as well, thanks for _documenting_ it! Now I am wondering, how did you find this `env` variable ? I am unable to find any reference, e.g. to other available/built-in variables. Thank you
tqcq commented 2023-11-30 13:48:11 +00:00
Copy Link

Hello, I am using this solution as well, thanks for documenting it!

Now I am wondering, how did you find this env variable ? I am unable to find any reference, e.g. to other available/built-in variables.

Thank you

jobs:
build:
strategy:
matrix:
build_type: [ "Debug", "Release" ]
runs-on: ubuntu-20.04
env:
BUILD_DIR: build
steps:
- name: show-envs
run: |
env | sort

try this

env | sort
> Hello, I am using this solution as well, thanks for _documenting_ it! > > Now I am wondering, how did you find this `env` variable ? I am unable to find any reference, e.g. to other available/built-in variables. > > Thank you jobs: build: strategy: matrix: build_type: [ "Debug", "Release" ] runs-on: ubuntu-20.04 env: BUILD_DIR: build steps: - name: show-envs run: | env | sort try this ```bash env | sort ```
👍 1
CJLove commented 2024-02-02 23:20:45 +00:00
Copy Link

I too would like this ability to run particular steps inside containers; I tried the above action as well as kohlerdominik/docker-run-action@v1.1.0 but was seeing similar issues with container cleanup due to in-use volume:

Error: Error occurred running finally: Error occurred running finally: Error response from daemon: remove GITEA-ACTIONS-TASK-push_WORKFLOW-Gitea-Actions-Demo_JOB-Explore-Gitea-Actions: volume is in use - [374186c206ed86674bbe533960eed55026cb92848188d1b3586054e590455627] (original error: <nil>) (original error: <nil>)

I found that a cleanup step after the docker-run-action step seemed to resolve the error at the end of the workflow. Here's an excerpt of the docker-run-action and cleanup steps:

      - name: Build
        uses: https://github.com/addnab/docker-run-action@v3
        with:
          image: myimage:mytag
          options: --volumes-from=${{ env.JOB_CONTAINER_NAME }}
          run: |
            g++ --version
      - name: Docker cleanup
        run: docker rm $(docker ps -l --format '{{.ID}}')

The docker cleanup step gets the id of the latest container ID (which would be the one created via the docker-run-action) and removes it, which frees up the volume when the overall workflow exits.

I too would like this ability to run particular steps inside containers; I tried the above action as well as `kohlerdominik/docker-run-action@v1.1.0` but was seeing similar issues with container cleanup due to in-use volume: ``` Error: Error occurred running finally: Error occurred running finally: Error response from daemon: remove GITEA-ACTIONS-TASK-push_WORKFLOW-Gitea-Actions-Demo_JOB-Explore-Gitea-Actions: volume is in use - [374186c206ed86674bbe533960eed55026cb92848188d1b3586054e590455627] (original error: <nil>) (original error: <nil>) ``` I found that a cleanup step after the `docker-run-action` step seemed to resolve the error at the end of the workflow. Here's an excerpt of the `docker-run-action` and cleanup steps: ``` - name: Build uses: https://github.com/addnab/docker-run-action@v3 with: image: myimage:mytag options: --volumes-from=${{ env.JOB_CONTAINER_NAME }} run: | g++ --version - name: Docker cleanup run: docker rm $(docker ps -l --format '{{.ID}}') ``` The docker cleanup step gets the id of the latest container ID (which would be the one created via the `docker-run-action`) and removes it, which frees up the volume when the overall workflow exits.
👍 1
CJLove commented 2024-02-03 16:15:37 +00:00
Copy Link

Better still, add --rm to the options and the Docker cleanup step isn't needed.

Better still, add `--rm` to the options and the Docker cleanup step isn't needed.
future commented 2024-03-18 10:44:52 +00:00
Copy Link

I can report that after reading this issue I was able to get started successfully. Much appreciated.

Example of how I use the tips found here:

name: Markdown Lint

on: [push]

jobs:
  lint:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@main

    - name: Lint
      uses: addnab/docker-run-action@v3
      with:
        image: ghcr.io/igorshubovych/markdownlint-cli:latest
        options: --volumes-from=${{ env.JOB_CONTAINER_NAME }}
        run: |
          cd ${{ github.workspace }}
          markdownlint "*.md"
I can report that after reading this issue I was able to get started successfully. Much appreciated. Example of how I use the tips found here: ```yaml name: Markdown Lint on: [push] jobs: lint: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@main - name: Lint uses: addnab/docker-run-action@v3 with: image: ghcr.io/igorshubovych/markdownlint-cli:latest options: --volumes-from=${{ env.JOB_CONTAINER_NAME }} run: | cd ${{ github.workspace }} markdownlint "*.md" ```
👍 1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
renovate/github.com-nektos-act-0.x
renovate/alpine-3.x
renovate/actions-setup-go-5.x
renovate/golang.org-x-term-0.x
v0.2.10
v0.2.9
v0.2.8
v0.2.7
v0.2.6
v0.2.5
v0.2.4
v0.2.3
v0.2.2
v0.2.1
v0.2.0
v0.1.8
v0.1.7
v0.1.6
v0.1.5
v0.1.4
v0.1.3
v0.1.2
v0.1.1
v0.1.0
v0.0.1
Labels
Clear labels   
kind
bug
Something is not working

  
kind
build

  
kind/compatible
  
kind
dependencies

  
kind
docs

  
kind
enhancement
New feature

  
kind
feature

  
kind
help wanted
Need some help

  
kind
proposal

  
kind
refactor

  
related
act
Related to act.

  
related
environment
Related to the environment.

  
related
exec

  
related
gitea
Related to Gitea.

  
related
workflow
Related to the workflow file or actions scripts.

  
reviewed
confirmed
confirmed issue

  
reviewed
duplicate
This issue or pull request already exists

  
reviewed
invalid
Something is wrong

  
reviewed
needs feedback

  
reviewed
wontfix
This won't be fixed

  
reviewed
workaround

No Label
kind
bug
kind
build
kind/compatible
kind
dependencies
kind
docs
kind
enhancement
kind
feature
kind
help wanted
kind
proposal
kind
refactor
related
act
related
environment
related
exec
related
gitea
related
workflow
reviewed
confirmed
reviewed
duplicate
reviewed
invalid
reviewed
needs feedback
reviewed
wontfix
reviewed
workaround
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
8 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/act_runner#189
No description provided.
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?