Workflows

GitHub Management

Pull Request Labeler

Der Workflow "Pull Request Labeler" (.github/workflows/pr_labeler.yml) nutzt die GitHub Action Labeler. Der Workflow labled neue Pull Requests automatisch basierend auf den geänderten Dateien mit apps/ und packages/ Labels. Damit dieses Labeling korrekt funktioniert müssen die einzelnen Labels in der Konfigurationsdatei .github/labeler.yml zu den zugehörigen Dateipfaden zugeordnet werden.

# This file is enabling the Labeler Action to run. Labeler is configured in .github/labeler.yml

name: "Pull Request Labeler"
on:
  - pull_request_target

jobs:
  labeler:
    permissions:
      contents: read
      pull-requests: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v5

# This file serves as configuration file for the labeler Workflow (.github/workflows/pr_labeler.yml)

# Labels for Github Health Files

github-management:
  - changed-files:
      - any-glob-to-any-file: ".github/**"

# Labels for apps/* changes

apps/docs:
  - changed-files:
      - any-glob-to-any-file: apps/docs/**

apps/northware-cockpit:
  - changed-files:
      - any-glob-to-any-file: apps/northware-cockpit/**

# Labels for pakages/* changes

packages/auth:
  - changed-files:
      - any-glob-to-any-file: packages/auth/**

packages/database and api:
  - changed-files:
      - any-glob-to-any-file: packages/database/**

...

Workflows des Northware New Projekts

Das Northware New Projekt nutzt einige Workflows, die die Arbeit mit dem Projket teilweise automatisieren und unterstützen. Die Workflows sind nicht mit klassischen GitHub Actions sondern über das integrierte Workflow-Modul definiert.

Mehr zu Projekt-Workflows

Verwendete Projekt-Workflows

• Auto-add to project: Issues und Pull Requests aus dem ncs-northware/northware Repository werden automatisch zu dem Northare New Projekt hinzugefügt.
• Item added to project: Wenn ein Issue oder Pull Request zu dem Projekt hinzugefügt wird, wird dem Eintrag der Status Triage zugeordnet.
• Item reopened: Wenn ein Issue oder Pull Request wieder geöffnet wird, wird dem Eintrag der Status In Progress zugeordnet.
• Pull Request merged: Wenn ein Pull Request gemerged wurde, wird ihm der Status Done zugeordnet.
• Item closed: Wenn ein Issue oder Pull Request geschlossen wird, wird dem Eintrag der Status Done zugeordnet.

CI/CD

Turborepo CI

Der Workflow Turborepo CI (.github/workflows/turborepo-ci.yml) wird immer dann ausgelöst, wenn Code auf den main Branch gepusht wird oder ein neuer Pull Request eröffnet oder aktualisiert wird.

• Der Workflow nutzt den vorliegenden Code und installiert das Projekt in einer Node.js Umgebung mit pnpm.
• Mit pnpm build --affected werden die von der Änderung betroffenen Code-Teile gebaut.
• Mit pnpm lint:ci werden die von der Änderung betroffenen Code-Teile mit Biome überprüft.

Sollte es während dieses Workflows zu Problemen kommen, wird der Workflow abgebrochen.

autofix.ci

Der Workflow autofix.ci (.github/workflows/autofix.yml) wird immer dann ausgeführt, wenn ein neuer Pull Request hinzugefügt oder geändert wurde.

Innerhalb des Workflows wird das Projekt vollständig gebaut, der vorhandene Code wird mit pnpm format:root formatiert. Wenn durch den Durchlauf des Workflows Änderungen am Code vorgenommen wurden, werden diese Code Fixes auf den vorhandenen Pull Request commitet.

Dieser Commit unterbricht nun alle laufenden Workflows. Diese Workflows scheitern. Anschließend starten alle vorgesehenen Workflows wieder von neuem.

Changesets Auto Release

Der Workflow Changesets Auto Release (.github/workflows/changesets-release.yml) wird ausgeführt, wenn Code auf den main Branch gepusht wird.

Der Workflow nutzt changesets/action, um einen Pull Request mit dem Titel chore(release): New Package Versions zu erstellen. Wird dieser Pull Request in main gemerged, werden alle Packages und Apps entsprechend der im Repository enthaltenen Changesets versioniert und die CHANGELOG.md wird entsprechend der Changesets aktualisiert. Alle vorhandenen Changesets werden gelöscht. Weitere Infos zur Release Strategie

Exisitiert bereits ein durch Changesets erstellter Pull Request, wird dieser bei jedem push auf den main Branch aktualisiert. Enthält der gepushte Code ein neues oder geändertes Changeset, wird dieses in das CHANGELOG aufgenommen. Enthält der gepushte Code keine Veränderungen an Changesets, wird der Branch lediglich auf den Stand des main Branch gebracht.

Typescript Syntax Checks

Der Workflow Typescript Syntax Checks (.github/workflows/tsc-check) wird bei jedem neu eröffneten oder aktualisierten Pull Request und bei Pushes auf den main Branch ausgeführt. Das Projekt wird mit den Commands pnpm tsc-check:root (für Dateien im Root-Verzeichnis) und pnpm turbo tsc-check (für die einzelnen Apps und Packages) auf Typescript-Fehler untersucht. Die beschriebenen Commands führen dazu den Command tsc --noEmit aus. Werden Fehler im Typescript-Code festgestellt, scheitert der Durchlauf des Workflows. Die Fehler sollten behoben werden, bevor der Pull Request gemerged wird.

Renovate Bot

Mit dem Renovate Bot werden die Dependencies im GitHub Repository aktuell gehalten. Renovate prüft samstags und sonntags, ob es Dependencies (in PNPM-Packages und GitHub Actions) mit neuen Versionen gibt. Findet Renovate eine neue Version, erstellt der Bot einen Pull Request, alle betroffenen Dateien (z.B. pnpm-lock.yaml, package.json und Workflow-Dateien) aktualisiert.

Im Repository sind der "Dependency graph" und die "Dependabot alerts" aktivert. So wird das Repository auf Sicherheitsrisiken geprüft und darüber benachrichtigt. Renovate greift auf diese Daten zu und löst die Risiken ggf. durch ein Update der betroffenen Dependency.

Konfigurationen