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.

.github/workflows/pr_labeler.yml

# 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

.github/labeler.yml

# 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.

Der Turborepo CI-Workflow durchläuft bei jedem Pull Request und bei jedem Merge die Schritte pnpm turbo build --affected und pnpm turbo run lint:ci. Damit diese Schritte nicht immer erst gemacht werden, wenn alles fertig ist lässt sich dieser Ablauf mit pnpm localci auch lokal abbilden, damit Fehler schon vor dem CI-Durchlauf auffallen.

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.

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

RegelWertBeschreibung
extendsConfig-Presets, die genutzt werden sollen
semanticCommitsenabled
labelsdependenciesVergebe das Label dependencies an alle Pull Requests, die von Renovate eröffnet werden.
reviewersonissenFordere für jeden Pull Request ein Review von onissen an.
rangeStrategybumpAktualisiere immer den Eintrag in der package.json, wenn eine neue Version verfügbar ist. Die pnpm-lock.yaml wird ebenfalls immer aktualisiert. Beispiel: ^1.0.0 wird zu ^1.1.0, ^3.4.0 wird zu ^3.4.1
schedule* * * * 0,6Renovate führt Änderungen immer samstags und sonntags zu einer beliebigen Zeit durch. Außerhalb dieses Zeitplans wartet Renovate bis der Zeitplan wieder erreicht ist und führt erst dann die Änderung durch.
timezoneEurope/AmsterdamZeitzone in der der schedule ausgeführt werden soll.
vulnerabilityAlertsKonfiguration, wenn mit dem Pull Request eine Security Vulnerability behoben wird. Renovate liest die Vulnerability Alerts von Dependabot und löst diese wenn möglich. PRs die als vulnerabilityAlerts erstellt werden. Halten sich nicht an den schedule, sie werden also so schnell wie möglich eröffnet, damit der Fix möglichst schnell erfolgen kann.
vulnerabilityAlerts.labelssecurity, dependencies
vulnerabilityAlerts.reviewersonissen
dependencyDashboardTitle[Renovate]: Dependency DashboardTitel des Issues für das Dependency Dashboard
dependencyDashboardLabels”dependencies”, “github-management”Labels, die auf den Dependency Dashboard Issue angewendet werden.
packageRulesRegeln, die nur auf bestimmte Packages angewendet werden.