starred/act

Fork 0

mirror of https://github.com/nektos/act.git synced 2026-04-26 01:15:51 +03:00

[GH-ISSUE #2724] Intermittent or Inconsistent File Access within `act`-Managed Docker Container on Windows for `dotnet pack` after `actions/checkout` #1233

New issue

Open

opened 2026-03-01 21:49:50 +03:00 by kerem · 0 comments

kerem commented

2026-03-01 21:49:50 +03:00

Owner

Originally created by @ulfbou on GitHub (Apr 8, 2025).
Original GitHub issue: https://github.com/nektos/act/issues/2724

Bug report info

act version:            0.2.76
GOOS:                   windows
GOARCH:                 amd64
NumCPU:                 4
Docker host:            DOCKER_HOST environment variable is not set
Sockets found:
        \\.\pipe\docker_engine(broken)
Config files:
        C:\Users\Uffe\AppData\Local\act\actrc:
                -P ubuntu-latest=catthehacker/ubuntu:act-latest
                -P ubuntu-22.04=catthehacker/ubuntu:act-22.04
                -P ubuntu-20.04=catthehacker/ubuntu:act-20.04
                -P ubuntu-18.04=catthehacker/ubuntu:act-18.04
Build info:
        Go version:            go1.24.1
        Module path:           github.com/nektos/act
        Main version:          v0.2.76
        Main path:             github.com/nektos/act
        Main checksum:
        Build settings:
                -buildmode:           exe
                -compiler:            gc
                -ldflags:             -s -w -X main.version=0.2.76 -X main.commit=4f4913f9f34da9f349bf4f842c56e9d7f8af3729 -X main.date=2025-04-01T02:36:03Z -X main.builtBy=goreleaser
                CGO_ENABLED:          0
                GOARCH:               amd64
                GOOS:                 windows
                GOAMD64:              v1
                vcs:                  git
                vcs.revision:         4f4913f9f34da9f349bf4f842c56e9d7f8af3729
                vcs.time:             2025-04-01T02:35:41Z
                vcs.modified:         false
Docker Engine:
        Engine version:        28.0.4
        Engine runtime:        runc
        Cgroup version:        1
        Cgroup driver:         cgroupfs
        Storage driver:        overlayfs
        Registry URI:          https://index.docker.io/v1/
        OS:                    Docker Desktop
        OS type:               linux
        OS version:
        OS arch:               x86_64
        OS kernel:             5.15.167.4-microsoft-standard-WSL2
        OS CPU:                4
        OS memory:             7916 MB
        Security options:
                name=seccomp,profile=unconfined

Command used with act

act -j publish -W local-ci/test-publish.yml

Note: The workflow filename might have varied slightly across our attempts, but this is the general command structure

Describe issue

We are unable to successfully execute the dotnet pack command within a Linux-based Docker container managed by act on your Windows host. The error consistently indicates that the project file (Async.Locks.csproj) cannot be found, even after steps within the same job have successfully listed the directory containing the file and even navigated into that directory. This suggests an inconsistency or problem with how act on Windows handles the volume-mounted filesystem and the execution context of commands within the container.

Detailed Observations and Steps Taken:

Workflow Goal: The objective is to locally test a GitHub Actions workflow that checks out .NET code and builds a NuGet package using the .NET SDK within a Docker container (ulfbou/dotnet-node:9.0).
Local Environment: The testing is being performed on a Windows machine using act. Docker Desktop is the underlying containerization platform.
Initial Attempts: Running the workflow directly resulted in the dotnet pack command failing with the error MSBUILD : error MSB1009: Project file does not exist. Switch: Async.Locks.csproj.
Verification of File Existence: We added steps to the workflow to list the contents of the /github/workspace directory (where the code is checked out via volume mount). These ls -l commands confirmed that the Src/Async.Locks directory and the Async.Locks.csproj file were indeed present within the container after the actions/checkout step.
Attempts with working-directory: We tried setting the working-directory for the dotnet pack step to various locations (/github/workspace, /github/workspace/Src/Async.Locks) in an attempt to provide the correct context for the command to find the project file. These attempts were unsuccessful.
Basic Volume Mount Test: We created a separate, simplified workflow that mounted your repository to a different location within a basic ubuntu:latest container. We were able to successfully list the contents of the mounted directory, confirming that basic volume mounting from the Windows host to the Linux container works with act.
Explicit Navigation and Debugging: We added steps to explicitly navigate into the project directory (/github/workspace/Src/Async.Locks) using cd and verified the current working directory using pwd. The output showed that the cd command succeeded, and the working directory was correctly set. However, the dotnet pack command immediately following this still failed to find the project file.
"chdir failed" Error: In some iterations, we encountered the error OCI runtime exec failed: exec failed: unable to start container process: chdir to cwd ("/github/workspace/Src/Async.Locks") set in config.json failed: no such file or directory: unknown. This error indicates that the container runtime itself was unable to change to the specified working directory for the dotnet pack step, even though a preceding cd command in a separate step to the same location was successful.
Relevance of act Issue Tracker: We reviewed issue #107 on the act GitHub repository, which, while related to a "command not found" error, highlights potential inconsistencies or limitations in how act manages the container environment, particularly concerning the filesystem and execution context.

Conclusion Based on the Evidence:

The consistent failure of dotnet pack to find the project file, even after verifying its existence and successfully navigating to its directory within the container, along with the "chdir failed" error, strongly suggests that there is an underlying issue with how act on your Windows system handles the interaction between the volume-mounted filesystem and the execution of commands in subsequent docker exec calls within the same job. The container's view or accessibility of the filesystem appears to be inconsistent or broken in a way that affects dotnet's ability to locate the project file, despite the shell being able to navigate to the correct location.

Therefore, further attempts to resolve this through modifications to the GitHub Actions workflow YAML are unlikely to be successful. The problem seems to be specific to the act environment on Windows. The most effective next step is to investigate the act issue tracker for similar reports, known limitations, or specific configuration requirements related to volume mounts and working directories on Windows. You may also need to consider alternative local testing strategies if act continues to exhibit this behavior.

Link to GitHub repository

No response

Workflow content

name: Test Publish (Container - Debug)

on: [push]

jobs:
  publish:
    name: Publish (Container)
    runs-on: ubuntu-latest
    container:
      image: ulfbou/dotnet-node:9.0
      volumes:
        - C:/Users/Uffe/Source/repos/Async/Locks:/github/workspace

    steps:
      - name: Checkout code
        uses: actions/checkout@v3
        with:
          path: /github/workspace
          fetch-depth: 0
          working-directory: /github/workspace # Be explicit

      - name: List workspace directory (after checkout)
        run: ls -l /github/workspace

      - name: Debug - PWD before CD
        run: pwd

      - name: Debug - List Src directory
        run: ls -l /github/workspace/Src

      - name: Debug - CD to Src/Async.Locks
        run: cd /github/workspace/Src/Async.Locks

      - name: Debug - PWD after CD
        run: pwd

      - name: Pack NuGet package (container)
        working-directory: /github/workspace/Src/Async.Locks
        run: |
          VERSION=$(awk -F'[<>=]' '/../../gitversion.props/{print $3}' ../../gitversion.props)
          dotnet pack Async.Locks.csproj --configuration Release --output ../../packages -p:Version="$VERSION"

      - name: List packages directory (container)
        run: ls -l /github/workspace/packages

      - name: Simulate Push NuGet package (container)
        working-directory: /github/workspace/packages
        run: echo "Simulating push of *.nupkg from /github/workspace/packages"

Relevant log output

[Test Publish (Container - Debug)/Publish (Container)] ⭐ Run Main List workspace directory (after checkout)
[Test Publish (Container - Debug)/Publish (Container)]   🐳  docker exec cmd=[sh -e /var/run/act/workflow/1.sh] user= workdir=
| total 180
| ... (listing of repository contents including Src/Async.Locks) ...
[Test Publish (Container - Debug)/Publish (Container)]   ✅  Success - Main List workspace directory (after checkout) [187.8931ms]
[Test Publish (Container - Debug)/Publish (Container)] ⭐ Run Main Debug - PWD before CD
[Test Publish (Container - Debug)/Publish (Container)]   🐳  docker exec cmd=[sh -e /var/run/act/workflow/2.sh] user= workdir=
| /github/workspace
[Test Publish (Container - Debug)/Publish (Container)]   ✅  Success - Main Debug - PWD before CD [107.8748ms]
[Test Publish (Container - Debug)/Publish (Container)] ⭐ Run Main Debug - List Src directory
[Test Publish (Container - Debug)/Publish (Container)]   🐳  docker exec cmd=[sh -e /var/run/act/workflow/3.sh] user= workdir=
| drwxrwxrwx 2 root root 4096 Apr  5 17:54 Src
[Test Publish (Container - Debug)/Publish (Container)]   ✅  Success - Main Debug - List Src directory [108.9467ms]
[Test Publish (Container - Debug)/Publish (Container)] ⭐ Run Main Debug - CD to Src/Async.Locks
[Test Publish (Container - Debug)/Publish (Container)]   🐳  docker exec cmd=[sh -e /var/run/act/workflow/4.sh] user= workdir=
[Test Publish (Container - Debug)/Publish (Container)]   ✅  Success - Main Debug - CD to Src/Async.Locks [106.1093ms]
[Test Publish (Container - Debug)/Publish (Container)] ⭐ Run Main Debug - PWD after CD
[Test Publish (Container - Debug)/Publish (Container)]   🐳  docker exec cmd=[sh -e /var/run/act/workflow/5.sh] user= workdir=
| /github/workspace/Src/Async.Locks
[Test Publish (Container - Debug)/Publish (Container)]   ✅  Success - Main Debug - PWD after CD [106.8986ms]
[Test Publish (Container - Debug)/Publish (Container)] ⭐ Run Main Pack NuGet package (container)
[Test Publish (Container - Debug)/Publish (Container)]   🐳  docker exec cmd=[sh -e /var/run/act/workflow/6.sh] user= workdir=/github/workspace/Src/Async.Locks
| MSBUILD : error MSB1009: Project file does not exist.
| Switch: Async.Locks.csproj
[Test Publish (Container - Debug)/Publish (Container)]   ❌  Failure - Main Pack NuGet package (container) [688.3654ms]

Additional information

The issue appears to be specific to running act on a Windows host with Docker Desktop, interacting with Linux containers and volume-mounted Windows files.
Basic volume mounting (listing directory contents) works correctly.
Explicitly setting the working-directory in the dotnet pack step and even successfully navigating to the project directory in a preceding step does not resolve the "project file not found" error.
In some attempts, a lower-level "chdir failed" error from the OCI runtime was observed, further indicating a problem with the container's access to the expected working directory.
The behavior suggests an inconsistency in how act manages the filesystem context or how the Docker container interacts with the volume-mounted files between different docker exec calls within the same act job on Windows.

Originally created by @ulfbou on GitHub (Apr 8, 2025). Original GitHub issue: https://github.com/nektos/act/issues/2724 ### Bug report info ```plain text act version: 0.2.76 GOOS: windows GOARCH: amd64 NumCPU: 4 Docker host: DOCKER_HOST environment variable is not set Sockets found: \\.\pipe\docker_engine(broken) Config files: C:\Users\Uffe\AppData\Local\act\actrc: -P ubuntu-latest=catthehacker/ubuntu:act-latest -P ubuntu-22.04=catthehacker/ubuntu:act-22.04 -P ubuntu-20.04=catthehacker/ubuntu:act-20.04 -P ubuntu-18.04=catthehacker/ubuntu:act-18.04 Build info: Go version: go1.24.1 Module path: github.com/nektos/act Main version: v0.2.76 Main path: github.com/nektos/act Main checksum: Build settings: -buildmode: exe -compiler: gc -ldflags: -s -w -X main.version=0.2.76 -X main.commit=4f4913f9f34da9f349bf4f842c56e9d7f8af3729 -X main.date=2025-04-01T02:36:03Z -X main.builtBy=goreleaser CGO_ENABLED: 0 GOARCH: amd64 GOOS: windows GOAMD64: v1 vcs: git vcs.revision: 4f4913f9f34da9f349bf4f842c56e9d7f8af3729 vcs.time: 2025-04-01T02:35:41Z vcs.modified: false Docker Engine: Engine version: 28.0.4 Engine runtime: runc Cgroup version: 1 Cgroup driver: cgroupfs Storage driver: overlayfs Registry URI: https://index.docker.io/v1/ OS: Docker Desktop OS type: linux OS version: OS arch: x86_64 OS kernel: 5.15.167.4-microsoft-standard-WSL2 OS CPU: 4 OS memory: 7916 MB Security options: name=seccomp,profile=unconfined ``` ### Command used with act ```sh act -j publish -W local-ci/test-publish.yml Note: The workflow filename might have varied slightly across our attempts, but this is the general command structure ``` ### Describe issue We are unable to successfully execute the `dotnet pack` command within a Linux-based Docker container managed by `act` on your Windows host. The error consistently indicates that the project file (`Async.Locks.csproj`) cannot be found, even after steps within the same job have successfully listed the directory containing the file and even navigated into that directory. This suggests an inconsistency or problem with how `act` on Windows handles the volume-mounted filesystem and the execution context of commands within the container. **Detailed Observations and Steps Taken:** 1. **Workflow Goal:** The objective is to locally test a GitHub Actions workflow that checks out .NET code and builds a NuGet package using the `.NET SDK` within a Docker container (`ulfbou/dotnet-node:9.0`). 2. **Local Environment:** The testing is being performed on a Windows machine using `act`. Docker Desktop is the underlying containerization platform. 3. **Initial Attempts:** Running the workflow directly resulted in the `dotnet pack` command failing with the error `MSBUILD : error MSB1009: Project file does not exist. Switch: Async.Locks.csproj`. 4. **Verification of File Existence:** We added steps to the workflow to list the contents of the `/github/workspace` directory (where the code is checked out via volume mount). These `ls -l` commands confirmed that the `Src/Async.Locks` directory and the `Async.Locks.csproj` file were indeed present within the container after the `actions/checkout` step. 5. **Attempts with `working-directory`:** We tried setting the `working-directory` for the `dotnet pack` step to various locations (`/github/workspace`, `/github/workspace/Src/Async.Locks`) in an attempt to provide the correct context for the command to find the project file. These attempts were unsuccessful. 6. **Basic Volume Mount Test:** We created a separate, simplified workflow that mounted your repository to a different location within a basic `ubuntu:latest` container. We were able to successfully list the contents of the mounted directory, confirming that basic volume mounting from the Windows host to the Linux container works with `act`. 7. **Explicit Navigation and Debugging:** We added steps to explicitly navigate into the project directory (`/github/workspace/Src/Async.Locks`) using `cd` and verified the current working directory using `pwd`. The output showed that the `cd` command succeeded, and the working directory was correctly set. However, the `dotnet pack` command immediately following this still failed to find the project file. 8. **"chdir failed" Error:** In some iterations, we encountered the error `OCI runtime exec failed: exec failed: unable to start container process: chdir to cwd ("/github/workspace/Src/Async.Locks") set in config.json failed: no such file or directory: unknown`. This error indicates that the container runtime itself was unable to change to the specified working directory for the `dotnet pack` step, even though a preceding `cd` command in a separate step to the same location was successful. 9. **Relevance of `act` Issue Tracker:** We reviewed issue #107 on the `act` GitHub repository, which, while related to a "command not found" error, highlights potential inconsistencies or limitations in how `act` manages the container environment, particularly concerning the filesystem and execution context. **Conclusion Based on the Evidence:** The consistent failure of `dotnet pack` to find the project file, even after verifying its existence and successfully navigating to its directory within the container, along with the "chdir failed" error, strongly suggests that there is an underlying issue with how `act` on your Windows system handles the interaction between the volume-mounted filesystem and the execution of commands in subsequent `docker exec` calls within the same job. The container's view or accessibility of the filesystem appears to be inconsistent or broken in a way that affects `dotnet`'s ability to locate the project file, despite the shell being able to navigate to the correct location. Therefore, further attempts to resolve this through modifications to the GitHub Actions workflow YAML are unlikely to be successful. The problem seems to be specific to the `act` environment on Windows. The most effective next step is to investigate the `act` issue tracker for similar reports, known limitations, or specific configuration requirements related to volume mounts and working directories on Windows. You may also need to consider alternative local testing strategies if `act` continues to exhibit this behavior. ### Link to GitHub repository _No response_ ### Workflow content ```yml name: Test Publish (Container - Debug) on: [push] jobs: publish: name: Publish (Container) runs-on: ubuntu-latest container: image: ulfbou/dotnet-node:9.0 volumes: - C:/Users/Uffe/Source/repos/Async/Locks:/github/workspace steps: - name: Checkout code uses: actions/checkout@v3 with: path: /github/workspace fetch-depth: 0 working-directory: /github/workspace # Be explicit - name: List workspace directory (after checkout) run: ls -l /github/workspace - name: Debug - PWD before CD run: pwd - name: Debug - List Src directory run: ls -l /github/workspace/Src - name: Debug - CD to Src/Async.Locks run: cd /github/workspace/Src/Async.Locks - name: Debug - PWD after CD run: pwd - name: Pack NuGet package (container) working-directory: /github/workspace/Src/Async.Locks run: | VERSION=$(awk -F'[<>=]' '/../../gitversion.props/{print $3}' ../../gitversion.props) dotnet pack Async.Locks.csproj --configuration Release --output ../../packages -p:Version="$VERSION" - name: List packages directory (container) run: ls -l /github/workspace/packages - name: Simulate Push NuGet package (container) working-directory: /github/workspace/packages run: echo "Simulating push of *.nupkg from /github/workspace/packages" ``` ### Relevant log output ```sh [Test Publish (Container - Debug)/Publish (Container)] ⭐ Run Main List workspace directory (after checkout) [Test Publish (Container - Debug)/Publish (Container)] 🐳 docker exec cmd=[sh -e /var/run/act/workflow/1.sh] user= workdir= | total 180 | ... (listing of repository contents including Src/Async.Locks) ... [Test Publish (Container - Debug)/Publish (Container)] ✅ Success - Main List workspace directory (after checkout) [187.8931ms] [Test Publish (Container - Debug)/Publish (Container)] ⭐ Run Main Debug - PWD before CD [Test Publish (Container - Debug)/Publish (Container)] 🐳 docker exec cmd=[sh -e /var/run/act/workflow/2.sh] user= workdir= | /github/workspace [Test Publish (Container - Debug)/Publish (Container)] ✅ Success - Main Debug - PWD before CD [107.8748ms] [Test Publish (Container - Debug)/Publish (Container)] ⭐ Run Main Debug - List Src directory [Test Publish (Container - Debug)/Publish (Container)] 🐳 docker exec cmd=[sh -e /var/run/act/workflow/3.sh] user= workdir= | drwxrwxrwx 2 root root 4096 Apr 5 17:54 Src [Test Publish (Container - Debug)/Publish (Container)] ✅ Success - Main Debug - List Src directory [108.9467ms] [Test Publish (Container - Debug)/Publish (Container)] ⭐ Run Main Debug - CD to Src/Async.Locks [Test Publish (Container - Debug)/Publish (Container)] 🐳 docker exec cmd=[sh -e /var/run/act/workflow/4.sh] user= workdir= [Test Publish (Container - Debug)/Publish (Container)] ✅ Success - Main Debug - CD to Src/Async.Locks [106.1093ms] [Test Publish (Container - Debug)/Publish (Container)] ⭐ Run Main Debug - PWD after CD [Test Publish (Container - Debug)/Publish (Container)] 🐳 docker exec cmd=[sh -e /var/run/act/workflow/5.sh] user= workdir= | /github/workspace/Src/Async.Locks [Test Publish (Container - Debug)/Publish (Container)] ✅ Success - Main Debug - PWD after CD [106.8986ms] [Test Publish (Container - Debug)/Publish (Container)] ⭐ Run Main Pack NuGet package (container) [Test Publish (Container - Debug)/Publish (Container)] 🐳 docker exec cmd=[sh -e /var/run/act/workflow/6.sh] user= workdir=/github/workspace/Src/Async.Locks | MSBUILD : error MSB1009: Project file does not exist. | Switch: Async.Locks.csproj [Test Publish (Container - Debug)/Publish (Container)] ❌ Failure - Main Pack NuGet package (container) [688.3654ms] ``` ### Additional information * The issue appears to be specific to running `act` on a Windows host with Docker Desktop, interacting with Linux containers and volume-mounted Windows files. * Basic volume mounting (listing directory contents) works correctly. * Explicitly setting the `working-directory` in the `dotnet pack` step and even successfully navigating to the project directory in a preceding step does not resolve the "project file not found" error. * In some attempts, a lower-level "chdir failed" error from the OCI runtime was observed, further indicating a problem with the container's access to the expected working directory. * The behavior suggests an inconsistency in how `act` manages the filesystem context or how the Docker container interacts with the volume-mounted files between different `docker exec` calls within the same `act` job on Windows.

kerem added the

kind/bug

label

2026-03-01 21:49:50 +03:00

kerem referenced this issue

2026-03-01 21:52:58 +03:00

[PR #1233] [MERGED] build(deps): bump github.com/spf13/cobra from 1.4.0 to 1.5.0 #1854

No milestone

No project

No assignees

1 participant

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

starred/act#1233

No description provided.

Rows
Columns

[GH-ISSUE #2724] Intermittent or Inconsistent File Access within act-Managed Docker Container on Windows for dotnet pack after actions/checkout #1233