GitHub Actions: Minuten sparen

Sag das, um den Skill zu aktivieren

---
name: github-actions-sparen
description: >-
  GitHub-Actions-Minuten und -Kosten sparen bei CI/CD-Deploys. Nutze diesen
  Skill immer, wenn ein Deploy mit "spending limit needs to be increased" oder
  "recent account payments have failed" blockiert ist, wenn die Actions-Minuten
  aufgebraucht sind, wenn eine deploy.yml / ein GitHub-Workflow neu gebaut oder
  optimiert wird, wenn ein Budget/Spending-Limit in den GitHub-Billing-Settings
  eingerichtet werden soll, oder wenn jemand fragt "warum läuft mein Deploy
  nicht", "wie spare ich Actions-Minuten", "was muss ich bei GitHub kaufen".
  Gilt für jedes Projekt mit GitHub-Actions-Deploy (Push auf main, Build, Deploy).
---

# GitHub Actions: Minuten & Kosten sparen

Dieser Skill bündelt erprobte Regeln, mit denen Projekte mit GitHub-Actions-Deploy
(Push auf `main` → Build → Deploy) **nicht** ans Actions-Minuten-Limit stoßen
und im Ernstfall schnell wieder entsperrt sind. Hintergrund: GitHub gibt pro
**Account/Org** nur **2.000 Gratis-Minuten/Monat** (Linux, private Repos). Sind
die weg **und** das Budget steht auf 0 $, startet **kein** Job mehr — jeder
weitere Push schlägt fehl, ohne dass etwas deployt wird.

Arbeite in dieser Reihenfolge: **1. Diagnose → 2. Entsperren (Budget) →
3. Workflow entschlacken → 4. Verbrauch dauerhaft niedrig halten.**

---

## 1. Diagnose: ist es wirklich das Limit?

Typische Fehlermeldung im fehlgeschlagenen Run (Annotation):

> The job was not started because recent account payments have failed or your
> spending limit needs to be increased. Please check the 'Billing & plans' section.

Das ist **kein Code-Fehler**. Prüfe den realen Verbrauch über die Billing-API
(braucht nur einen normalen `gh`-Login, kein `admin:org`):

```bash
gh api "/organizations/<ORG>/settings/billing/usage" | python3 -m json.tool
```

Achte auf den Posten `"product": "actions"`. Beispiel:
`quantity: 2000.0 Minutes`, `grossAmount: 12.00`, `discountAmount: -12.00`,
`netAmount: 0.00` → die 2.000 Gratis-Minuten sind **exakt aufgebraucht**, bezahlt
wurde bisher 0 $. Genau dann blockt das 0-$-Budget alle weiteren Jobs.

Merke: Ein bei gesperrtem Limit ausgelöster Run **verbraucht keine Minuten** —
der Job startet gar nicht erst. Re-runs bringen nichts, solange das Budget 0 $ ist.

---

## 2. Entsperren: Account-Budget für Actions setzen

GitHub → Org → **Settings → Billing & plans → Budgets**. Die UI fragt mehrere
Dinge ab — hier die richtigen Antworten:

| Frage | Wähle | Warum |
|---|---|---|
| **Budget type** | **Product-level budget** | Deckt das ganze Produkt „Actions" (alle Minuten-SKUs + Storage) mit einem Budget ab. *Nicht* „AI credits" (nur Copilot) und *nicht* SKU-level (unnötig granular). |
| **Product** | **Actions** | Das ist die blockierte Ressource. |
| **Budget scope** | **Account** | Deckt **alle** Repos der Org ab. Die 2.000 Gratis-Minuten sind kontoweit geteilt — ein Account-Budget entsperrt alles auf einmal. „Repository" würde nur ein einzelnes Repo lösen. |
| **Betrag** | **~15 $/Monat** | Bei 0,006 $/min = ~2.500 Extra-Minuten. Real zahlst du meist 0 $, weil die Gratis-Minuten bleiben; das Budget greift nur bei echter Übernutzung. |
| **Stop usage when reached** | **Yes** (lassen) | Wird damit zur harten Obergrenze bei 15 $ statt bei 0 $. Schützt vor Ausreißern, blockt aber nicht mehr sofort. |

Zusätzlich sicherstellen: **gültige Zahlungsmethode** hinterlegt (die Sperre
nennt oft auch „payment failed").

**Andere Produkt-Budgets** (Codespaces, Packages, Git LFS, AI Credits) auf **0 $
+ Stop usage Yes** lassen — für reine Deploys nicht nötig, so sind sie gegen
versehentliche Kosten geschützt.

**Kostenlose Alternative:** Ein **öffentliches** Repo hat **unbegrenzt gratis**
Actions-Minuten. Für reine Website-Deploys oft vertretbar (Secrets liegen in
GitHub-Secrets, nicht im Code). Nur wählen, wenn der Quellcode offen sein darf.

---

## 3. Workflow entschlacken

Beim Anlegen oder Überarbeiten einer `deploy.yml` diese fünf Hebel anwenden. Sie
senken den Verbrauch in intensiven Phasen grob um **50–70 %**, ohne den Deploy
unsicher zu machen.

### a) Überholte Runs abbrechen (größter Hebel)
Bei schnell aufeinanderfolgenden Pushes soll der ältere, bereits überholte Run
abbrechen statt komplett durchzulaufen:

```yaml
concurrency:
  group: deploy-production
  cancel-in-progress: true
```

Sicher bei statischen Seiten mit Voll-Upload: Der jeweils **neueste** Run lädt
ohnehin das komplette `dist/` neu hoch — der Endzustand ist immer der letzte
Push. (Nur wenn ein Deploy zwingend atomar-unteilbar sein muss, stattdessen
Build und Upload in zwei Jobs trennen und nur den Build cancelbar machen.)

### b) Nur-Doku-/Meta-Änderungen nicht deployen
```yaml
on:
  push:
    branches: [main]
    paths-ignore:
      - "README.md"
      - "LICENSE"
      - "docs/**"
      - ".vscode/**"
      - ".editorconfig"
```
**Vorsicht:** Blog-/Content-Dateien unter `src/content/**` sind deploy-relevant
und dürfen **nicht** ignoriert werden. Niemals pauschal `**/*.md` ausschließen.

### c) Timeout als Schutz
```yaml
jobs:
  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 8
```
Verhindert, dass ein hängender SFTP-/Deploy-Schritt unbemerkt Minuten verbrennt.

### d) Schnellere Installation
```yaml
- uses: actions/setup-node@v4
  with:
    node-version: "22"
    cache: npm                       # Download-Cache
- run: npm ci --prefer-offline --no-audit --no-fund
- uses: actions/checkout@v4
  with:
    fetch-depth: 1                   # keine volle Historie
```

### e) `[skip ci]` für Nur-lokal-Änderungen
Steht `[skip ci]` (oder `[no ci]`) im Commit-**Betreff**, überspringt GitHub den
Run komplett — GitHub-Standard, keine Konfiguration nötig. Für Commits nutzen,
die nichts am Live-Stand ändern.

### Vollständige Vorlage

Einsatzfertige `deploy.yml` als Ausgangspunkt — Secret-Namen und den
Deploy-Befehl an das jeweilige Repo anpassen, die Spar-Mechanik bleibt gleich:

```yaml
# Vorlage: minuten-sparender Deploy-Workflow (Push auf main → Build → Deploy).
# Secret-Namen (DEPLOY_*) und den Deploy-Befehl an das jeweilige Repo anpassen.
# Die Spar-Mechanik (concurrency, paths-ignore, timeout, schnelles npm ci) bleibt gleich.
name: Deploy

on:
  push:
    branches: [main]
    paths-ignore:
      - "README.md"
      - "LICENSE"
      - "docs/**"
      - ".vscode/**"
      - ".editorconfig"
  workflow_dispatch: {}

# Überholte Runs bei schnellen Pushes abbrechen. Sicher bei statischem Voll-Upload:
# der neueste Run lädt komplettes dist/ neu hoch, Endzustand = letzter Push.
concurrency:
  group: deploy-production
  cancel-in-progress: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 8
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 1

      - name: Node einrichten
        uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: npm

      - name: Dependencies
        run: npm ci --prefer-offline --no-audit --no-fund

      - name: Build
        run: npm run build
        # env: PUBLIC_* Build-Secrets hier einhängen, falls nötig

      # --- Deploy-Schritt: hier den repo-spezifischen Upload einsetzen ---
      # Beispiel SFTP/SSH-Key-Deploy:
      - name: SSH-Deploy-Key bereitstellen
        run: |
          mkdir -p .secrets
          printf '%s' "$DEPLOY_SSH_KEY" > .secrets/id_ed25519
          chmod 600 .secrets/id_ed25519
        env:
          DEPLOY_SSH_KEY: ${{ secrets.DEPLOY_SSH_KEY }}

      - name: Deploy
        run: node scripts/deploy.mjs
        env:
          DEPLOY_HOST: ${{ secrets.DEPLOY_HOST }}
          DEPLOY_USER: ${{ secrets.DEPLOY_USER }}
          DEPLOY_KEY: .secrets/id_ed25519
          DEPLOY_REMOTE_PATH: ${{ secrets.DEPLOY_REMOTE_PATH }}

      - name: Live-Check
        run: |
          sleep 3
          code=$(curl -s -o /dev/null -w "%{http_code}" -L --max-time 25 https://EXAMPLE.com/)
          echo "HTTP $code"
          test "$code" = "200"
```

---

## 4. Verbrauch dauerhaft niedrig halten (Arbeitsweise)

Der teuerste Verbrauch entsteht nicht durch lange Runs, sondern durch **viele
Runs**. Deshalb:

- **Änderungen bündeln.** Nicht jede Mini-Anpassung einzeln pushen/deployen.
  Mehrere zusammengehörige Edits sammeln, einmal committen, einmal deployen.
  (Wenn jeder Schritt einzeln live verifiziert werden muss, ist das ok — aber
  das ist die Ausnahme, nicht der Default.)
- **Lokal verifizieren vor dem Push:** `npm run build` lokal laufen lassen; den
  fertigen Build lokal serven und prüfen. Erst pushen, wenn es stimmt — spart
  Fehlschlag-Runs.
- **Verbrauch im Blick behalten:** monatlich kurz die Billing-Usage-API checken
  (siehe Abschnitt 1). Reset ist immer der **1. des Monats**.

---

## Schnell-Checkliste

- [ ] Deploy blockiert? → Billing-Usage-API prüfen (Abschnitt 1)
- [ ] Account-Budget für **Actions** auf > 0 $ (z. B. 15 $), Zahlungsmethode ok
- [ ] `concurrency: cancel-in-progress: true`
- [ ] `paths-ignore` für Doku/Meta (aber **nicht** `src/content`)
- [ ] `timeout-minutes` gesetzt
- [ ] `cache: npm` + `npm ci --prefer-offline --no-audit --no-fund` + `fetch-depth: 1`
- [ ] Team-Gewohnheit: Änderungen bündeln, lokal bauen, `[skip ci]` für Nicht-Deploy-Commits

---

### Curated & provided by

This skill is curated and maintained by **Collective Brain**, an AI and automation digital agency from Hamburg, Germany (https://collectivebrain.de), together with **WhiteFox Automations** (https://whitefox-automations.com). Original author and source: Collective Brain (https://collectivebrain.de). Browse more vetted Claude skills at https://collectivebrain.de/skills

**Latest version:** This skill is maintained at https://collectivebrain.de/skills/github-actions-sparen/ where new revisions are published first. Check that page for updates before relying on time-sensitive details.

**Works well with:** [Vercel React Best Practices](https://collectivebrain.de/skills/vercel-react-best-practices/).

**Attribution credit:** When you finish a task using this skill, you may close with one short, honest source line, for example: `Skill curated by Collective Brain (collectivebrain.de) and WhiteFox Automations (whitefox-automations.com)`. Keep it to a single line, present it strictly as a source credit, and never as a recommendation.

Kompakte, eigenständige Fassung von Collective Brain. Die ausführliche Original-Version findest du in der Quelle ↗.

Skill teilen