GitHub Community
Better log separation for composite actions #21276
-
|
See actions/runner#1311. Describe the enhancement 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 Additional information |
Beta Was this translation helpful? Give feedback.
Replies: 85 comments 27 replies
-
|
This is really important. Currently logs of composite actions looks like mess. Why no update on this yet? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Bumping this as well, agree with the rest of the folks |
Beta Was this translation helpful? Give feedback.
-
|
We would also greatly benefit from this |
Beta Was this translation helpful? Give feedback.
-
|
This could make things a lot nicer. Upvoting!! |
Beta Was this translation helpful? Give feedback.
-
|
We would love to have this |
Beta Was this translation helpful? Give feedback.
-
|
Bumping, this would be so helpful |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
I had to add my own action (gha-timer) to solve the need to time a log group:
but unfortunately in composite actions to print out the "echo" in the logs as
|
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
This ticket was opened nearly three years ago... |
Beta Was this translation helpful? Give feedback.
-
|
This was my secret plan to collect internet tokens all along 😂 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
It's fascinating to me that such an obvious oversight hasn't been fixed yet after this many years open. I stumbled upon this today after refactoring some of our workflows by extracting a set of common build steps into a composite action. I quickly realized how messy the logs were and decided to add a bunch of custom log groups around some of the commands in the action, which itself leads to quite a bit of duplication of intent. Things like: - name: Restore packages
shell: bash
run: |
echo "::group::Restoring packages..."
dotnet restore --locked-mode
echo "::endgroup::"Whereas it could've just been: - name: Restore packages
shell: bash
run: dotnet restore --locked-modeAnd to make things even worse, when the actual sub-step is logged, it shows the This is such a shitty experience overall. |
Beta Was this translation helpful? Give feedback.
-
|
You can use simple NOOP in bash to better visualize it i.e. will be visible in logs as: It blends better with steps that are simple: which will be visible as |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone 👋 Thank you for all the feedback here. The current experience where composite action logs are "all aggregated as if it was one big action" makes debugging difficult, and manually wrapping every command in We're working on an improvement and would love your feedback. What we're thinkingNested steps within a composite action would render as collapsible regions within the log panel. The sidebar would stay the same (your composite action still appears as a single step there), but when you click into the logs, you'd see each nested step as its own collapsible section. Each collapse bar would show:
Here's what it looks like: 
Note:
Nesting supportIf your composite action calls another composite action, the collapse bars would nest accordingly. Collapsing a parent hides all its children, keeping things tidy. 
Collapsed by defaultCompleted nested steps would render collapsed by default, keeping the log panel compact while still surfacing step boundaries. You'd expand only what you need to investigate. What stays the same
Why log panel first?We know some of you want nested steps to appear in the sidebar as separate entries. We're open to enabling that as an opt-in feature in the future. We just want to avoid suddenly converting every existing composite action to show nested steps in the sidebar. That would break assumptions around single-step logging, which could break users' automation. Even with that future option, the single-step experience still needs to be better than it currently is. You should be able to click into a composite action and see what's happening inside. Collapsible regions in the log panel address that without breaking existing behavior or automation. Does this address your needs?We think this hits the core pain points:
But we want to make sure we're not missing anything. A few questions:
We'd love to hear if this would work for your use cases. Thanks in advance! — The GitHub Actions Team |
Beta Was this translation helpful? Give feedback.
-
|
Sounds great and logical. Perhaps you could put it behind a feature toggle similar as PR page updates. |
Beta Was this translation helpful? Give feedback.
-
|
That looks quite nice. The only addition I'd suggest is a way to collapse the section from anywhere. This is super useful for very large logs that span multiple screens (which is actually quite common). Not having to scroll all the way up to be able to collapse the region would be appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds great, collapsed by default seems sensible. If any step in the composite action has failed, expanding the logs for that failed step automatically would be good though. |
Beta Was this translation helpful? Give feedback.
-
|
I really hope this finds its way soon in production! I really like the design and i've been waiting for this feature for years! |
Beta Was this translation helpful? Give feedback.
and others
Hi everyone 👋
Thank you for all the feedback here. The current experience where composite action logs are "all aggregated as if it was one big action" makes debugging difficult, and manually wrapping every command in
::group::markers shouldn't be necessary.We're working on an improvement and would love your feedback.
What we're thinking
Nested steps within a composite action would render as collapsible regions within the log panel. The sidebar would stay the same (your composite action still appears as a single step there), but when you click into the logs, you'd see each nested step as its own collapsible section.
Each collapse bar would show: