WIP: Improve support for reusable workflows

[Zettat123]

This PR aimes to improve the logic for handling reusable workflows. Key changes include:

• Introduce ParentJob to represent a job calling a reusable workflow.
• Parse reusable workflow files on Gitea side rather than by runner during execution. This ensures that jobs within the reusable workflow can be correctly picked up and executed by runners with the specified labels.

Related to https://gitea.com/gitea/act/pulls/152

---

• Create ActionRunJob for the reusable workflow caller and its child jobs.
• on.workflow_call.inputs
• on.workflow_call.outputs
• on.workflow_call.secrets
• Nesting reusable workflows
• Rerun
• UI
• Tests

Screenshots

---

This PR is not ready for review yet as there are still several changes to be made (#36388 (comment)). The CI will currently fail at this stage.

[Sirherobrine23]

Hi @Zettat123, could you take a look at this patch based on your PR? I've made some minor changes to align the logs in the same workflow

• workflow_allign.patch
• test-main.tar.gz

[Sirherobrine23]

One question, wasn't the migration supposed to continue with the old actions? I tested it with a backup, and the old actions aren't being listed. Could it be something with the sql query?

[Zettat123]

@Sirherobrine23 Thank you for the patches. This PR is currently a few commits behind the main branch, so I am in the process of updating the branch and resolving conflicts. Once the conflicts are fixed, I will attempt to apply these patches.

One question, wasn't the migration supposed to continue with the old actions? I tested it with a backup, and the old actions aren't being listed. Could it be something with the sql query?

This change won't affect previous actions. The issue you discovered appears to be a bug, and I will fix it in the next update.

---

I also noticed issue #36822 that you created; this bug is caused by Gitea improperly handling reusable workflows. It will be resolved once this PR is completed.

[Zettat123]

Hi @Sirherobrine23, due to code conflicts, I didn't apply the patch directly. Instead, I’ve created a new PR - Zettat123#1 . Could you please check if it covers all the changes from your patch?

[Zettat123]

Hi @Sirherobrine23, I have tested and reviewed your patch. Here are some concerns:

• jobIndex has been replaced by jobID. Since many parts of the current logic rely on jobIndex, this modification is incomplete. This approach requires further discussion/validation.

• Nested calls are not fully supported. While this change handles single-level calls well (e.g., Workflow A calling Workflow B), it cannot properly handle nested calls (e.g., Workflow A calling Workflow B, which then calls Workflow C).

---

The UI changes in the current PR could still be further improved. Any suggestions are welcome.

[Sirherobrine23]

I swapped jobIndex for jobID in my testing the workflows, it was quick, i tried keeping jobIndex because it wasn't locating the job, but it was something i needed to fix before sending patch

[Zettat123]

I swapped jobIndex for jobID in my testing the workflows, it was quick, i tried keeping jobIndex because it wasn't locating the job, but it was something i needed to fix before sending patch

Don't worry. I'll send another PR to replace jobIndex with jobID. After that PR, this PR will be able to locate a job by its ID.

---

#36842

[silverwind]

This review was written by Claude.

Overall, the architecture is solid and the integration test is well-designed. Here are the important issues I found:

---

Bug: Two consecutive returns in ParseRawOn (dead code)

modules/actions/jobparser/model.go:

if k != "workflow_dispatch" && k != "workflow_call" {
    return nil, fmt.Errorf("map should only for workflow_dispatch but %s: %#v", act, content)
    return nil, fmt.Errorf("map should only for workflow_dispatch or workflow_call but %s: %#v", act, content)
}

The first return makes the second one unreachable. The old error message (mentioning only workflow_dispatch) is kept instead of the corrected one. Looks like an editing mistake.

---

Bug: Dead code in checkRunNestingLevel

services/actions/reusable_workflow.go:

for cur.ParentJobID > 0 {
    if cur.ParentJobID == 0 {  // <-- can never be true inside this loop
        break
    }

The inner check is dead code since the loop condition already guarantees ParentJobID > 0.

---

expandReusableWorkflow failure is silently swallowed

In services/actions/job_emitter.go, if expandReusableWorkflow fails, it's only logged. The job remains with ChildRunID == -1 and Status == Waiting, stuck forever since CreateTaskForRunner skips jobs where child_run_id != 0. The job should be marked as failed/errored so users see the problem.

Same issue in services/actions/run.go after InsertRun where errors from expandReusableWorkflow are logged but the run/job stays in a broken state.

---

Rerun guard removed

RerunWorkflowRunJobs removed the if !run.Status.IsDone() guard. The new code only conditionally resets timestamps. This means a running workflow could now be "rerun". The IsDone() check in rerunWorkflowJob was also weakened — old code returned early if !status.IsDone(), new code returns early only if oldStatus == newStatus. A running job being set to waiting could cause races.

---

LoadAttributes called twice

expandReusableWorkflow calls parentJob.LoadAttributes(ctx), and then createChildRunFromReusableWorkflow (called immediately after) also calls parentJob.LoadAttributes(ctx). One of them is redundant.

---

Copyright year

services/actions/reusable_workflow.go has Copyright 2025 but should be 2026.

---

Missing secrets: inherit support

GitHub supports secrets: inherit to pass all parent secrets through. The current implementation only handles explicit secret mappings. Worth noting for follow-up.

[Sirherobrine23]

I'm looking at the action_run_job.child_run_id and action_run.parent_job_id column and it's showing as NULL. I had to update manually:

UPDATE public.action_run_job
SET child_run_id = 0
WHERE child_run_id IS NULL;

UPDATE public.action_run
SET parent_job_id = 0
WHERE parent_job_id IS NULL;

[Sirherobrine23]

You also need to modify repo.NumOpenActionRuns to ignore workflow_call

gitea/models/repo/repo.go

Lines 324 to 326 in 6372cd7

	repo.NumOpenProjects = repo.NumProjects - repo.NumClosedProjects
	repo.NumOpenActionRuns = repo.NumActionRuns - repo.NumClosedActionRuns
	if repo.DefaultWikiBranch == "" {

---

And some actions are no longer being triggered when the needs are defined

name: Docker build
on:
  push:
  workflow_dispatch:
  schedule:
    - cron: 0 0/2 * * *

jobs:
  check-release:
    runs-on: ubuntu-latest
    name: Check if image released
    outputs:
      LATEST_SKIP: ${{ steps.checker.outputs.LATEST_SKIP }}
      RELEASE_SKIP: ${{ steps.checker.outputs.RELEASE_SKIP }}
      # -----
      LATEST_DOCKER_TAG: ${{ steps.checker.outputs.LATEST_DOCKER_TAG }}
      RELEASE_DOCKER_TAG: ${{ steps.checker.outputs.RELEASE_DOCKER_TAG }}
      # -----
      LATEST_GIT_VERSION: ${{ steps.checker.outputs.LATEST_GIT_VERSION }}
      RELEASE_GIT_VERSION: ${{ steps.checker.outputs.RELEASE_GIT_VERSION }}
      # -----
      LATEST_GITEA_VERSION: ${{ steps.checker.outputs.LATEST_GITEA_VERSION }}
      RELEASE_GITEA_VERSION: ${{ steps.checker.outputs.RELEASE_GITEA_VERSION }}
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - uses: actions/setup-go@v4
        with:
          go-version-file: "./.github/checker/go.mod"
          cache: true

      - name: Release check
        id: checker
        uses: ./.github/checker
        env:
          GITEA_REPO: "https://github.com/go-gitea/gitea.git"
  
  main-build:
    if: needs.check-release.outputs.RELEASE_SKIP != '0' && needs.check-release.outputs.LATEST_SKIP == '0'
    needs: [ check-release ]
    name: Build main docker image
    uses: "./.github/workflows/call.yaml"
    secrets: inherit
    with:
      GITEA_TAG: ${{ needs.check-release.outputs.LATEST_GIT_VERSION }}
      DOCKER_TAG: ${{ needs.check-release.outputs.LATEST_DOCKER_TAG }}
      GITEA_REPO: "https://github.com/go-gitea/gitea.git"
      GITEA_VERSION: ${{ needs.check-release.outputs.LATEST_GITEA_VERSION }}

  release-build:
    if: needs.check-release.outputs.RELEASE_SKIP == '0'
    needs: [ check-release ]
    name: Build release docker image
    uses: "./.github/workflows/call.yaml"
    secrets: inherit
    with:
      GITEA_TAG: ${{ needs.check-release.outputs.RELEASE_GIT_VERSION }}
      DOCKER_TAG: ${{ needs.check-release.outputs.RELEASE_DOCKER_TAG }}
      GITEA_REPO: "https://github.com/go-gitea/gitea.git"
      GITEA_VERSION: ${{ needs.check-release.outputs.RELEASE_GITEA_VERSION }}

[Zettat123]

I'm looking at the action_run_job.child_run_id and action_run.parent_job_id column and it's showing as NULL. I had to update manually:

Thank you for reporting this bug. It's fixed by f6d6462

[Sirherobrine23]

gitea/models/actions/run.go

Lines 201 to 203 in 6372cd7

	SetExpr("num_action_runs",
	builder.Select("count(*)").From("action_run").
	Where(builder.Eq{"repo_id": repo.ID}),

changes count(*) to count(parent_job_id = 0)

[Sirherobrine23]

You will need to modify these files for the artifacts folder:

gitea/routers/api/v1/repo/action.go

Lines 1446 to 1452 in 6372cd7

	artifacts, total, err := db.FindAndCount[actions_model.ActionArtifact](ctx, actions_model.FindArtifactsOptions{
	RepoID: repoID,
	RunID: runID,
	ArtifactName: artifactName,
	FinalizedArtifactsV4: true,
	ListOptions: utils.GetListOptions(ctx),
	})

gitea/routers/web/repo/actions/view.go

Lines 670 to 673 in 6372cd7

	artifacts, err := db.Find[actions_model.ActionArtifact](ctx, actions_model.FindArtifactsOptions{
	RunID: run.ID,
	ArtifactName: artifactName,
	})

gitea/routers/api/actions/artifactsv4.go

Lines 496 to 499 in 6372cd7

	artifacts, err := db.Find[actions.ActionArtifact](ctx, actions.FindArtifactsOptions{
	RunID: runID,
	Status: int(actions.ArtifactStatusUploadConfirmed),
	})

gitea/routers/api/actions/artifacts.go

Lines 340 to 343 in 6372cd7

	artifacts, err := db.Find[actions.ActionArtifact](ctx, actions.FindArtifactsOptions{
	RunID: runID,
	Status: int(actions.ArtifactStatusUploadConfirmed),
	})

gitea/routers/api/actions/artifacts.go

Lines 405 to 409 in 6372cd7

	artifacts, err := db.Find[actions.ActionArtifact](ctx, actions.FindArtifactsOptions{
	RunID: runID,
	ArtifactName: itemPath,
	Status: int(actions.ArtifactStatusUploadConfirmed),
	})

gitea/services/actions/cleanup.go

Lines 196 to 199 in 6372cd7

	artifacts, err := db.Find[actions_model.ActionArtifact](ctx, actions_model.FindArtifactsOptions{
	RepoID: repoID,
	RunID: run.ID,
	})

gitea/services/actions/cleanup.go

Lines 227 to 230 in 6372cd7

	recordsToDelete = append(recordsToDelete, &actions_model.ActionArtifact{
	RepoID: repoID,
	RunID: run.ID,
	})

[Sirherobrine23]

Your last commit stopped showing the workflow childs (i use this rebase code Sirherobrine23@be75b0d):

Gravacao.da.tela.2026_03_17.15-55-07.mp4

[Zettat123]

Hi @Sirherobrine23, thanks for testing this PR. I’ve actually been working on bug fixes for the past few days. Unfortunately, the ParentJob-ChildRun hierarchy introduced by this PR broke almost all logic related to Run-Job relationships, and some of that affected logic is effectively unfixable.

As a result, I’ve had to abandon the previous implementation and begin a refactor to remove the "ChildRun" concept entirely. This work is still in progress, and there are many bugs and missing features. I appreciate your testing and suggestions, but please note that since this PR is still in active development, be sure to back up all your data before testing.

[bircni]

Updates?

[Zettat123]

This PR is now blocked by #37119. Will continue after #37119 is completed