[CI] quality-gates — la deroga owns-auth-roles non arriva allo step e blocca node-user-profiling #8

New Issue

2026-09-07T19:29:16Z

LucaZanni commented

2026-09-07 19:29:16 +00:00

Sintomo

node-user-profiling ha la CI rossa da tre push consecutivi (run 26374, 27457, 27540). Fallisce sempre lo stesso step di quality-gates.yml@v1:

::error::Questo repository dichiara ruoli in auth.ruoli, che appartiene a node-user-profiling.

migrations/10_seed_auth.sql:9:INSERT INTO auth.ruoli ...
migrations/11_seed_cliente_role.sql:14:INSERT INTO auth.ruoli ...
migrations/12_seed_servizioesterno_role.sql:15:INSERT INTO auth.ruoli ...
migrations/13_seed_ruoli_funzionali.sql:38:INSERT INTO auth.ruoli ...
migrations/15_seed_automazioneflussi_role.sql:29:INSERT INTO auth.ruoli ...
migrations/22_ruolo_notespese_write.sql:37:INSERT INTO auth.ruoli ...

Il gate sta bloccando il repository proprietario dello schema, cioè l'unico a cui quei sei INSERT sono legittimamente concessi. Tutti gli step successivi (npm ci, lint, typecheck, format, build, test) risultano skipped: da tre push non si sa più niente della qualità del codice di quel microservizio.

Causa

Lo step nasce con la propria deroga:

      - name: Nessun ruolo dichiarato fuori da node-user-profiling
        if: ${{ !inputs.owns-auth-roles }}

e node-user-profiling/.gitea/workflows/ci.yml passa correttamente owns-auth-roles: true dal commit 4ec9706 (28/08, undici secondi prima del commit 67fccd8 che ha introdotto il gate qui).

Il valore però non arriva: nel workflow_call di act_runner (v1.0.6) i valori with: del chiamante non raggiungono il contesto inputs in posizione if:, quindi !inputs.owns-auth-roles resta vero e lo step gira comunque. Non era emerso subito perché la deroga è nata insieme al gate e il tag v1 è stato spostato su 67fccd8 solo dopo: i run 137–141 usavano ancora una v1 senza lo step.

Il resto del workflow condiviso non se n'era accorto perché ogni altro uso di inputs è scritto con un fallback (inputs.node-version || '24.16.0', inputs.working-directory || '.'), che maschera il valore assente restituendo il default.

Correzione

Togliere la deroga dal campo if: e leggerla dentro lo script come variabile d'ambiente, con il nome del repository come rete di sicurezza:

        env:
          OWNS_AUTH_ROLES: ${{ inputs.owns-auth-roles }}
        run: |
          repo="${GITHUB_REPOSITORY:-}"
          if [ "${OWNS_AUTH_ROLES:-}" = "true" ] || [ "${repo##*/}" = "node-user-profiling" ]; then
            echo "Repository proprietario di auth.ruoli: controllo non applicabile."
            exit 0
          fi

Le due condizioni dicono la stessa cosa — una dichiarata dal chiamante, una constatata dal runner — così la deroga regge anche se inputs non dovesse arrivare nemmeno in env:.

Verificato in locale sui tre casi: deroga via input (esce 0), deroga via nome repository con input vuoto (esce 0), repo terzo con le stesse migrazioni (esce 1, il gate continua a mordere).

Dopo il merge va spostato il tag v1 sul nuovo commit, altrimenti la flotta continua a prendere la versione difettosa.

## Sintomo `node-user-profiling` ha la CI rossa da tre push consecutivi (run [26374](https://gitea.pzetatouch.it/PZeta_Touch/node-user-profiling/actions/runs/26374), [27457](https://gitea.pzetatouch.it/PZeta_Touch/node-user-profiling/actions/runs/27457), [27540](https://gitea.pzetatouch.it/PZeta_Touch/node-user-profiling/actions/runs/27540)). Fallisce sempre lo stesso step di `quality-gates.yml@v1`: ``` ::error::Questo repository dichiara ruoli in auth.ruoli, che appartiene a node-user-profiling. migrations/10_seed_auth.sql:9:INSERT INTO auth.ruoli ... migrations/11_seed_cliente_role.sql:14:INSERT INTO auth.ruoli ... migrations/12_seed_servizioesterno_role.sql:15:INSERT INTO auth.ruoli ... migrations/13_seed_ruoli_funzionali.sql:38:INSERT INTO auth.ruoli ... migrations/15_seed_automazioneflussi_role.sql:29:INSERT INTO auth.ruoli ... migrations/22_ruolo_notespese_write.sql:37:INSERT INTO auth.ruoli ... ``` Il gate sta bloccando **il repository proprietario dello schema**, cioè l'unico a cui quei sei `INSERT` sono legittimamente concessi. Tutti gli step successivi (`npm ci`, lint, typecheck, format, build, test) risultano `skipped`: da tre push non si sa più niente della qualità del codice di quel microservizio. ## Causa Lo step nasce con la propria deroga: ```yaml - name: Nessun ruolo dichiarato fuori da node-user-profiling if: ${{ !inputs.owns-auth-roles }} ``` e `node-user-profiling/.gitea/workflows/ci.yml` passa correttamente `owns-auth-roles: true` dal commit `4ec9706` (28/08, undici secondi prima del commit `67fccd8` che ha introdotto il gate qui). Il valore però non arriva: nel `workflow_call` di act_runner (v1.0.6) i valori `with:` del chiamante non raggiungono il contesto `inputs` in posizione `if:`, quindi `!inputs.owns-auth-roles` resta vero e lo step gira comunque. Non era emerso subito perché la deroga è nata insieme al gate e il tag `v1` è stato spostato su `67fccd8` solo dopo: i run 137–141 usavano ancora una `v1` senza lo step. Il resto del workflow condiviso non se n'era accorto perché ogni altro uso di `inputs` è scritto con un fallback (`inputs.node-version || '24.16.0'`, `inputs.working-directory || '.'`), che maschera il valore assente restituendo il default. ## Correzione Togliere la deroga dal campo `if:` e leggerla dentro lo script come variabile d'ambiente, con il nome del repository come rete di sicurezza: ```yaml env: OWNS_AUTH_ROLES: ${{ inputs.owns-auth-roles }} run: | repo="${GITHUB_REPOSITORY:-}" if [ "${OWNS_AUTH_ROLES:-}" = "true" ] || [ "${repo##*/}" = "node-user-profiling" ]; then echo "Repository proprietario di auth.ruoli: controllo non applicabile." exit 0 fi ``` Le due condizioni dicono la stessa cosa — una dichiarata dal chiamante, una constatata dal runner — così la deroga regge anche se `inputs` non dovesse arrivare nemmeno in `env:`. Verificato in locale sui tre casi: deroga via input (esce 0), deroga via nome repository con input vuoto (esce 0), repo terzo con le stesse migrazioni (esce 1, il gate continua a mordere). Dopo il merge va spostato il tag `v1` sul nuovo commit, altrimenti la flotta continua a prendere la versione difettosa.

LucaZanni referenced this issue from a commit

2026-09-07 19:31:13 +00:00

🔧 fix(ci): la deroga al gate dei ruoli arriva allo step che deve saltare

LucaZanni added spent time 1 hour 30 minutes

2026-09-07 19:31:13 +00:00

LucaZanni closed this issue

2026-09-07 19:31:13 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Total Time Spent: 1 hour 30 minutes

LucaZanni

1 hour 30 minutes

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: devops/shared-actions#8