GH actions long delay between finishing build job and starting success job about django-oauth-toolkit HOT 8 OPEN

You are correct in how you describe the behavior. We are probably also throttled a bit since we have such an intense job run. A runner is allocated for every build in the matrix. Maybe explicitly selecting a different runner class for the success job would get it allocated more quickly.

from django-oauth-toolkit.

Yeah presumably these runners are all counted against the Jazzband org. Can we try this without having to bug @jezdez?

from django-oauth-toolkit.

The reason we added the success job to the build process so we wouldn't need @jezdez to intercede to change the success criteria of our builds since we don't have settings access. We should be able to select the machine class by changing runs-on for the success job. Maybe we can get away without specifying it? I'm not sure what the default is...

from django-oauth-toolkit.

I think this is something we could maybe open with Github support?

from django-oauth-toolkit.

I assume we're waiting on the backlog of jazzband jobs and it's being slowed down by the concurrent job limit, https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration

from django-oauth-toolkit.

Another option may be to go ahead and reduce our matrix dropping django 4.0 and django 4.1 since they're no longer supported upstream. That should reduce our matrix by 10 jobs. Success still won't be enqueued until they're complete...

from django-oauth-toolkit.

alternatively if @jezdez would give you, @n2ygk, or someone else on team settings access to this repo, then we could manage the branch protections ourselves and wouldn't need the success job since we could update the required checks when needed.

from django-oauth-toolkit.

@jezdez @n2ygk I fired off a request to GH support to increase the concurrent build limit for the jazzband organization.

from django-oauth-toolkit.