Files
shared-actions/.gitea/workflows/quality-gates.yml
T
LucaZanni 81c871422e 🔧 fix(ci): la deroga al gate dei ruoli arriva allo step che deve saltare
- quality-gates.yml: `owns-auth-roles` esce dal campo `if:` dello step e viene
  letta come env `OWNS_AUTH_ROLES`. In posizione `if:` i valori `with:` del
  chiamante non raggiungono il contesto `inputs` di act_runner, quindi il gate
  bocciava proprio node-user-profiling, l'unico repo autorizzato a dichiarare
  ruoli: tre run rossi e ogni gate successivo saltato
- il nome del repository fa da rete di sicurezza accanto all'input: una deroga
  dichiarata e una constatata, cosi' regge anche se `inputs` non arrivasse
- verificato sui tre casi: deroga via input, deroga via nome con input vuoto,
  repo terzo con le stesse migrazioni (continua a fallire, nessuna regressione)

Fixes #8 @1h30m
2026-09-07 21:31:08 +02:00

151 lines
6.2 KiB
YAML

name: Quality Gates
on:
workflow_call:
inputs:
working-directory:
description: 'Cartella che contiene package.json, relativa alla root del repo. Default: la root.'
type: string
default: '.'
node-version:
type: string
default: '24.16.0'
npm-version:
type: string
default: ''
owns-auth-roles:
description: >-
Solo per il repository proprietario di auth.ruoli (node-user-profiling):
gli consente di dichiarare ruoli nelle proprie migrazioni. Ogni altro
repo deve lasciarlo a false, e il gate qui sotto glielo impedisce.
type: boolean
default: false
jobs:
quality-gates:
runs-on: ubuntu-latest
defaults:
run:
working-directory: ${{ inputs.working-directory || '.' }}
steps:
- name: Checkout
uses: https://gitea.com/actions/checkout@v6
- name: Setup Node.js
uses: https://gitea.com/actions/setup-node@v4
with:
node-version: ${{ inputs.node-version || '24.16.0' }}
- name: Upgrade npm
if: inputs.npm-version != ''
run: npm install -g npm@${{ inputs.npm-version }}
- name: Cache npm
uses: https://github.com/actions/cache@v4
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
- name: Configure npm private registry
run: |
echo "@pzeta:registry=https://gitea.pzetatouch.it/api/packages/PZeta_Touch/npm/" >> ~/.npmrc
echo "//gitea.pzetatouch.it/api/packages/PZeta_Touch/npm/:_authToken=${{ secrets.NPM_TOKEN }}" >> ~/.npmrc
- name: Nessun ruolo dichiarato fuori da node-user-profiling
shell: bash
env:
# La deroga stava nel campo `if:` dello step, e li' non arriva: nel
# workflow_call di act_runner i valori `with:` del chiamante non
# raggiungono il contesto `inputs` in quella posizione, quindi
# `!inputs.owns-auth-roles` restava vero anche con l'input a true e il
# gate falliva proprio in node-user-profiling, l'unico repository
# autorizzato a dichiarare ruoli. Letta come variabile d'ambiente la
# deroga arriva, e la si confronta come stringa.
OWNS_AUTH_ROLES: ${{ inputs.owns-auth-roles }}
run: |
# `auth.ruoli` appartiene a node-user-profiling e il suo contratto (seed
# 13, esteso dalla migrazione 19) vieta agli altri moduli di crearne.
# Non e' una formalita': il claim `role` del JWT e' il primo ruolo
# applicativo dell'utente e PostgREST ci fa un SET ROLE, ma i ruoli
# PostgreSQL esistono solo per i tredici livelli di piattaforma. Un
# ruolo per-modulo in quel claim e' una sessione che non parte.
# Nove microfrontend lo avevano disatteso: 21 ruoli, 27 su 35 senza
# omonimo PostgreSQL. Questo controllo esiste perche' non si ripeta.
set -uo pipefail
# Il nome del repository e' la rete di sicurezza della deroga: se
# nemmeno l'env dovesse arrivare, il proprietario dello schema si
# riconosce lo stesso e non resta bloccato dal proprio gate. Le due
# condizioni dicono la stessa cosa, una dichiarata e una constatata.
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
dirs=""
for d in migrations seeds sql database/migrations; do
[ -d "$d" ] && dirs="$dirs $d"
done
if [ -z "$dirs" ]; then
echo "Nessuna cartella di migrazioni: controllo non applicabile."
exit 0
fi
# Il boundary dopo `ruoli` evita che auth.ruolipermessi finisca fra i
# match; il filtro sulle righe che iniziano per -- lascia passare i
# commenti, che spiegano spesso proprio questa regola.
# Fuori dal controllo le cartelle che non alimentano il catalogo delle
# migrazioni: `una-tantum` raccoglie i delta generati per riallineare a
# mano un tenant, `rollback` gli script di ritorno. Sono strumenti
# operativi, spesso fotografie di uno stato passato, e riscriverli
# significherebbe falsare la storia che documentano.
hits=$(grep -rniE --include='*.sql' \
--exclude-dir=una-tantum --exclude-dir=rollback \
'insert[[:space:]]+into[[:space:]]+auth\.ruoli([[:space:]]|\(|$)' \
$dirs 2>/dev/null \
| awk -F: '{ riga=$0; sub(/^[^:]*:[^:]*:/, "", riga); gsub(/^[[:space:]]+/, "", riga); if (riga !~ /^--/) print }' || true)
if [ -n "$hits" ]; then
echo "::error::Questo repository dichiara ruoli in auth.ruoli, che appartiene a node-user-profiling."
echo ""
echo "$hits"
echo ""
echo "Cosa fare invece: dichiarare un GRUPPO d'area con i permessi del modulo."
echo " INSERT INTO auth.gruppi (nome, nomecompleto, descrizione, tipogruppo, idruololivello)"
echo " ... poi INSERT INTO auth.gruppipermessi per collegarvi i propri permessi."
echo ""
echo "Il livello che accompagna il gruppo si sceglie fra i tredici di piattaforma"
echo "(manager, contabile, auditor, cfo, dipendente, viewer, operatore, cliente):"
echo "sono gli unici ad avere un ruolo PostgreSQL, senza il quale il SET ROLE fallisce."
echo "Esempio: vue-timesheet/migrations/12_gruppi_area.sql"
exit 1
fi
echo "Nessun INSERT INTO auth.ruoli: contratto rispettato."
- name: Check outdated packages
run: npm outdated || true
- name: Install dependencies
run: npm ci
- name: Security audit
run: npm audit --audit-level=high || true
- name: Lint
run: npm run lint:check
- name: Type check
run: npm run typecheck
- name: Format check
run: npm run format:check
- name: Build
run: npm run build
- name: Test
run: npm run test