"Approve run" is a major pain when managing large OSS ecosystems

I understand why “approve run” was introduced for GitHub actions but it is one of the worst features introduces by GitHub - imo - ever. Other CI systems like CircleCI never had to introduce such a feature even though they are surely also seeing crypto mining attacks.

“Approve run” is fundamentally broken because:

  1. If I approve a run and the contributor makes a change, I have to approve the run again.
  2. Contributors that have made contributions to other repos in the org still require “approve run” if they contribute to another repo in the ecosystem.
  3. Some GH actions take 30 minutes or more to complete. This significantly increases the time for PR turnover and frustrates both maintainers as well as contributors. My review schedule now often looks like this:
    1. I have time to review PRs now
    2. Go through PRs - notice CI did not run yet
    3. Approve CI run
    4. Continue with some other work and come back in a day or two to see the CI probably fail due to some broken tests or regressions introduced
    5. Ask for changes and repeat with step 1
  4. Maintainers of large OSS ecosystems are overburdened with managing contributions, issues, and more. Now we are also burdened with making sure that GH doesn’t run malicious actions?

Generally, I believe the current approval system is inherently broken. It would be so easy to introduce a trust level which could be elevated by contributing several changes to larger OSS systems, or judging by account age or activity. Instead OSS maintainers hammer “approve run” over and over and over again.

What are the plans in GitHub to address these issues? To me, the introduction of that features looks like a panic reaction. My hope is that these issues get addressed because right now, GitHub Actions is more or less unusable for large OSS projects.


Let’s join forces here: How to auto-approve workflow runs for first-time contributors? - #8 by alcalzone