support max-parallel calls

[pharindoko]

Hey,

I have the case that one of my colleagues built up a matrix with 40 jobs and limited it with max-parallel option to 5....
https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations#defining-the-maximum-number-of-concurrent-jobs

The issue:
This triggers in background still all 40 calls and the step functions to create ec2s, but only 5 jobs will start immediately while the other jobs and ec2-instances are idle and will timeout after 10 minutes.

Usually one job runs for minimum 1 hour and I would not like to run all those instances in idle mode for that timeframe without doing anything.

Any idea how to deal with this ?

br,

@pharindoko

[kichik]

Oh that's very interesting. Any chance you have the workflow_job webhook payload on hand for those? Sounds like they're all just action: 'queued'. But is there anything else in there that might suggest they're queued but delayed?

[kichik]

We had a similar issue before with waits and fixed it in #416

Hopefully there is a similar way to detect this condition.

[pharindoko]

Oh that's very interesting. Any chance you have the workflow_job webhook payload on hand for those? Sounds like they're all just action: 'queued'. But is there anything else in there that might suggest they're queued but delayed?

at least not in the properties Ive seen in the stepfunctions. Yes I assume theres a wait state on it.
sorry will check the payload if there`s a state waiting on it in gh...

[pharindoko]

Ok we tried it out with max-parallel
=> status is "queued" in webhook request payload even for runners that are just waiting and no property to identify that the workflow itself is in a waiting state....

[kichik]

I tried this myself and observed the same issue. The webhook payload doesn't seem to have any indication it will be waiting to schedule the job.

Only workaround I can think of right now, which is very hacky, would be using provider selector (#837) to filter out some of these jobs based on some label. You will then be able to use warm runners (#836) in the future to catch the jobs when they finally schedule.

It would be far better if GitHub could provide some indication in the payload. Maybe you have some connections in GitHub to ask for this since you are using GHES?