Gitea Action didn't use last commit when action is triggered by schdule

[ChaojuWang]

Description

I set up a workflow to exec routine action every day but the action uses outdated commit when checkout the code.



It seems that the action checkout the 2rd commit during running.

here is part of my workflow

name: XXX

on:
  schedule: # execute every 24 hours
    - cron: "35 6 * * *"
...
 steps:
    - name: XXX
      uses: actions/checkout@v4
      with:
        path: xxx
...

Gitea Version

1.22.2

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.45.2

Operating System

Docker 27.0.3 in Ubuntu 22.04.4 LTS

How are you running Gitea?

Docker 27.0.3 in Ubuntu 22.04.4 LTS
start both Gitea and runner by docker-compose

Database

SQLite

[yp05327]

I can not reproduce it immediately, but I can see the same issue in Gitea.com like https://gitea.com/gitea/docs

adminxxxx is pushed at 10/9 PM 9:00

more changes and upgrade to 1.22.3 is pushed at 10/9 PM 3:03
So the title of the schedule should be more changes?

These there commits all failed during set up job. Maybe it is related.

[Zettat123]

I don't know the cause of this issue. But to fix it, you can disable "Actions" and then enable it in the repo's settings page. This operation will make Gitea re-detect scheduled workflows, which should be able to make the workflow use the latest commit.

[ChaojuWang]

in my case the action checkout the 2rd commit in main branch.
maybe the gitea pass the wrong ref info to the runner?

According to the doc, it seems that the checkout action use $GITHUB_SHA as default commit.

[ChaojuWang]

I don't know the cause of this issue. But to fix it, you can disable "Actions" and then enable it in the repo's settings page. This operation will make Gitea re-detect scheduled workflows, which should be able to make the workflow use the latest commit.

I've closed and reopened the flow. It should be run on next scheduled time.

Hope that the 1.23 can be released soon, so we can manually active the flow.

[Zettat123]

I've closed and reopened the flow. It should be run on next scheduled time.

I'm not sure what you mean by "closed and reopened the flow". To make Gitea re-detect schedule workflows, you need to go to the setting page of this repo, then disable and enable the "Actions". I hope this would help.

[ChaojuWang]

I'm not sure what you mean by "closed and reopened the flow". To make Gitea re-detect schedule workflows, you need to go to the setting page of this repo, then disable and enable the "Actions". I hope this would help.

Thanks
I tried to close and reopen the workflow before.

[ChaojuWang]

I've closed and reopened the flow. It should be run on next scheduled time.

I'm not sure what you mean by "closed and reopened the flow". To make Gitea re-detect schedule workflows, you need to go to the setting page of this repo, then disable and enable the "Actions". I hope this would help.

The first workflow works fine at Oct 10, 2024, 11:36.

The first workflow pushed a commit.

But the second workflow used the old commit again while running.

[Zettat123]

Does your workflow push any commits to the main branch?

[lunny]

I can not reproduce it immediately, but I can see the same issue in Gitea.com like gitea.com/gitea/docs

adminxxxx is pushed at 10/9 PM 9:00 more changes and upgrade to 1.22.3 is pushed at 10/9 PM 3:03 So the title of the schedule should be more changes?

These there commits all failed during set up job. Maybe it is related.

That is different problem. That is because there is an action's repository disappeared from Github.

[Zettat123]

I can not reproduce it immediately, but I can see the same issue in Gitea.com like https://gitea.com/gitea/docs

adminxxxx is pushed at 10/9 PM 9:00 more changes and upgrade to 1.22.3 is pushed at 10/9 PM 3:03 So the title of the schedule should be more changes?

These there commits all failed during set up job. Maybe it is related.

The reason why the run #276 does not use d2ff4a6117 is that d2ff4a6117 was pushed to another branch (not the main branch, see PR). And I guess this PR used "Fast-forward" merge style so no merge commit was created and nothing was pushed to the main branch when this PR was merged. As a result, Gitea did not re-detect the schedule workflow and the schedule task was not updated.

gitea/services/actions/notifier_helper.go

Line 177 in cb739f5

shouldDetectSchedules := input.Event == webhook_module.HookEventPush && input.Ref.BranchName() == input.Repo.DefaultBranch

[ChaojuWang]

Does your workflow push any commits to the main branch?

yes

[ChaojuWang]

I can not reproduce it immediately, but I can see the same issue in Gitea.com like https://gitea.com/gitea/docs
adminxxxx is pushed at 10/9 PM 9:00 more changes and upgrade to 1.22.3 is pushed at 10/9 PM 3:03 So the title of the schedule should be more changes?
These there commits all failed during set up job. Maybe it is related.

The reason why the run #276 does not use d2ff4a6117 is that d2ff4a6117 was pushed to another branch (not the main branch, see PR). And I guess this PR used "Fast-forward" merge style so no merge commit was created and nothing was pushed to the main branch when this PR was merged. As a result, Gitea did not re-detect the schedule workflow and the schedule task was not updated.

gitea/services/actions/notifier_helper.go

Line 177 in cb739f5

shouldDetectSchedules := input.Event == webhook_module.HookEventPush && input.Ref.BranchName() == input.Repo.DefaultBranch

In my case, the workflow pushed the commit to the main branch directly without any merge or PR.
And there is a huge time gap between two workflows so they won't be executed together.

[Zettat123]

Now I know the cause of this issue. To avoid loop triggering, changes pushed by actions won't trigger workflow detection. This is by design.

gitea/services/actions/notifier_helper.go

Lines 118 to 125 in 900ac62

	func notify(ctx context.Context, input *notifyInput) error {
	if input.Doer.IsActions() {
	// avoiding triggering cyclically, for example:
	// a comment of an issue will trigger the runner to add a new comment as reply,
	// and the new comment will trigger the runner again.
	log.Debug("ignore executing %v for event %v whose doer is %v", getMethod(ctx), input.Event, input.Doer.Name)
	return nil
	}

To resolve this issue, you can create a new token that includes write permission to the repo. And use this token in your workflow like

      - uses: actions/checkout@v4
        with:
          token: ${{ secrets.YOUR_TOKEN }}

Then the changes pushed to the repo will be able to trigger workflow detection so that the schedule tasks will use the latest ref.

---

And I'm also thinking that we should allow Gitea to re-detect schedule tasks even if the doer is "ActionsUser". I did some testing on GitHub and found that changes pushed by the "ActionsUser" are also able to trigger updates to schedule tasks.