🦙 MegaLinter status: ✅ SUCCESS

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

MegaLinter is graciously provided by

Codecov Report

Attention: Patch coverage is 63.63636% with 20 lines in your changes missing coverage. Please review.

Project coverage is 68.74%. Comparing base (5a80a04) to head (0cc29b7).
Report is 140 commits behind head on master.

@@            Coverage Diff             @@
##           master    #2552      +/-   ##
==========================================
+ Coverage   61.56%   68.74%   +7.18%     
==========================================
  Files          53       71      +18     
  Lines        9002    10959    +1957     
==========================================
+ Hits         5542     7534    +1992     
+ Misses       3020     2859     -161     
- Partials      440      566     +126     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

• Message for skipped steps

Isn't it partially here? you need to use -v aka verbose. I would recommend that your extension then filters debug/trace away by default, log level is a json property

For jobs n/a I had fixed that the result is skipped, but I didn't think about the logger at that time.

• stepResult for pre stage

Maybe debug this?, technically you should have this in the log
I mean

I noticed some log messages are not scoped in via this function in pre, like downloading the action aka (pre pre step, yes this get's weird, and it is)

Job skipped log is also on debug level only and needs verbose flag

• stepResult for pre stage

Maybe debug this?, technically you should have this in the log I mean

act/pkg/runner/step.go

Line 64 in 9c7f103

func runStepExecutor(step step, stage stepStage, executor common.Executor) common.Executor {

should be called for all stages and has the code for stepResult.
I noticed some log messages are not scoped in via this function in pre, like downloading the action aka (pre pre step, yes this get's weird, and it is)

@ChristopherHX I had a try with the following workflow:

name: Sample

on:
  push:
    branches: ["main"]

jobs:
  cli:
    name: CLI

    runs-on: ubuntu-latest

    steps:
      - name: Install Node
        uses: actions/setup-node@v4
        with:
          node-version: 18.x
          registry-url: 'https://registry.npmjs.org'

This has both a pre and post stage. I have attached the full json log below. There is a stepResult only for the step itself and the post stage. pre stage for some reason does not have it. In act, it would be best to always have a stepResult for every stage to ensure we can properly get back the status of it rather than having to assume it was successful.

output.log

This has both a pre

No this nodejs action has no pre step, the logger might make you believe this is the case.

This action has a pre step: https://github.com/nektos/act-test-actions/tree/main/js-with-pre-and-post-step

Downloading the action is needed to check if it has a pre step, those log messages use the same log fields as the pre step log messages.

I wouldn't add this to this change either way

No this nodejs action has no pre step, the logger might make you believe this is the case.

Downloading the action is needed to check if it has a pre step, those log messages use the same log fields as the pre step log messages.

At the moment, is there a way to properly determine when there is a real pre step?

I feel that it would make more sense for there to be a different log type to avoid this issue. What do you think? And can this be implemented easily?

is there a way to properly determine when there is a real pre step?

Checking for \u2B50 Run in message if type is pre then add it? May need to adapt the star emoji encoding for typescript.

Runner.Client logs everything as Main type and would be unaffected by such a hack.

I feel that it would make more sense for there to be a different log type to avoid this issue. What do you think? And can this be implemented easily?

..., moving downloading actions this into the setup job step makes more sense for me to align with actions/runner

moving downloading actions this into the setup job step makes more sense for me to align with actions/runner

I agree, this makes the most sense. pre step logs should strictly be for if the step truly does have a pre step.