Variabili GitLab CI da Crunu, legate con id_tokens

Cosa fa Crunu in GitLab CI

Un job esegue il tuo comando tramite crunu run. L’agente crunu accede con un token di servizio, controlla le firme, decifra le variabili in memoria e avvia il comando con quelle variabili. Nulla viene scritto su disco.

crunu run --env web-app/staging -- npm test

Il token riceve solo gli ambienti che concedi. Con un vincolo CI (OIDC), GitLab emette per il job un token con il tuo server Crunu come audience, e il token Crunu funziona solo insieme a quello, per il percorso di progetto, il ref e l’ambiente che imposti. crunu legge da solo il token GitLab da CRUNU_ID_TOKEN.

Configurazione

1. In Crunu, apri Service tokens e scegli New service token. Concedi gli ambienti di cui il job ha bisogno. Il token viene mostrato una sola volta.
2. In GitLab, apri Settings → CI/CD → Variables e aggiungi CRUNU_TOKEN come variabile mascherata e protetta.
3. Aggiungi CRUNU_SERVER, CRUNU_VERSION, CRUNU_INSTALL_URL, CRUNU_INSTALL_SHA256 e CRUNU_BINARY_SHA256 con i valori del blocco CI setup nella pagina del token. Nel cloud, CRUNU_SERVER è https://app.crunu.com.
4. Facoltativo: aggiungi un vincolo CI (OIDC) nella pagina del token. Scegli il provider GitLab e imposta project_path, ref, ref_type e, per un token di produzione, environment.

Job di esempio

L’immagine del job ha bisogno di sh e di curl o wget. Le immagini node, python e alpine li hanno.

test:
  image: node:24
  id_tokens:
    CRUNU_ID_TOKEN:
      aud: https://app.crunu.com   # your Crunu server; only if the token has a CI binding (OIDC)
  script:
    - curl -sSf "$CRUNU_INSTALL_URL" -o /tmp/crunu-install.sh
    - echo "$CRUNU_INSTALL_SHA256  /tmp/crunu-install.sh" | sha256sum -c -
    - sh /tmp/crunu-install.sh --version "$CRUNU_VERSION" --sha256 "$CRUNU_BINARY_SHA256" --user-install
    - crunu run --env web-app/staging -- npm test

Per un token di produzione, il vincolo CI (OIDC) potrebbe richiedere:

• project_path: kiteline/web-app
• ref: main
• ref_type: branch
• environment: production

I template di job .crunu

I passaggi di installazione sono disponibili anche come file di template con due job nascosti. I tuoi job li ereditano con extends:

• .crunu installa una versione fissata di crunu in before_script, controlla lo SHA-256 dell’installer e del binario e stampa crunu version;
• .crunu-oidc fa lo stesso e aggiunge id_tokens, per i token con un vincolo CI.

Tieni una copia del template nel tuo repository, così le sue modifiche vengono revisionate insieme al tuo codice. Se invece lo includi da un altro progetto GitLab, fissa ref a un commit, non a un branch.

include:
  - local: ci/crunu.gitlab-ci.yml

test:
  image: node:24
  extends: .crunu
  script:
    - crunu run --env web-app/staging -- npm test

deploy:
  image: node:24
  extends: .crunu-oidc        # the production token has an OIDC rule: project_path, ref, environment
  environment: production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  script:
    - crunu run --env web-app/production -- npm run deploy

Il before_script del job sostituisce quello del template, perché extends non unisce gli elenchi di comandi. Aggiungi di nuovo in modo esplicito i passaggi del template:

test:
  extends: .crunu
  before_script:
    - !reference [.crunu, before_script]
    - npm ci
  script:
    - crunu run --env web-app/staging -- npm test

Cosa viene controllato

• Il checksum dell’installer viene confrontato prima che venga eseguito. Se non corrisponde, il job si ferma e crunu non viene installato.
• L’installer controlla il checksum del binario e lo esegue una volta prima di metterlo al suo posto.
• I valori malformati, come un checksum mancante o un indirizzo che non è https://, vengono rifiutati prima di scaricare qualsiasi cosa.

Runner e checksum

crunu funziona su Linux e macOS, su amd64 e arm64. Non esiste una build per Windows. Il checksum nel blocco CI setup è per Linux amd64; per i runner arm64, imposta i checksum per piattaforma dal manifest.json della release.

Revoca

Apri il token in Crunu e scegli Revoke. Il suo accesso successivo viene rifiutato, e un job già in esecuzione termina con ciò che ha ricevuto. Se il token potrebbe essere trapelato, ruota anche le chiavi degli ambienti che gli erano stati concessi e riemetti presso i fornitori i valori che contengono.

Correlati

• CI/CD in Crunu
• GitLab CI nella documentazione
• Legare un token con OIDC
• Token di servizio