Better log separation for composite actions

[Sytten]

See actions/runner#1311.

Describe the enhancement
Currently when using composite actions, the logs are all aggregated as if it was one big action.
This becomes quickly problematic to debug an error occurring in one step since we can't easily see when one step starts and one ends.

The best would be to have the "sub-steps" clearly displayed in the interface liked the steps are for a "normal" actions. We could settle for a text based split but it would not be ideal.

I feel this will be essential for if conditions to be introduced (issue actions/runner#834), otherwise it will be a mess to try to debug which steps ran and which were skipped.

Additional information
Here is what it could look like:

[sayyid5416]

This is really important. Currently logs of composite actions looks like mess. Why no update on this yet?

[nrdxp]

This is my biggest annoyance with composite actions atm. I am more than happy for them not to even be subspaced, but each step could be right at the top level just like regular steps. After all it is a "composite" of steps.

[ali-kafel]

Bumping this as well, agree with the rest of the folks

[ofek]

We would also greatly benefit from this

[hongfei-zhou]

This could make things a lot nicer. Upvoting!!

[monemihir]

We would love to have this

[EvieSchwarzIntel]

Bumping, this would be so helpful

[yonizabari]

+1

[bsda]

+1

[rakeshramakrishnan-hbk]

+1

[fspaniol]

+1

[paulovirote]

+1

[FFdhorkin]

This is a must-have. Right now, I'm forced to do some awkward stuff with multiple jobs (despite the fact it could all be in one job) in order to try to make the "build" steps visually distinct from the "test" steps.

Otherwise, if the build fails, it looks like the test job failed unless you look super closely.

[galexeyev]

+1

[oerp-odoo]

I moved one of my job steps to composite action, to solve another github actions limitation (to be able to skip jobs and still run dependent ones without needing to spam jobs with always() conditions), but now run into this issue, where composite steps are cramped into single step, which is really a mess.

[Drowze]

This also affects how Datadog traces our GitHub workflows (context: https://docs.datadoghq.com/continuous_integration/pipelines/), example:

In the screenshot above:action-parallel-test is a composite action which is reused in a few of our private repositories - would be nice to have a breakdown of each step - so that Datadog could trace that separately as well.

[AlekSi]

See also actions/runner#1877

[alberto-corrales]

+1 having composite actions should produce huge logs merged in just one step, as it makes it harder to read

[yanz-safe]

+1

[brianmichel]

Any updates on this? seems like there's general consensus from the community that this is valuable...

[jcazallasc]

+1 bump

[karleinarb]

+1

[danielkim-moloco]

+1

[jylitalo]

If your action is basically long list of shell commands, one thing that you can try is echo "::group::TOPIC IN LOGS" && echo "::endgroup::"
actions/runner#1404 has good discussion about its ups and downs.

[rahulshrivastava-eaton]

Do we have something like this for python also ?

[jylitalo]

I think it applies to anything that your stuff outputs. For example my example was taken from bash script, so you might be able to get same effect with something like print("::group::some topic") . Apparently there might be some PyPI modules that might help you, since at least JavaScript seems to @actions/core package that they use in https://octocat.dev/posts/Groups-and-formatting-in-GitHub-Actions

[ljharb]

That's awesome. The issue you linked suggests, though, that composite action groups still won't show up?

[jylitalo]

One thing that I noticed when I played around with this stuff last week was that use of grouping encourage you to combine steps into bigger chunks than what you would otherwise use, since if you have something like:

    - name: Setup Ruby
      run: |
        echo "::group::Setting up ruby environment..."

It can turn up as

➤ Run echo "::group::Installing rbenv..."
➤ Installing rbenv...

in GitHub Actions log. So if you are running list of shell commands for example, I would bundle them all into single step with echoes to handle grouping.

[Time0o]

Trying this out now, if it works it would be both a life saver and completely puzzling why GH has not yet automated this because it does seem pretty trivial to automatically insert this pre/post each step.

[mehulkar]

It would be great to make this work, and not just in the UI. The DataDog agent does not register each step as a separate "Job" in their flamegraph, and my guess is that it's because steps in composite actions are not modeled in the same way as steps in a regular workflow job.

[radiomix]

⚙️ Truncated log-lines for a step in a composite action complicates debugging a sequential step inside the same composite action ❌

You have to download/extract the logs . . . ⏳

[electricbrass]

+1

[freakyblack]

+1

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[lucasoares]

+1

I'm facing two issues with the current logging state:

• Step Execution Time – There's no way to determine exactly how long each step took to execute. While job-level execution times are displayed, this granularity is missing at the step level.
• Collapsible Logs – Some steps generate a large volume of logs, but there's no way to collapse them when needed. Steps should always be expanded by default to show complete execution log of the job, but having the option to collapse them would improve log readability and navigation. Additionally, a job-level "Collapse All" option and a setting to disable collapsing for all steps would provide greater flexibility for different use cases.

The following image illustrates the problem:

The highlighted square section shows a log that I can never collapse.
Unlike jobs, steps do not provide execution time visibility.