fix: make check-for-non-releasable-actions action run on any actions/ change

[dsotirakis]

After #588 got merged, I realized that the action wasn't triggered in the automated release-please PRs, even if the CHANGELOG changes, which lives in actions/ directory.

This PR should fix the issue, by adding the double-start glob pattern.

[iainlane]

Wasn't the point to trigger only if an action is added or removed? I made a comment asking if that was how it worked, and it made sense to me that if it did then this was a good way to behave. The file should only be able to drift when the action changes, it's modified itself or when actions are added/removed, right?

Said in a different way, I'm not sure that it should have run when #588 got merged.

Or doesn't it work like that after all?

[dsotirakis]

Wasn't the point to trigger only if an action is added or removed? I made a comment asking if that was how it worked, and it made sense to me that if it did then this was a good way to behave. The file should only be able to drift when the action changes, it's modified itself or when actions are added/removed, right?

Said in a different way, I'm not sure that it should have run when #588 got merged.

Or doesn't it work like that after all?

Yeah sorry that's right, I wasn't clear. The expectation should be that it should run only for additions/removals of actions in the actions/ directory. It just occurred to me though that we should have this check in case someone renames the action? 🤔

[iainlane]

Wasn't the point to trigger only if an action is added or removed? I made a comment asking if that was how it worked, and it made sense to me that if it did then this was a good way to behave. The file should only be able to drift when the action changes, it's modified itself or when actions are added/removed, right?
Said in a different way, I'm not sure that it should have run when #588 got merged.
Or doesn't it work like that after all?

Yeah sorry that's right, I wasn't clear. The expectation should be that it should run only for additions/removals of actions in the actions/ directory. It just occurred to me though that we should have this check in case someone renames the action? 🤔

Yeah, be good to check how this existing check behaves! I wasn't totally sure but you gave me confidence 😄

[dsotirakis]

Renaming an existing action or adding/removing a new one doesn't work :(

But I guess what we also need is a single star (*) actually? So only adding a new folder (a new action) should trigger this? Let's go with that.

[dsotirakis]

Next test, change the target branch in this PR, to fix-trigger-paths (current PR) and it correctly doesn't trigger the action since nothing is touched.

[dsotirakis]

So current implementation doesn't work, also single star glob pattern doesn't work either on renames or additions (tried both actions/* and actions/*/), so I guess double star should be fine. On any change that happens in actions/, we'll be triggering this action.

[iainlane]

Looks good. I'd consider removing the path filters completely, and then we can make the check a required one.

[dsotirakis]

Looks good. I'd consider removing the path filters completely

Hmm, I think paths could still be valuable for example to avoid running the check if we add new workflows (not actions) or touching stuff outside of the actions/ directory.

we can make the check a required one.

That's a good point though. Let's merge it now and revisit. I'll create an issue about it. Maybe we can also use the policy bot?

[iainlane]

Maybe we can also use the policy bot?

No afraid not, not since we're using the merge queue - #478 is relevant to this. Running checks more often than needed is the best way we have right now sadly 😢

[dsotirakis]

Ugh okay - then it makes sense to close this PR and open a new one which removes the paths completely!

[dsotirakis]

closing in favor of: #600