11 of 76 open PRs have their CI silently blocked at the fork-approval gate, oldest since 2026-10-03

Abierto
  • ¿Algo no está bien?
#1,078 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github, github-actions, python
Área
ci-cd, devops

Línea de trabajo

Start by reading the repository’s CONTRIBUTING.md and AGENTS.md review guidance, then inspect the GitHub Actions workflows and how open pull request runs are queried. The issue proposes a scheduled report for action_required runs, a repository setting change, or a documentation update; agree on the chosen scope with maintainers first. Done means the selected fix makes the approval gate visible or explains the triage step without approving unreviewed fork runs.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

agent-coded bug

Summary

11 of 76 open pull requests have their entire CI blocked at the fork-contributor approval gate. Their workflow runs sit at conclusion: action_required, which GitHub's PR view renders as no checks rather than blocked, so they read as "CI has not started yet" indefinitely and nobody is prompted to clear them. The oldest has been in that state since 2026-10-03.

Census

Taken 2026-10-28 over all 76 open PRs, counting workflow runs at conclusion: action_required on each PR's current head.

PR author last push runs blocked title
#1066 perfectmodelslab 2026-10-26 9 poll_bfl: refuse to send the API key over a plain-http polling_url
#1065 perfectmodelslab 2026-10-26 9 download: credentials ride only to the target's own origin
#1064 perfectmodelslab 2026-10-26 9 generate: recover the openapi cache instead of dying on it for a week
#1063 perfectmodelslab 2026-10-26 9 config.ini: atomic replace and a lock around read-modify-write
#1062 perfectmodelslab 2026-10-25 9 tracking: redact the path-valued options path, deps, output
#1061 perfectmodelslab 2026-10-26 9 fix: two validation paths that print their error and keep going
#1060 perfectmodelslab 2026-10-26 9 generate: decode inline b64_json answers, refresh the Gemini model enum
#1059 perfectmodelslab 2026-10-26 9 launch --background: honor --log-file and COMFY_CLI_BACKGROUND_LOG
#1058 perfectmodelslab 2026-10-26 9 launch --background: re-exec the invoked binary, not PATH's comfy
#964 wanjiang263 2026-10-03 8 fix(resolve-python): use python_embeded from a Windows portable install
#963 RaphaelFakhri 2026-10-07 8 fix(launch): re-exec background launch through the current interpreter

Four of the eleven are security-relevant (an API key sent over plain HTTP, credential scoping on download, redaction of path-valued telemetry, atomic config writes) and none of them has ever been tested by this repo's suite.

Why it is not self-correcting

Three properties combine badly:

  1. It is invisible. action_required is a terminal conclusion, so the run shows as completed. gh pr checks lists nothing, and the PR page shows no check section at all — identical to a PR whose workflows have not been triggered.
  2. It re-arms on every push. Clearing the gate approves the runs for one head only. I cleared #1016's nine runs this morning; the author then merged main into their branch and all nine were blocked again on the new head, with the PR diff unchanged.
  3. Nothing reports it. There is no label, no comment, and no notification when a run lands in this state, so the only way to find it is to query the Actions API per head, which is what this census did.

The combined effect is that a PR can look like it is waiting on review when it is actually waiting on a maintainer button, and the contributor has no way to tell the difference.

Suggested fixes, cheapest first

  1. Report it. A scheduled job that queries open PRs for action_required runs and comments once per PR (or applies a ci-blocked label) would make the state visible without changing any trust boundary. This is the one I would do first; it is a few lines of gh api and it turns an invisible state into a triageable queue.
  2. Reconsider the setting. Settings → Actions → Fork pull request workflows from outside collaborators currently appears to be "Require approval for all outside collaborators". GitHub's narrower option, approval only for first-time contributors, would unblock #1058-#1066 permanently (that contributor has nine PRs, so they are not first-time) while keeping the gate where it earns its keep. This is a judgement call about runner exposure and belongs to whoever owns that setting, not to me.
  3. Write the triage step down. CONTRIBUTING.md and AGENTS.md both describe how to run the checks locally but neither mentions that a fork PR's CI needs a maintainer to release it. A sentence in the review section would stop the next person reading action_required as "not started".

What I have and have not done

I cleared the gate on #1016 and #1039 only, because I had reviewed both diffs and confirmed neither touches .github/, scripts/, pyproject.toml, or any build config — approving a fork run executes the contributor's code on the runners, so it is a per-PR trust decision rather than a dashboard chore.

I have deliberately not cleared the other eleven. I have not read those diffs, and mass-approving unaudited fork PRs to make a census go green would be the wrong trade. They need someone to look at them, which is the point of filing this.

Found while investigating why #1016 showed no checks at all, during the converter-convergence work tracked in #1077.

Lenguaje dominante
Python
Estrellas
1k
Forks
176
Merge medio
1 d 11 h
PR fusionados (30 d)
87

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Comfy-Org/comfy-cli

Todos los issues de Comfy-Org/comfy-cli

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.