Zum Hauptinhalt springen

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.

.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 Repo-Root (Turborepo Administration)

turborepo:
  - changed-files:
      - any-glob-to-any-file: "*"

# 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:
  - 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 --affected werden Lint-Tests des betroffenen Codes ausgeführt.

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

Local CI

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

Dependabot​

Dependabot wird verwendet, um die im gesamten Repository verwendeten Dependencies aktuell zu halten. Wenn Dependabot Dependencies findet, bei denen es eine neue Version gibt, wird das Update umgesetzt und als Pull Request bereitgestellt.

In diesem Repository ist Dependabot so konfiguriert, das wöchentlich freitags um 14:00 Uhr der Durchlauf startet. onissen wird dann als Reviewer hinzugefügt, damit ich auf den PR aufmerksam werde.

Mit open-pull-request-limit: 0 und versioning-strategy: increase wird gewährleistet, das Dependabot im Monorepo-Umfeld funktioniert.

Auch für GitHub Actions ist Dependabot konfiguriert, es wird also auch die Workflows auf neue Versionen prüfen.