When a workflow is triggered by schedule, the value of `gitea.event_name` in `run-name` is empty

[imkuang]

Description

Hello,

As stated in the title, I tested push, schedule, and workflow_dispatch triggers with the following workflow:

name: test
run-name: ${{ format('test ({0})', gitea.event_name) }}

on:
  schedule:
    - cron: "*/2 * * * *"
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v6

The results are as follows, when triggered by schedule, gitea.event_name is empty

I have do some simple analysis, and it might be caused by the fact that the ActionRun object generated by the ToActionRun function (introduced in #34301) does not set the TriggerEvent field. In theory, explicitly setting it to webhook_module.HookEventSchedule should work.
https://github.com/go-gitea/gitea/blob/main/models/actions/utils.go#L87

I'm not familiar with Golang and Gitea's implementation, and I currently lack a Golang development environment and enough time, so I'm merely raising the issue and a possible reason. If someone could fix it, it would be greatly appreciated.

Gitea Version

1.25.4

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Docker

Database

SQLite

[priyanshu360]

I tried reproducing this issue locally.

It is reproducible on Gitea 1.25.4, but I was not able to reproduce it on the latest 1.25.5 release or the main branch, which suggests that it may already be fixed in newer versions.

[imkuang]

I tried reproducing this issue locally.

It is reproducible on Gitea 1.25.4, but I was not able to reproduce it on the latest 1.25.5 release or the main branch, which suggests that it may already be fixed in newer versions.

Unfortunately, in my testing, version 1.25.5 still has the same issue, as shown in the screenshot below:

Additionally, during my recent retest, I discovered that the cron expression in the workflow configuration I pasted in my original post was missing quotation marks, caused the workflow to fail to start. I have just edited and fixed it.

[imkuang]

Update: I just spent some time this weekend running tests and confirmed that there are no issues with the latest code on the main branch. I will try to find out where the differences are.

[imkuang]

With the help of AI, I think I have identified the reason for the behavioral differences between the main branch code and version 1.25.5. #35624 cleaned up the relevant code and removed the call to ToActionRun, but this change was not backported to version 1.25.

@ChristopherHX Is there any plan to backport this commit? If not, that's fine—I can wait for the 1.26 release. Additionally, it seems that ToActionRun function is no longer being called, so maybe it should be removed (it did mislead me at first).

[imkuang]

Additionally, this is the simplest fix suggested by the AI for version 1.25, which indeed matches my initial idea.

[ChristopherHX]

Additionally, it seems that ToActionRun function is no longer being called, so maybe it should be removed (it did mislead me at first).

I guess that I didn't realise that this is now dead code

Is there any plan to backport this commit?

No backport had been planned by me, because of the feature concurrency support merged before cleaning up the code.

I also didn't know that it even fixed any existing bugs.