Advice on handling scheduled event builds

Hi @dorny,

We have a workflow containing multiple triggers:

• push events (to the default branch)
• pull requests (against the default branch)
• workflow dispatch (i.e. manually-triggered)
• scheduled events (i.e. cron)

Your paths-filter action works great for the first three use-cases, detecting the context and base to compare against. However, it fails for scheduled events giving the error This action requires 'base' input to be configured or 'repository.default_branch' to be set in the event payload.

Looking in your code at where the error is thrown, we could set a base, but I’m not sure how to set that in a way that would work for the other triggers.

Any suggestions on how to handle this? For a scheduled build there is obviously no “base” to compare against as it’s just a specific commit that is used, but ideally it would fall-back and handle this situation without raising an error?

Thanks,

Joe.

[dorny]

Sorry for the delay, I’ve been quite busy the last few months.

IMHO, there’s not much use for this action with scheduled events. At the same time, it should not stay in the way and complicate the workflow definitions more than necessary. So, I’ve come to the conclusion:

• By default, all files will be considered as changed - this will allow using the same job definition for scheduled events without any ifs. The most common usage of this action is for running tests, so running everything by default seems like a sensible default.
• If base is specified:
  • if is different than the current branch, it will be used to do the comparison as usual
  • if it’s the same as the current branch, the changes from the last commit will be used

This way it should support both behaviors that were proposed in this issue. I will make it part of the next release later this month or so. I haven’t gone through all the reported issues yet, so depends on what I will find there.

[joehorsnell]

Hi @dorny - yep, agreed, I think the best thing is for this action to just consider everything as having changed for a scheduled event. If people want specific behaviour for scheduled events, they can always do that, but the main thing is just having it not cause an error on that event type.