Workflows teilen statt kopieren – und nie zweimal dasselbe gleichzeitig laufen lassen.
on:
workflow_call: # macht ihn aufrufbar
inputs:
python:
type: string
default: "3.12"
secrets:
token: { required: false }
jobs:
test:
runs-on: docker
container: python:${{ inputs.python }}-slim
steps:
- uses: actions/checkout@v4
- run: pip install -r requirements.txt && pytest -qjobs:
call-test:
uses: ./.forgejo/workflows/reusable-test.yaml
with:
python: "3.12"
secrets: inherit # oder gezielt einzelne weitergebenruns-on/steps – nur
uses: auf den Workflow, plus with: und secrets:. Den Runner
bestimmen die Jobs im aufgerufenen Workflow. So lassen sich auch Workflows aus anderen
(öffentlichen) Repos einbinden: owner/repo/.forgejo/workflows/x.yaml@ref.
concurrency:
group: deploy-${{ forgejo.ref }}
cancel-in-progress: true
Alle Läufe mit derselben group bilden eine Reihe. cancel-in-progress: true
bricht einen noch laufenden Lauf ab, sobald ein neuer derselben Gruppe startet – ideal, damit nicht
zwei Deploys desselben Branches kollidieren.
include: / CI-Components
Parameter via inputs: (spec)
resource_group / interruptible
workflow_call + uses:
Parameter via inputs/secrets
concurrency + cancel-in-progress
Frage: Ein aufrufender Job hat uses:, aber kein
runs-on. Ist das ein Fehler?
Nein – beim Aufruf einer reusable workflow entfällt runs-on. Den
Runner wählen die Jobs im aufgerufenen Workflow.
Aufgabe: Sorge dafür, dass pro Branch immer nur ein CI-Lauf aktiv ist und ältere abgebrochen werden.
concurrency:
group: ci-${{ forgejo.ref }}
cancel-in-progress: trueWas macht einen Workflow aufrufbar?
Nur mit on: workflow_call kann ein anderer Workflow ihn via uses: einbinden.
Wozu dient cancel-in-progress: true?
Ein neuer Lauf derselben group beendet den noch laufenden – verhindert Kollisionen.
concurrency.group? Frag im Chat – wir schneiden den Baustein passend.