starred/act

Fork 0

mirror of https://github.com/nektos/act.git synced 2026-04-26 09:25:54 +03:00

[GH-ISSUE #2740] [Feature Request] Add option to only trigger Pre, Main or Post steps of job steps #1240

New issue

Closed

opened 2026-03-01 21:49:53 +03:00 by kerem · 5 comments

kerem commented

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

Owner

Originally created by @qoomon on GitHub (Apr 24, 2025).
Original GitHub issue: https://github.com/nektos/act/issues/2740

Act version

0.2.76

Feature description

I am currently working on an action to run steps in parallel https://github.com/qoomon/actions--parallel-steps
So far act is quite handy to achieve this with little effort. Everything is working except that the Preand Post steps of actions are executed as part of the main step of my parallel-steps action.

Therefore it would be awesome to be able to specifically only runs Pre, Main and Post action steps.

And it would be great to run a specific step of a job only, currently it's only possible to run a whole job. But this only an improvement idea, because I worked around that by use jobs with exactly one step :-)

Originally created by @qoomon on GitHub (Apr 24, 2025). Original GitHub issue: https://github.com/nektos/act/issues/2740 ### Act version 0.2.76 ### Feature description I am currently working on an action to run steps in parallel https://github.com/qoomon/actions--parallel-steps So far act is quite handy to achieve this with little effort. Everything is working except that the `Pre`and `Post` steps of actions are executed as part of the main step of my [parallel-steps](https://github.com/qoomon/actions--parallel-steps) action. Therefore it would be awesome to be able to specifically only runs `Pre`, `Main` and `Post` action steps. And it would be great to run a specific step of a job only, currently it's only possible to run a whole job. But this only an improvement idea, because I worked around that by use jobs with exactly one step :-)

kerem

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

closed this issue
added the
kind/feature-request
label

kerem commented

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

Author

Owner

@qoomon commented on GitHub (May 2, 2025):

Three environment variables to separately skip pre, main and post would be enough as a solution e.g. ACT_STEPS_PRE_SKIP=true, ACT_STEPS_MAIN_SKIP=true, ACT_STEPS_POS_SKIP=true

@qoomon commented on GitHub (May 2, 2025): Three environment variables to separately skip `pre`, `main` and `post` would be enough as a solution e.g. `ACT_STEPS_PRE_SKIP=true`, `ACT_STEPS_MAIN_SKIP=true`, `ACT_STEPS_POS_SKIP=true`

kerem commented

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

Author

Owner

@ChristopherHX commented on GitHub (May 2, 2025):

Act keeps state between pre, main, post step. Like GITHUB_STATE, workdir, container, volumes etc. AFAIK It's design does not allow someone managing state externally without rewriting old code.

Three environment variables to separately skip pre, main and post would be enough as a solution e.g. ACT_STEPS_PRE_SKIP=true, ACT_STEPS_MAIN_SKIP=true, ACT_STEPS_POS_SKIP=true

This could cause inconsistencies, since the action state is unclear

The best you can do is

start act in the pre step and let act run all pre stages
inject a run step (hide it's log) before the first step that blocks the workflow until your actions main stage signals being ready then stream log output to the main step
inject a run step (hide it's log) after the last step and wait for your action to signal the post stage and stream the log output to the post step
.

@ChristopherHX commented on GitHub (May 2, 2025): Act keeps state between pre, main, post step. Like GITHUB_STATE, workdir, container, volumes etc. AFAIK It's design does not allow someone managing state externally without rewriting old code. > Three environment variables to separately skip `pre`, `main` and `post` would be enough as a solution e.g. `ACT_STEPS_PRE_SKIP=true`, `ACT_STEPS_MAIN_SKIP=true`, `ACT_STEPS_POS_SKIP=true` This could cause inconsistencies, since the action state is unclear The best you can do is - start act in the pre step and let act run all pre stages - inject a run step (hide it's log) before the first step that blocks the workflow until your actions main stage signals being ready then stream log output to the main step - inject a run step (hide it's log) after the last step and wait for your action to signal the post stage and stream the log output to the post step .

kerem commented

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

Author

Owner

@qoomon commented on GitHub (May 3, 2025):

The best you can do is

start act in the pre step and let act run all pre stages

inject a run step (hide it's log) before the first step that blocks the workflow until your actions main stage signals being ready then stream log output to the main step

inject a run step (hide it's log) after the last step and wait for your action to signal the post stage and stream the log output to the post step

@ChristopherHX sounds promising, can you explain how to start act in the pre step and let act run all pre stages and how to listen for those stage signals?

@qoomon commented on GitHub (May 3, 2025): > The best you can do is > > - start act in the pre step and let act run all pre stages > - inject a run step (hide it's log) before the first step that blocks the workflow until your actions main stage signals being ready then stream log output to the main step > - inject a run step (hide it's log) after the last step and wait for your action to signal the post stage and stream the log output to the post step @ChristopherHX sounds promising, can you explain how to `start act in the pre step and let act run all pre stages` and how to listen for those stage signals?

kerem commented

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

Author

Owner

@ChristopherHX commented on GitHub (May 3, 2025):

An action can start a daemon process without waiting for it to finish, so the runner moves on.

in bash an AI assistent would provide you such an bash snipped, e.g. wait for a file to be created until bash exists.

Create a MYSTATEDIR variable like $RUNNER_TEMP/$(uuidgen) in bash
Save it to GITHUB_STATE
Start the act --env MYSTATEDIR=$MYSTATEDIR
Save the pid to GITHUB_STATE
Wait for $MYSTATEDIR/pre.done to be created by the run step
Main stage create MYSTATEDIR from GITHUB_STATE saved data e.g. $MYSTATEDIR/main.start
and so on, be creative

#!/bin/bash

FILE="/path/to/your/file"

# Wait until the file exists
while [ ! -f "$FILE" ]; do
  sleep 1  # Check every second
done

echo "File $FILE has been created!"

  # Use file watchers, a tcp server, unix sockets or whatever inter process communication
- run: |
     touch "$MYSTATEDIR/pre.done"
     while [ ! -f "$MYSTATEDIR/main.start" ]; do
       sleep 1  # Check every second
     done
  shell: bash
# ......
- run: |
     touch "$MYSTATEDIR/main.done"
     while [ ! -f "$MYSTATEDIR/post.start" ]; do
       sleep 1  # Check every second
     done
  shell: bash

@ChristopherHX commented on GitHub (May 3, 2025): An action can start a daemon process without waiting for it to finish, so the runner moves on. in bash an AI assistent would provide you such an bash snipped, e.g. wait for a file to be created until bash exists. - Create a MYSTATEDIR variable like `$RUNNER_TEMP/$(uuidgen)` in bash - Save it to GITHUB_STATE - Start the `act --env MYSTATEDIR=$MYSTATEDIR` - Save the pid to GITHUB_STATE - Wait for $MYSTATEDIR/pre.done to be created by the run step - Main stage create MYSTATEDIR from GITHUB_STATE saved data e.g. `$MYSTATEDIR/main.start` - and so on, be creative ```bash #!/bin/bash FILE="/path/to/your/file" # Wait until the file exists while [ ! -f "$FILE" ]; do sleep 1 # Check every second done echo "File $FILE has been created!" ``` ```yaml # Use file watchers, a tcp server, unix sockets or whatever inter process communication - run: | touch "$MYSTATEDIR/pre.done" while [ ! -f "$MYSTATEDIR/main.start" ]; do sleep 1 # Check every second done shell: bash # ...... - run: | touch "$MYSTATEDIR/main.done" while [ ! -f "$MYSTATEDIR/post.start" ]; do sleep 1 # Check every second done shell: bash ```

kerem commented

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

Author

Owner

@qoomon commented on GitHub (May 4, 2025):

ah now I got it, thats a nice idea thanks a lot

@qoomon commented on GitHub (May 4, 2025): ah now I got it, thats a nice idea thanks a lot

kerem referenced this issue

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

[PR #1240] [MERGED] build(deps): bump github.com/stretchr/testify from 1.7.5 to 1.8.0 #1857

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

No description provided.

Rows
Columns