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.

[pazmariano]

+1 bump

[jmgilman]

+1 This was initially presented in #1311 almost precisely three years ago.

[cavadibrahimli1]

+1

[nebuk89]

ooh interesting. This is a pain point I haven't actually seen before :) let me dig in and learn. I will ensure that this goes onto our backlog of pain points to look at this year and if I have questions I will ensure I come back to this thread.
No timeline yet 💔 , but we will ensure it's on the list.

[shanesavoie]

Thanks. It's not just a visual issue. It's difficult to ingest metrics and effectively determine bottlenecks when Composite Actions are rolled into a single step. Hopefully a solution will also result in more fine grained metrics.

[nebuk89]

ooh sorry I missed the offers! For those who are happy to run me through it :) if you give me permission I will nab an email address and drop you something over. (Trying to stay on lots of these has made my notifications a bit 🔥 ). Also with the caveat I have some leave coming up for a personal matter, so there may be a delay in the setup of that!

[ljharb]

You have my permission, i look forward to it.

[Sytten]

@nebuk89 You guys need better ways to handle customer feedback than random PM seeing a post after two years by accident...

[danielg25]

How would you prioritize pain points if you managed this backlog?

[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

[danielkim525]

+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.

[jylitalo]

If you have a step in your action, where it does:

echo "::group::terraform init"
terraform init
echo "::endgroup::"
echo "::group::terraform validate"
terraform validate -no-color
echo "::endgroup::"
echo "::group::Pull state and re-init"
terraform state pull > terraform.tfstate
sed 's|backend "s3"|backend "local"|g'<provider.tf|\
grep -v -E '(bucket|dynamodb_table|encrypt|key|region)[ ]+='> local.tf
rm -rf .terraform provider.tf
terraform init
echo "::endgroup::"
echo "::group::Refresh"
terraform refresh -lock=false
echo "::endgroup::"

It will show up on your logs as:

And if you want to know what happened in terraform init, you just click the triangle and it will show you output of that command.
As an outcome, you are able to split the log into groups, which allows you to easily find the parts that your interested about.

[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.

[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 . . . ⏳