starred/act

Fork 0

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

[GH-ISSUE #2090] Add an additional argument `--shell` to open an act generated docker container #1000

New issue

Open

opened 2026-03-01 21:48:06 +03:00 by kerem · 4 comments

kerem commented

2026-03-01 21:48:06 +03:00

Owner

Originally created by @wolfiex on GitHub (Nov 12, 2023).
Original GitHub issue: https://github.com/nektos/act/issues/2090

Act version

0.2.53

Feature description

When developing actions, it is often useful to explore the final state of the repository.
For this using the interactive shell provides a suitable debug tool.

Currently this can be done using the commands outlined below.

Although already possible, there is no reason it should not be attached to the end of the act pipeline with a suggested --shell argument.

# list all the containers, and identify the relevant one
docker ps -a

# launch an interactive shell using the container id
docker exec -it <container_id> /usr/bin/bash

Originally created by @wolfiex on GitHub (Nov 12, 2023). Original GitHub issue: https://github.com/nektos/act/issues/2090 ### Act version 0.2.53 ### Feature description When developing actions, it is often useful to explore the final state of the repository. For this using the interactive shell provides a suitable debug tool. Currently this can be done using the commands outlined below. Although already possible, there is no reason it should not be attached to the end of the act pipeline with a suggested `--shell` argument. ``` # list all the containers, and identify the relevant one docker ps -a # launch an interactive shell using the container id docker exec -it <container_id> /usr/bin/bash ```

kerem added the

kind/feature-request

label

2026-03-01 21:48:06 +03:00

kerem commented

2026-03-01 21:48:06 +03:00

Author

Owner

@jpivarski commented on GitHub (Jan 24, 2024):

+1 to this! The reason I installed act was because I thought it did this. Running GitHub Actions locally is nice—I can avoid the time spent waiting for a runner to launch—but I still need to wait for the initial (installation) steps to complete before reaching the step that I need to debug.

If there were an option to tell act to run the action and save a new Docker image at the point where the action failed, that would be ideal. (Saving a Docker image after success could be useful, too: I could remove the failing step and try commands interactively to determine what that step ought to be, for run steps, anyway.)

I have tried the various alternatives that provide ssh access into a GitHub Action, but not with any success. With one of these (I can't remember which), I managed to connect but couldn't solve the problem before the connection timed out. Naturally, the timeout is for security reasons, but that's why debugging it locally would be an advantage.

@jpivarski commented on GitHub (Jan 24, 2024): +1 to this! The reason I installed act was because I thought it did this. Running GitHub Actions locally is nice—I can avoid the time spent waiting for a runner to launch—but I still need to wait for the initial (installation) steps to complete before reaching the step that I need to debug. If there were an option to tell act to run the action and save a new Docker image at the point where the action _failed_, that would be ideal. (Saving a Docker image after success could be useful, too: I could remove the failing step and try commands interactively to determine what that step ought to be, for `run` steps, anyway.) I have tried the various alternatives that provide ssh access into a GitHub Action, but not with any success. With one of these (I can't remember which), I managed to connect but couldn't solve the problem before the connection timed out. Naturally, the timeout is for security reasons, but that's why debugging it locally would be an advantage.

kerem commented

2026-03-01 21:48:07 +03:00

Author

Owner

@robert-smith-maersk commented on GitHub (May 24, 2024):

Also, the command in the summary only gets you a new shell on the running image and some state is lost (environment variables etc.). It would be even better if act would leave the terminal session in which the workflow is run open and drop us into that...

@robert-smith-maersk commented on GitHub (May 24, 2024): Also, the command in the summary only gets you a _new_ shell on the running image and some state is lost (environment variables etc.). It would be even better if act would leave the terminal session in which the workflow is run open and drop us into that...

kerem commented

2026-03-01 21:48:07 +03:00

Author

Owner

@SaswatPadhi commented on GitHub (Oct 1, 2024):

Having such a flag would be nice.

This is what I currently do:

act -W .github/workflows/build.yml || docker exec -it `docker ps -q | head -n1` bash

If the build fails (||) then docker exec into the latest container and run bash.

@SaswatPadhi commented on GitHub (Oct 1, 2024): Having such a flag would be nice. This is what I currently do: ``` act -W .github/workflows/build.yml || docker exec -it `docker ps -q | head -n1` bash ``` If the build fails (`||`) then `docker exec` into the latest container and run `bash`.

kerem commented

2026-03-01 21:48:07 +03:00

Author

Owner

@rafl commented on GitHub (Apr 25, 2025):

What I currently do for this purpose is creating a reverse shell in my actions at point where I'd like to debug, kinda like a breakpoint, for example using - run: socat EXEC:"bash -i",pty,stderr,setsid,sigint,sane TCP-CONNECT:host.docker.internal:4444. On the host, I wait for incoming debug connections using socat TCP4-LISTEN:4444,reuseaddr,fork STDIO,raw,echo=0, which provides a decently usable terminal within the environment of the action being executed.

Using the same approach, and with just a small additional wrapper, you can even get a tmux session that'll spawn a new window for any new incoming debug connection, which is handy when running multiple workflows in parallel.

While this has been working pretty well for me, it would be nice to have a feature like this built in.

https://github.com/namespacelabs/breakpoint is a project related to this issue, and their breakpoint action could probably be extended to work locally via act as well.

@rafl commented on GitHub (Apr 25, 2025): What I currently do for this purpose is creating a reverse shell in my actions at point where I'd like to debug, kinda like a breakpoint, for example using `- run: socat EXEC:"bash -i",pty,stderr,setsid,sigint,sane TCP-CONNECT:host.docker.internal:4444`. On the host, I wait for incoming debug connections using `socat TCP4-LISTEN:4444,reuseaddr,fork STDIO,raw,echo=0`, which provides a decently usable terminal within the environment of the action being executed. Using the same approach, and with just a small additional wrapper, you can even get a tmux session that'll spawn a new window for any new incoming debug connection, which is handy when running multiple workflows in parallel. While this has been working pretty well for me, it would be nice to have a feature like this built in. https://github.com/namespacelabs/breakpoint is a project related to this issue, and their breakpoint action could probably be extended to work locally via act as well.

kerem referenced this issue

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

[PR #1057] [MERGED] deps: bump go-git #1748

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#1000

No description provided.

Rows
Columns

[GH-ISSUE #2090] Add an additional argument --shell to open an act generated docker container #1000

Act version

Feature description

[GH-ISSUE #2090] Add an additional argument `--shell` to open an act generated docker container #1000