Support manually triggered jobs in an existing Actions workflow run

[tulzke]

What problem would this solve?

Gitea Actions supports manually starting an entire workflow with workflow_dispatch, but it does not support manual jobs inside an existing workflow run.

This makes common deployment pipelines awkward. For example, a pipeline may automatically:

1. Build an application or container image.
2. Run tests and other checks.
3. Deploy to a test or canary environment.
4. Wait for a user to manually approve deployment to production.

With workflow_dispatch, production deployment has to be implemented as a separate workflow run. This has several drawbacks:

• It is not shown as part of the original pipeline graph.
• It is not naturally linked to the original build.
• Commit SHA, artifact ID, image tag, or other identifiers may need to be passed manually.
• The full pipeline status is harder to understand.
• It is harder to ensure that the exact artifact produced by the original run is deployed.

A manual job inside the same workflow run would make staged deployments and approval-based pipelines much easier to implement and understand.

What do you propose?

Add support for jobs that wait for explicit manual confirmation before running.

A manual job should:

• Be visible in the workflow graph from the beginning.
• Remain disabled while its dependencies are incomplete.
• Expose a Run or Play button after its dependencies succeed.
• Run inside the same workflow run.
• Use the same commit, context, and artifacts.
• Allow permissions to control who can start it.
• Trigger downstream dependent jobs after it completes.

Example pipeline:

build → tests → deploy-canary → [manual] deploy-production

Possible YAML syntax:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: ./build.sh

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: ./test.sh

  deploy-production:
    needs: test
    manual: true
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh production

The exact YAML syntax is only an example.

It may also be useful to distinguish between:

• Optional manual jobs, which do not keep the workflow in a running state.
• Blocking manual jobs, which must be started or skipped before the workflow can finish.

GitLab provides similar behavior with when: manual, displaying a Play button for the job in the pipeline graph.