search

dorny / paths-filter

Conditionally run actions based on files modified by PR, feature branch or pushed commits
MIT License
2.14k stars 239 forks source link

Scheduled build always running even if no change in filter path #213

Open mallikkml opened 8 months ago

mallikkml commented 8 months ago

Here is the log of github action:

Run dorny/paths-filter@v2
Get current git ref
**Warning: 'before' field is missing in event payload - changes will be detected from last commit**
Change detection in last commit
Detected 668 changed files
Results:
**Filter changed = true
Changes output set to ["changed"]**

Is there a way to fix this?

dorny commented 8 months ago

@mallikkml I could give you a better answer if you add a relevant part of your workflow file.

In general, this warning means the action is set to detect changes against the same branch. However the event that triggered the workflow is not a "push" event with a "before" field. That field normally provides information about the last commit on the branch before the new commits were pushed. So on a best-effort basis, the action detected changes only from the last commit in the git history, which might not be what you want.

dorny commented 8 months ago

@mallikkml I just remembered about a similar issue from a long time ago. Please look at this issue: https://github.com/dorny/paths-filter/issues/100

Summary - there's no sensible default as to how this action should behave for scheduled builds. You have to detect changes against some other branch/tag or provide it commit sha you figure out yourself.

What would be the desired behavior in your case?

jsoref commented 8 months ago

I'd argue the best behavior would be since the last time the same workflow ran for the same event.

So, if .github/workflows/test.yml ran for on: schedule 3 days ago and is running now, the changes should be between the commit that it ran 3 days ago and the commit it's running on now.

I think that's technically a calculable thing. (It obviously requires permissions:actions:read)

It might not be easy, but it's defensible.

n.b. I don't intend to use this feature, I'm currently answering someone else's complaint about a github feature and I gave up and suggested this action because I needed to suggest something, so now I'm reviewing its open issues.

mallikkml commented 8 months ago

@dorny Thanks for sharing all the details, I had gone through issue: #100

My understanding is base value is missing for scheduled builds, due to this main seems to be considered as base and this is leading filter to return change as true.

I am looking for a solution or workaround to overcome on this and filter to return true only when there is a change.