mirror of
https://github.com/nektos/act.git
synced 2026-04-26 09:25:54 +03:00
[GH-ISSUE #2095] act fails where GitHub CI succeeds #1003
Labels
No labels
area/action
area/cli
area/docs
area/image
area/runner
area/workflow
backlog
confirmed/not-planned
kind/bug
kind/discussion
kind/external
kind/feature-request
kind/question
meta/duplicate
meta/invalid
meta/need-more-info
meta/resolved
meta/wontfix
meta/workaround
needs-work
pull-request
review/not-planned
size/M
size/XL
size/XXL
stale
stale-exempt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/act#1003
Loading…
Add table
Add a link
Reference in a new issue
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?
Originally created by @dabrahams on GitHub (Nov 17, 2023).
Original GitHub issue: https://github.com/nektos/act/issues/2095
Bug report info
Command used with act
Describe issue
Note that Docker IS in fact running
act fails on my local machine but the workflow succeeds in Github Linux CI
See attached act.log
Link to GitHub repository
https://github.com/dabrahams/SPMBuildToolSupport/actions/runs/6901849884
Workflow content
Relevant log output
Additional information
No response
@SyntaxSugarNet commented on GitHub (Mar 22, 2024):
Facing the same issue using
actanddevcontainers/ci.The problem is that the mounted workspace in the
devcontainers/cidocker container is from the host file system.actis creating its own docker container with the workspace copied into its container's file system.devcontainers/cidocker container is not created insideact's container (no docker-in-docker), but besides it. Thereforedevcontainers/ci's workspace mount is not pointing toact's workspace copy, but to the original workspace on the host file system.This is why the devcontainer cannot start. Path
/var/run/act/workflow/exists inact's container but not on your host system:This can be worked around by creating the files under
/var/run/act/workflow/on the host filesystem, so the devcontainer can start, BUT as thedevcontainers/cistep will work on a different file system from all the other steps in the job, running it withactwill be possibly pointless.Not sure how
actshould handle these kind of scenarios, but maybe if instead of copying the workspace into its container it could create a temporary copy of the workspace and the necessary files (like/var/run/act/workflow/) on the host file system. Then could bind mount this copy into all of the containers created for the given job run and all the steps of the job would work on the same copied workspace on the host file system.@gund commented on GitHub (Jun 18, 2024):
I've hit the same issue as @SyntaxSugarNet while trying to run
devcontainers/ciaction withacton WSL:@zanettea commented on GitHub (Aug 14, 2024):
A workaround I found is to use custom a image that adds the dockerd daemon and then adding a step before devcontainer/ci to start docker-in-docker:
The command line:
act -s GITHUB_TOKEN="$(gh auth token)" --container-options --privileged -P ubuntu-latest=ghcr.io/corvina-r-d/ubuntu:act-22.04However it would be nice if docker-in-docker were a native options of act (
act --dind... )@github-actions[bot] commented on GitHub (Feb 11, 2025):
Issue is stale and will be closed in 14 days unless there is new activity
@stevejr commented on GitHub (Feb 27, 2025):
This issue is still present. Is it possible to get an update on an official fix?