mirror of
https://github.com/nektos/act.git
synced 2026-04-26 09:25:54 +03:00
[GH-ISSUE #631] Issue: Declared container in a job overrides default image #413
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#413
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 @davido-nw on GitHub (Apr 23, 2021).
Original GitHub issue: https://github.com/nektos/act/issues/631
Act version
Expected behavior
Some of our workflows utilize a specific image by declaring an image in
container.imagewithin the job. The actual run of the workflow utilizes the base Ubuntu 18.04 environment - which hasdockerinstalled in it - to pull that image and run the job steps from within the images' container within the 18.04 environment.This is also evident when manually starting a shell container from the
catthehacker/ubuntu:act-18.04image - that image containsdockerandnodeinstalled, since it leveragesnodeto run the action. But thenixosimage that we use does not containnode. Runningacton this workflow fails because it's expecting to callnodewhich isn't present in thenixosimage.The TL;DR is: the expected behavior is that
actwould launch a container based off thecatthehacker/ubuntu:act-18.04image, and then pull thenixosimage from within that container.Actual behavior
Even if I explicitly state that I want to use the
catthehacker/ubuntu:act-18.04image by callingact pull_request -P ubuntu-18.04=catthehacker/ubuntu:act-18.04, the presence of acontainer.imagewithin the job means it wants to actually run the action within that image (nixos).What became evident by going through the verbose output is that it never bothered to start the
catthehacker/ubuntu:act-18.04container. Instead, it went straight to thenixoscontainer, where it expected to be able to callnode /actions/actions-checkout@28c7f3d2b5162b5ddd3dfd9a45aa55eaf396478b/dist/index.js. This failed because node isn't in thenixoscontainer.Workflow and/or repository
workflow
Steps to reproduce
First, just to be clear, I only just started using this a couple of hours ago, so it's quite possible I might be misunderstanding something that isn't immediately obvious.
act pull_request -P ubuntu-18.04=catthehacker/ubuntu:act-18.04 -vWith or without the
-P, it wants to go straight to thenixosimage that's part of that job. Again, it's possible that I might be misunderstanding things, and that perhaps this is expected behavior, but my take on the expected behavior is that it should be properly emulating the "container within a container" setup correctly, since the 'outer' 18.04 container should be expected to containnode.actoutputLog
@catthehacker commented on GitHub (Apr 23, 2021):
From https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainer
To me, what you see happening, is correct behaviour according to GitHub documentation
@ChristopherHX commented on GitHub (Apr 23, 2021):
I agree, Act behaves differently than the github runner at this point. I have no problem with it, act is different in many ways
The official runner doesn't execute node supplied by the docker image.
Correct is, node is executed inside the container.
Different is, the runner bind mounts it's own external tools (including node12) into the container and executes it's own version of node12 from the bind mount.
Reference:
github.com/actions/runner@be9632302c/src/Runner.Worker/Handlers/NodeScriptActionHandler.cs (L84)BTW: I'm working on something similar to act (with more official source code), to run github actions on my raspberry Pi 4 with gitea instead of github.
@davido-nw commented on GitHub (Apr 28, 2021):
Thanks for the insights; I'm going to close this now.