search

erigontech / erigon

Ethereum implementation on the efficiency frontier https://erigon.gitbook.io
GNU Lesser General Public License v3.0
3.15k stars 1.13k forks source link

Update integration test runner #12644

Open dvovk opened 3 weeks ago

dvovk commented 3 weeks ago

In order to speedup tests it will be goo to update "ubuntu" runner to stronger one. I tried to do it by adding ubuntu-latest-erigontests-large but it doesn't work (stuck at Waiting for a runner to pick up this job...) even on main branch.

michelemodolo commented 3 weeks ago

I have set up the new runners: I checked it and they are ready to be picked up. You also correctly changed your code as requested.

The internal name of your workflow coded inside test-integration.yml is "Integration tests" which overlaps the one coded inside test-erigon-is-library.yml

Once you list the available Actions you see two "Integration tests", yet both ones point to test-erigon-is-library.yml, which invokes different runners.

I suspect that github got somehow confused by the above situation. Please change your internal workflow name (line 1 of your file).

dvovk commented 3 weeks ago

Unfortunately suggested solution didn't help.

michelemodolo commented 1 week ago

I have put https://github.com/erigontech/erigon/blob/main/.github/workflows/test-integration-erigon.yml which has been running fine for every commit (which are correctly picked up by the ubuntu-latest-erigontests-large runner too while unexpectedly emitting "Waiting for a runner to pick up this job..." in case of PRs (even though the ubuntu-latest-erigontests-large runner is always in ready state).

I raised the #3101190 case to GitHub: https://support.github.com/ticket/personal/0/3101190

michelemodolo commented 3 days ago

@dvovk I just received this feedback from Github Support:

...
 The behaviour you reported is interesting.

We can see that ubuntu-latest-erigontests-large is one of your GitHub hosted larger runners. Please, what is the job concurrency set for the runner? Please, see our [Configuring autoscaling for larger runners](https://docs.github.com/en/enterprise-cloud@latest/actions/using-github-hosted-runners/about-larger-runners/managing-larger-runners#configuring-autoscaling-for-larger-runners), which states:

You can control the maximum number of jobs allowed to run concurrently for specific runner sets. Setting this field to a higher value can help prevent workflows being blocked due to parallelism.

Does the runner eventually pickup the job, is spite of the unexpected behaviour?

Looking forward to your reply.
...

So they seem to be puzzled by this issue too.

I'm going to reply that concurrency is not a problem since that runner is always "ready" to be picked up.

I add you @antonis19 FYI since you recently raised (in discord) a problem related to this issue.

I'll keep you both updated.