Repository navigation
ci(pullfrog): retry the review with the fallback subscription token - #40
fabiodalez-dev wants to merge 1 commit into
Conversation
PULLFROG_OAUTH_FALLBACK can hold a second subscription token, but the workflow only ever passed the standard names — all unset here — so the agent's single credential was the one Pullfrog holds at account scope. That limit is per account and shared with interactive local use of the same subscription, and an afternoon of local work exhausts it: in the Pinakes repository every review from 16:08 onward failed with `429 ... would exceed your account's rate limit` followed by `no other model or provider was selected`, after two that had succeeded earlier. A per-account limit is not fixed by a second expression — the first credential has to be tried and seen to fail — so this is a second attempt, not an `||`. Written as `secrets.A || secrets.B` it would be worse than nothing: with no repository-level token set, that resolves to the spare one on every run and drains both quotas at once. Three details that are not obvious from the diff: - Only the presence flag is hoisted to job level, not the token. A step-level `if:` cannot read the `secrets` context at all — GitHub refuses to parse the whole workflow with `Unrecognized named-value: 'secrets'`, which I confirmed by dispatching a throwaway workflow rather than assuming. `env` is readable there, hence the flag. - The provider keys stay on the agent steps. Moving them to job level would put every token in the environment of the checkout and of the final `run:` too, which cuts against `persist-credentials: false` and `shell: restricted`. - The fallback step passes only the fallback token. If another provider were configured and usable, the first step would already have reached it, since Pullfrog walks its credentials in order. Degrades safely: with the secret unset, HAS_OAUTH_FALLBACK is false, the second step is skipped and behaviour is exactly as before. The final step restores the failure the first step's continue-on-error held back, so a review that genuinely cannot run still reports red instead of passing silently. This repository still needs the secret itself to be set for the fallback to do anything.
|
Run failed. View the logs → |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Aggiornamento: il secret è ora impostato su questo repository e il fallback è stato verificato in esecuzione, non solo nella forma. Run su
Nel log si vede il passaggio: il primo step chiude con Questo risolve anche il dubbio che avevo lasciato aperto: un run salvato dalla riserva riporta verde, non rosso. Il timore era che il primo step marcasse il check dell'action come fallito prima che Resta vera la distinzione |
This branch has not been deployed
1 participant
Il problema
PULLFROG_OAUTH_FALLBACKpuò contenere un secondo token di sottoscrizione, ma il workflow passava solo i nomi standard — qui tutti non impostati — quindi l'unica credenziale che l'agente vedeva era quella che Pullfrog tiene a livello di account. Quel limite è per account ed è condiviso con l'uso interattivo locale della stessa sottoscrizione.Nel repository Pinakes è già costato review reali: due riuscite alle 14:55 e 15:05, poi sei fallimenti di fila dalle 16:08 alle 20:47, ognuno con
Nel log del job le variabili risultano vuote, che è la prova diretta: nessun secret del repository veniva mappato.
Perché un secondo tentativo e non un
||Un limite per account non si aggira con una seconda espressione: la prima credenziale deve essere provata e vista fallire. Scritto come
secrets.A || secrets.Bsarebbe peggio di niente — senza un token a livello di repository quell'||risolve al token di riserva a ogni run, e le due quote si prosciugano insieme. Avevo aperto una PR in quella forma su FAZ-Cookie-Manager e l'ho chiusa per questo motivo.Tre dettagli non ovvi dal diff
Solo il flag di presenza sale a livello job, non il token. Un
if:di step non può leggere il contestosecrets: GitHub rifiuta di parsare l'intero workflow conUnrecognized named-value: 'secrets'. L'ho verificato dispatchando un workflow usa-e-getta invece di presumerlo. Il contestoenvlì è leggibile, da cui il flag.Le chiavi dei provider restano sugli step dell'agente. Spostarle a livello job metterebbe ogni token nell'ambiente anche del checkout e del
run:finale, contropersist-credentials: falseeshell: restrictedche questo file imposta con cura.Lo step di riserva passa solo il token di riserva. Se un altro provider fosse configurato e usabile, il primo step l'avrebbe già raggiunto: Pullfrog percorre le sue credenziali in ordine.
Verificato eseguendolo
Dispatchato sul branch, non solo letto:
continue-on-errorHAS_OAUTH_FALLBACK: false, secret assenteUna trappola che il run ha chiarito: con
continue-on-errorla UI segna quello step comesuccess, mentreoutcomeconservafailure. L'if:leggeoutcome, quindi la condizione funziona — ma leggendo solo la lista degli step si concluderebbe il contrario.Degrada in sicurezza: senza il secret il secondo step è saltato e il comportamento è identico a prima. L'ultimo step ripristina il fallimento trattenuto, così una review che davvero non può girare resta rossa invece di passare in silenzio.
Da fare a mano
Questo repository ha bisogno del secret
PULLFROG_OAUTH_FALLBACKperché la riserva faccia qualcosa: io non posso scriverlo. Finché manca, questa PR non peggiora nulla e non migliora nulla — prepara solo il posto.