Actions step status display error when use composite action

[seepine]

Description

The composite action .gitea/actions/action-docker-build-push/action.yml

name: 'Docker build and push'
description: 'Setup docker, build image and push'

inputs:
  password:
    description: 'Password or personal access token used to log against the Docker registry'
    required: false

runs:
  using: 'composite'
  steps:
    - run: "echo a: Set up QEMU"

    - run: |
        sleep 10
        echo 'sleep 10 end'

    - run: "echo b: Login to DockerHub"
      if: ${{ inputs.password != '' }}

    - run: |
        sleep 10
        echo 'c: Set up Docker BuildX'

The workflows file .gitea/workflows/build-docker.yml

name: Gitea Actions Demo
on: [push]
jobs:
  build-docker:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Docker build push
        uses: ./.gitea/actions/action-docker-build-push

      - run: echo The end

When the echo 'a: Set up QEMU' step run done, the status is success although there are still two more steps ahead. And then the b: Login to DockerHub step skip, the status is skip.

Gitea Version

1.22.0

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

Git Version

No response

Operating System

No response

How are you running Gitea?

docker

Database

MySQL/MariaDB

[Sharaf5]

This is directly related to my issue https://gitea.com/gitea/act_runner/issues/553 but you discribed it better than me

[ChristopherHX]

This is directly related to my issue https://gitea.com/gitea/act_runner/issues/553 but you discribed it better than me

I don't think so, because I know that reusable workflows and composite actions are fundamentally different concepts.

reusable workflows	composite actions
contains jobs	contains steps
can be referenced as a job via uses specify a yaml file	can be referenced as step via uses, specify a folder
file must be under .github/workflows Not for gitea	must be a file called action.yml or action.yaml
same format as regular workflow with a workflow_call trigger	action metadata format

Pure act_runner bug, my third party Gitea Actions Runner has no such issues. Only that the action.yml of this issue is not parseable by actions/runner written by GitHub and doesn't have the required shell property for run steps.

A fully conform action.yml file could look like

name: 'Docker build and push'
description: 'Setup docker, build image and push'

inputs:
  password:
    description: 'Password or personal access token used to log against the Docker registry'
    required: false

runs:
  using: 'composite'
  steps:
    - run: |
        echo 'a: Set up QEMU'        
      shell: bash

    - run: |
        echo 'b: Login to DockerHub'        
      if: ${{ inputs.password != '' }}
      shell: bash

    - run: |
        echo 'c: Set up Docker BuildX'        
      shell: bash

[Sharaf5]

The setup provided by @seepine is not matching your comparison table @ChristopherHX «Docker build push» is calling workflow from the same repo

Seems I need to dig concepts more

but I thought we both needed the same setup where we call a workflow inside the same repo from multible other working workflows

[ChristopherHX]

The setup provided by seepine is not matching your comparison table

seepine description matches all point of my comparsion table for composite actions, it's clearly not calling a reusable workflow

• uses is in the steps block
• uses specifies the folder that contains an action.yml file
• the composite action has an action.yml
• the action yaml uses the action metadata format

[Sharaf5]

Then this is a reusable workflow files-changed

that is called like this

and this is a composite action build_sdist

that is called like this

Am I right ?

[ChristopherHX]

Yes this is correct

[Sharaf5]

@ChristopherHX Thanks alot for clarification that realy helped me much

[yp05327]

I can not run the provided workflow unless I changed it: from:

    - run: echo 'a: Set up QEMU'

    - run: echo 'b: Login to DockerHub'
      if: ${{ inputs.password != '' }}

    - run: echo 'c: Set up Docker BuildX'

I got this error:

to:

    - run: 'echo a: Set up QEMU'

    - run: 'echo b: Login to DockerHub'
      if: ${{ inputs.password != '' }}

    - run: 'echo c: Set up Docker BuildX'

All done:

[seepine]

除非我更改它，否则我无法运行提供的工作流：from：

    - run: echo 'a: Set up QEMU'

    - run: echo 'b: Login to DockerHub'
      if: ${{ inputs.password != '' }}

    - run: echo 'c: Set up Docker BuildX'

我收到此错误：

自：

    - run: 'echo a: Set up QEMU'

    - run: 'echo b: Login to DockerHub'
      if: ${{ inputs.password != '' }}

    - run: 'echo c: Set up Docker BuildX'

全部完成：

Sorry, that was cut from my previous steps. I update the https://github.com/go-gitea/gitea/issues/31397#issue-2357231032 , and it can work now and the added sleep step can reflect the difference.

[yp05327]

Thanks for the update. Now I can reproduce it.

[yp05327]

It seems that it is caused by upstream. These statuses come from act_runner, and it says it is success -> skipped -> success again:

(the step id 1's status is strange)

[yp05327]

the skip status comes from here:

The root reason is that Docker build push uses local actions, and it contains several steps, act_runner reports the status of theses steps one by one , so the status of Docker build push will be changed three times.

It seems that we need to check the layout level of the job steps, if it is the root of the step, wait for all child steps finished and report the status.

[ChristopherHX]

Yes the reporter of act_runner doesn't make use of the "stepId" logger field to ignore stepReults of composite steps.

For example if this array has length > 1 it's within composite see here (actually my runner takes a different approuch an stores whatever stepresult was the last one and sends it when the root step advances to the next one) https://github.com/ChristopherHX/github-act-runner/blob/main/actionsdotnetactcompat/act_worker.go#L99-L106

don't report the stepResult for them

Fancy UI's could visualize the logging results of composite actions via collapsable step groups, not even gh implements that feature enhancement