Composite Actions: Give users control over how verbose the step output is

[pbartolome]

Describe the bug
No output grouping on composite actions

To Reproduce
Create a composite action that uses log grouping with echo "::group::Start.." echo "::endgroup::"

name: 'Issue'
description: 'Composite example'
inputs:
  ruby-version:
    description: 'Ruby version'
    required: false
    default: '2.6.0'
runs:
  using: "composite"
  steps:
    - name: Setup rbenv
      run: |
        echo "::group::Installing rbenv..."
        brew list rbenv || brew install rbenv
        echo "~/.rbenv/shims" >> $GITHUB_PATH
        echo "::endgroup::"
      shell: bash

    - name: Setup Ruby
      run: |
        echo "::group::Setting up ruby environment..."
        rbenv install ${{ inputs.ruby-version }} -s
        rbenv local ${{ inputs.ruby-version }}
        rbenv rehash
        which ruby
        rbenv which ruby
        echo "::endgroup::"
      shell: bash
    
    - name: Bundle Install
      run: |
        echo "::group::Running bundle install..."
        gem env home
        gem install bundle
        bundle install
        echo "::endgroup::"
      shell: bash

Using this composite action on another action has the following output:

Prepare all required actions
➤ Run ./.github/actions/issue
➤ Run echo "::group::Installing rbenv..."
➤ Installing rbenv...
➤ Run echo "::group::Setting up ruby environment..."
➤ Setting up ruby environment...
➤ Run echo "::group::Running bundle install..."
➤ Running bundle install...

Expected behavior

Prepare all required actions
➤ Run ./.github/actions/issue
➤ Installing rbenv...
➤ Setting up ruby environment...
➤ Running bundle install...

This was the output of a job running on '2.280.3'

Runner Version and Platform

Version of your runner?
2.281.1

OS of the machine running the runner?
OSX

[thboop]

This is intentional, we want to show more information about the steps that are being run. We could add a feature to disable this behavior with a toggle in the composite action, so i've retagged this as an enhancement.

[umarcor]

@thboop, although field name is supported for steps in a composite action (https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runsstepsname), it seems to be ignored in the UI. IMHO., using group and endgroup should be redundant in the example above. Is there any issue tracking enhancements in this regard?

Furthermore, with regard to the toggle you mentioned, would it be feasible to "promote" the steps from a composite action for them to be shown as steps of the parent workflow?

[jpenilla]

would it be feasible to "promote" the steps from a composite action for them to be shown as steps of the parent workflow?

This would be super useful when combining multiple steps which each have a lot of log output in a composite action. Currently reading the logs becomes much more difficult with the steps in a composite action, to the point that we have just inlined the steps for some of our workflows. Using ::group:: helps, but it's still not great (and of course has the issue mentioned above).

At minimum would probably want to prefix the step name with the name of the composite action calling it, and a toggle for this behavior.

Even better would be if the steps were shown in a collapsible list under the composite step in a similar format to the steps for the root workflow. But that would be a larger UI change so might be out of scope.

#1477 seems to be related as well

[quodlibetor]

Since it's been almost exactly 2 years since the last comment I want to add another comment in favor of this.

I've been refactoring groups of actions across my teams into shared actions, and the extra log verbosity can be devastating to dev experience.

If I perform a run action it respects ::group::s within it, but there is no way to collapse useed actions from within an already nested action afaict.

For some of our actions this means going from tests that are easy to read and debug to thousands of lines of noisy build logs before the tests or lint failures appear, and the failures now stick out less.

There are workarounds, but all of them involve compromises or dev effort, education, and maintenance because devs can't just click on the little ❌ and see what went wrong.