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.
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.
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
Regel | Wert | Beschreibung |
---|---|---|
extends | Config-Presets, die genutzt werden sollen | |
semanticCommits | enabled | |
labels | dependencies | Vergebe das Label dependencies an alle Pull Requests, die von Renovate eröffnet werden. |
reviewers | onissen | Fordere für jeden Pull Request ein Review von onissen an. |
rangeStrategy | bump | Aktualisiere 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,6 | Renovate 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. |
timezone | Europe/Amsterdam | Zeitzone in der der schedule ausgeführt werden soll. |
vulnerabilityAlerts | Konfiguration, 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.labels | security , dependencies | |
vulnerabilityAlerts.reviewers | onissen | |
dependencyDashboardTitle | [Renovate]: Dependency Dashboard | Titel des Issues für das Dependency Dashboard |
dependencyDashboardLabels | ”dependencies”, “github-management” | Labels, die auf den Dependency Dashboard Issue angewendet werden. |
packageRules | Regeln, die nur auf bestimmte Packages angewendet werden. |