Zmienne GitLab CI z Crunu, powiązane przez id_tokens

Co Crunu robi w GitLab CI

Zadanie uruchamia twoje polecenie przez crunu run. Agent crunu loguje się tokenem usługowym, sprawdza podpisy, odszyfrowuje zmienne w pamięci i uruchamia z nimi polecenie. Nic nie jest zapisywane na dysku.

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

Token dostaje tylko środowiska, do których dasz mu dostęp. Z powiązaniem CI (OIDC) GitLab wystawia zadaniu token, którego audience to twój serwer Crunu, a token Crunu działa tylko razem z nim, dla ustawionych przez ciebie ścieżki projektu, refu i środowiska. crunu sam odczytuje token GitLaba ze zmiennej CRUNU_ID_TOKEN.

Konfiguracja

1. W Crunu otwórz Service tokens i wybierz New service token. Przyznaj środowiska, których potrzebuje zadanie. Token jest pokazywany tylko raz.
2. W GitLabie otwórz Settings → CI/CD → Variables i dodaj CRUNU_TOKEN jako zmienną maskowaną i chronioną.
3. Dodaj CRUNU_SERVER, CRUNU_VERSION, CRUNU_INSTALL_URL, CRUNU_INSTALL_SHA256 i CRUNU_BINARY_SHA256 z wartościami z bloku CI setup na stronie tokenu. W chmurze CRUNU_SERVER to https://app.crunu.com.
4. Opcjonalnie dodaj powiązanie CI (OIDC) na stronie tokenu. Wybierz dostawcę GitLab i ustaw project_path, ref, ref_type oraz, dla tokenu production, environment.

Przykładowe zadanie

Obraz zadania potrzebuje sh oraz curl lub wget. Mają je obrazy node, python i alpine.

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

Dla tokenu production powiązanie CI (OIDC) może wymagać:

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

Szablony zadań .crunu

Kroki instalacji są też dostępne jako plik szablonu z dwoma ukrytymi zadaniami. Twoje zadania dziedziczą je przez extends:

• .crunu instaluje przypiętą wersję crunu w before_script, sprawdza SHA-256 instalatora i pliku binarnego i wypisuje crunu version;
• .crunu-oidc robi to samo i dodaje id_tokens dla tokenów z powiązaniem CI.

Trzymaj kopię szablonu w swoim repozytorium, żeby zmiany w nim przechodziły przegląd razem z twoim kodem. Jeśli zamiast tego dołączasz go z innego projektu GitLab, przypnij ref do commita, a nie do gałęzi.

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

Własny before_script zadania zastępuje ten z szablonu, bo extends nie scala list poleceń. Dodaj kroki szablonu z powrotem jawnie:

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

Co jest sprawdzane

• Suma kontrolna instalatora jest porównywana przed jego uruchomieniem. Przy niezgodności zadanie się zatrzymuje, a crunu nie zostaje zainstalowany.
• Instalator sprawdza sumę kontrolną pliku binarnego i uruchamia go raz, zanim umieści go na miejscu.
• Nieprawidłowe wartości, takie jak brakująca suma kontrolna albo adres, który nie zaczyna się od https://, są odrzucane, zanim cokolwiek zostanie pobrane.

Runnery i sumy kontrolne

crunu działa na Linuksie i macOS, na amd64 i arm64. Nie ma wersji na Windows. Suma kontrolna w bloku CI setup dotyczy Linuksa na amd64; dla runnerów arm64 ustaw sumy kontrolne dla poszczególnych platform z pliku manifest.json wydania.

Unieważnianie tokenu

Otwórz token w Crunu i wybierz Revoke. Jego następne logowanie zostanie odrzucone, a zadanie, które już trwa, kończy się z tym, co otrzymało. Jeśli token mógł wyciec, wymień też klucze środowisk, do których miał dostęp, i wygeneruj ponownie zapisane w nich wartości u ich dostawców.

Zobacz także

• CI/CD w Crunu
• GitLab CI w dokumentacji
• Powiązanie tokenu przez OIDC
• Tokeny usługowe