Optionally search for workflows

[romangg]

When no workflow is set, until now the current workflow has been chosen. But the workflow we get the artifact from could be another one determined by other criteria like the branch and the artifact name.

We provide a new option workflow_search, that if set, allows us to search for the workflow repo-wide according to the other provided data.

This is a failing job with upstream action v3: https://github.com/romangg/theseus-ship/actions/runs/7904208512/job/21573949899

This is a successful job ran against the version from this PR: https://github.com/romangg/theseus-ship/actions/runs/7906156620/job/21581226467

In my case the workflows are named differently depending on them being a scheduled workflow or a workflow on push.

This new option defaulting to false should be compatible with current usage of the action.

[dawidd6]

Nice, thanks!
Let's see if anything breaks 😄.

[etripier]

@romangg @dawidd6 Hello, it looks like the latest version of this action is exhausting our GitHub rate limit. From a very cursory look it seems like you're getting all workflow runs in the current repo if the immediate workflow run is unable to be found, and then checking the workflow run against the GitHub API for every run in said repo. That's a lot of requests.

[dawidd6]

@etripier @romangg care to take a look and provide some PR? If not, maybe we should revert?

[etripier]

I don't have time, unfortunately. But a revert might be the safest option.

[romangg]

I can take a look later today. So the issue is that listWorkflowRunsForRepo is too heavy, right?

That should only be called though when no workflow was provided. Something that shouldn't have worked before anyway. Can I take a look at your repo @etripier?

[romangg]

@etripier Can you try #271? It restores a parameter to the request that is the commit which got moved to the body for no good reason. If you in your pipelines provided the commit value, that might be the reason why you're thitting the rate limit and it's not about the new listWorkflowRunsForRepo after all.