Actions support workflow dispatch event

[pangliang]

fix #23668

My plan:

• In the actions.list method, if workflow is selected and IsAdmin, check whether the on event contains workflow_dispatch. If so, display a Run workflow button to allow the user to manually trigger the run.
• Providing a form that allows users to select target brach or tag, and these parameters can be configured in yaml
• Simple form validation, required input cannot be empty
• Add a route /actions/run, and an actions.Run method to handle
• Add WorkflowDispatchPayload struct to pass the Webhook event payload to the runner when triggered, this payload carries the inputs values and other fields, doc: workflow_dispatch payload

Other PRs

• the Workflow.WorkflowDispatchConfig() method still return non-nil when workflow_dispatch is not defined. I submitted a PR https://gitea.com/gitea/act/pulls/85 to fix it. Still waiting for them to process.

Behavior should be same with github, but may cause confusion. Here's a quick reminder.

• Doc Said: This event will only trigger a workflow run if the workflow file is on the default branch.
  • If the workflow yaml file only exists in a non-default branch, it cannot be triggered. (It will not even show up in the workflow list)
  • If the same workflow yaml file exists in each branch at the same time, the version of the default branch is used. Even if Use workflow from selects another branch

name: Docker Image CI

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning'
        type: choice
        options:
        - info
        - warning
        - debug
      tags:
        description: 'Test scenario tags'
        required: false
        type: boolean
      boolean_default_true:
        description: 'Test scenario tags'
        required: true
        type: boolean
        default: true
      boolean_default_false:
        description: 'Test scenario tags'
        required: false
        type: boolean
        default: false
      environment:
        description: 'Environment to run tests against'
        type: environment
        required: true
        default: 'environment values'
      number_required_1:
        description: 'number '
        type: number
        required: true
        default: '100'
      number_required_2:
        description: 'number'
        type: number
        required: true
        default: '100'
      number_required_3:
        description: 'number'
        type: number
        required: true
        default: '100'
      number_1:
        description: 'number'
        type: number
        required: false
      number_2:
        description: 'number'
        type: number
        required: false
      number_3:
        description: 'number'
        type: number
        required: false

env:
  inputs_logLevel:              ${{ inputs.logLevel }}
  inputs_tags:                  ${{ inputs.tags }}
  inputs_boolean_default_true:  ${{ inputs.boolean_default_true }}
  inputs_boolean_default_false: ${{ inputs.boolean_default_false }}
  inputs_environment:           ${{ inputs.environment }}
  inputs_number_1:              ${{ inputs.number_1  }}
  inputs_number_2:              ${{ inputs.number_2  }}
  inputs_number_3:              ${{ inputs.number_3  }}
  inputs_number_required_1:     ${{ inputs.number_required_1  }}
  inputs_number_required_2:     ${{ inputs.number_required_2  }}
  inputs_number_required_3:     ${{ inputs.number_required_3  }}

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: ls -la
      - run: env | grep inputs
      - run: echo ${{ inputs.logLevel }}
      - run: echo ${{ inputs.boolean_default_false }}

[wizpresso-steve-cy-fan]

Well, the problem is, you can specify some user-supplied fields for workflow_dispatch, have you handled that case as well?

[pangliang]

Well, the problem is, you can specify some user-supplied fields for workflow_dispatch, have you handled that case as well?

I plan to implement a version similar to github, providing a form that allows users to fill in the env parameters of the workflow run, and these parameters can be configured in yaml. Hopefully I can complete it

[yp05327]

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch

Should we also follow this note?

[yp05327]

In the actions.list method, if workflow is selected and IsAdmin, check whether the on event contains workflow_dispatch. If so, display a Run workflow button to allow the user to manually trigger the run.

IMO, this notification takes too many spaces, and we don't need to always display it at there?
How about put it into the dropdown menu?

Not a block, feel free to discus.

[pangliang]

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch Should we also follow this note?

I think it should be following now.

• When list workflow, DefaultBranch is used
• When running workflow_dispatch workflow, the target ref is selected and specified, but the workflow configuration still uses DefaultBranch

[pangliang]

In the actions.list method, if workflow is selected and IsAdmin, check whether the on event contains workflow_dispatch. If so, display a Run workflow button to allow the user to manually trigger the run.

IMO, this notification takes too many spaces, and we don't need to always display it at there? How about put it into the dropdown menu?

Not a block, feel free to discus.

At first I also tried to put it in the dropdown menu, but there was a confusing problem. When no child elements exist, the dropdown menu will not hide automatically. Then it is more difficult to deal with when to display the button

if a or b or c or .... then
   <dropdown>
          if a then
              <menu a>
          end
          if b then
              <menu b>
          end
          ...
   </dropdown>
end

I don't know, I feel a little OCD here

Maybe I'm using it the wrong way, so I copied the design from github
If you have a good solution please tell me, Or I can put it in dropdown. After all, there are only two if conditions now.

[yp05327]

It is a required input, but it is empty.

[yp05327]

• environment: gitea doesn't support the environment feature yet, right? Maybe act_runner uses environment as a keyword, so it can't get the value of inputs.environment

gitea doesn't support the environment feature yet, right? Maybe act_runner uses environment as a keyword, so it can't get the value of inputs.environment

If I set a default value, it works. Maybe it is caused by something else.

And if I change the default value, it will still be the default value.
So it seems that it will only display the default value, but not the value in the form.

[silverwind]

I will give this UI another test. There are some minor tweaks left to do.

[kirill-shtrykov]

Is it possible to include workflows from all branches in the list?
Additionally, after specifying which branch to launch the workflow from, the inputs and the entire workflow aren't pulled from this branch.

[yp05327]

@pangliang
can you link this PR to 23668 correctly?
use fix or other keywords instead of related

[Renerick]

Is API endpoint for workflow_dispatch planned?

[0xa1d0]

Is this coming in any time soon? 😁

[pandatix]

Is this coming in any time soon? 😁

Planned for 1.23 given the milestones, still waiting for 1.22 so not tomorrow but I hope not too long too !

[lunny]

I think we need to keep the sequences?

[pangliang]

Workflow Dispatch Payload is to transmit data to act_runner, and the WorkflowDispatch type in nektos/act uses the kv structure. workflow.go#L77

To maintain order when displaying the inputs form, need to create a separate new same type for the view and use an array to store the Inputs. Because I think it will not be accepted to directly modify the kv of nektos/act into an array.
Previously discussed here: (issuecomment-1859484485)[https://github.com//pull/28163#issuecomment-1859484485]

in short:

• New WorkflowDispatchInput WorkflowDispatch and workflowDispatchConfig in gitea/routes/web/repo/actions/view.go, to maintain the order of inputs in forms
• Keep the kv of WorkflowDispatchPayload unchanged to adapt to nektos/act

What do you think? If you think it is feasible, I will modify it like this.

[lunny]

And the first branch is not default branch.

[pangliang]

This logic seems to be to ensure that the default branch is first; reference from: repo.go#L687

[silverwind]

The branch selector in this PR was very broken, I patched it up now to be similar to the one in the issue list. It did require a few JS changes unfortunately because the one in the issue list was written in a very non-reusable fashion.

There is more to do on the form fields, I will check later.

[yp05327]

Have you tested long branch name?

[silverwind]

I will, but the overflow: hidden css is active, so I assume it will work. This CSS has one issue with cutting off g letters thought, likely I'll fix that in another PR.

[silverwind]

Branch selector will need more adjustments after #30803 merges. Sorry to hold this PR off, but it's basically previous contributor's fault for leaving it in such a messy and non-reusable state.

[ghnp5]

it's basically previous contributor's fault

No problem for holding the PR, and if things have to be improved, then things have to be improved.

But it's not nice to put a blame like that to someone who is just trying to help and contribute... for free.

Even if it's "technically true", no one is born knowing all the proper design patterns and all codebase's standards, etc...

To every contributor -- thank you for improving Gitea 🧡

[bencurio]

I suggests adding a new API endpoint to facilitate the dispatching of workflows. It empowers developers and teams to automate repetitive tasks and orchestrate complex workflows efficiently.

Create a workflow dispatch event

Payload:

POST /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches
Content-Type: application/json
Authorization: Bearer <token>

{
  "ref": "main",
  "inputs": {
    "param1": "value1",
    "param2": "value2"
  }
}

Permissions:

• "Actions" repository permissions (write)

Additional endpoints:

• Enable workflow (PUT /repos/{owner}/{repo}/actions/workflows/{workflow_id}/enable)
• Disable workflow (PUT /repos/{owner}/{repo}/actions/workflows/{workflow_id}/disable)
• Get a workflow (GET /repos/{owner}/{repo}/actions/workflows/{workflow_id})
• Get workflow usage (GET /repos/{owner}/{repo}/actions/workflows/{workflow_id}/timing)
• List repository workflows (GET /repos/{owner}/{repo}/actions/workflows)