Informationen zur fortlaufenden Integration

Sie können benutzerdefinierte Continuous Integration (CI) und Continuous Deployment (CD)-Workflows direkt in Ihrem GitHub Repository mit GitHub Actionserstellen.

GitHub Actions ist verfügbar mit GitHub Free, GitHub Pro, GitHub Free für Organisationen, GitHub Team, GitHub Enterprise Cloud, und GitHub AE. GitHub Actions ist nicht verfügbar für private Repositorys, die im Besitz von Konten mit älteren Pro-Repository-Plänen sind. For more information, see "GitHub's products."

Informationen zur fortlaufenden Integration

Bei der Softwarepraktik der fortlaufenden Integration (CI) erfolgen häufige Code-Commits an ein gemeinsames Repository. Code-Commits in kurzen Abständen tragen dazu bei, Fehler frühzeitiger aufzudecken, und verringern die Codemenge, die ein Entwickler auf der Suche nach der Fehlerursache debuggen muss. Durch häufige Code-Aktualisierungen lassen sich zudem Änderungen von verschiedenen Mitgliedern eines Software-Entwicklungsteams leichter zusammenführen. Dies bedeutet einen erheblichen Vorteil für die Entwickler, die sich damit stärker auf das Schreiben des Codes konzentrieren können, statt Fehler debuggen oder Mergekonflikte beheben zu müssen.

Durch einen Code-Commit an das Repository können Sie den Code fortlaufend erstellen und testen, sodass gewährleistet ist, dass der Commit keine Fehler einbringt. Die Tests können beispielsweise Code-Linters (überprüfen Stilformatierungen), Sicherheitsprüfungen, Code-Abdeckung, Funktionstests und andere benutzerdefinierte Prüfungen umfassen.

Zum Erstellen und Testen des Codes ist ein Server erforderlich. Sie können Aktualisierungen lokal erstellen und testen, bevor Sie den Code per Push an ein Repository senden, oder auch einen CI-Server heranziehen, der neue Code-Commits in einem Repository prüft.

Informationen zur kontinuierlichen Integration mit GitHub Actions

CI using GitHub Actions offers workflows that can build the code in your repository and run your tests. Workflows können auf GitHubgehosteten virtuellen Maschinen oder auf Computern ausgeführt werden, die Sie selbst hosten. For more information, see "Virtual environments for GitHub-hosted runners" and "About self-hosted runners."

Sie können Ihren CI-Workflow so konfigurieren, dass er ausgeführt wird, wenn ein GitHub Ereignis auftritt (z. B. wenn neuer Code an Ihr Repository übertragen wird), nach einem festgelegten Zeitplan oder wenn ein externes Ereignis mithilfe des Repository-Dispatch-Webhooks auftritt.

GitHub führt die CI-Tests aus und stellt die Ergebnisse jedes Tests in der Pullanforderung bereit, sodass Sie sehen können, ob die Änderung in Ihrem Zweig einen Fehler verursacht. Sobald alle CI-Tests in einem Workflow bestanden wurden, können die per Push übermittelten Änderungen von einem Teammitglied geprüft oder zusammengeführt werden. Wenn ein Test nicht bestanden wird, liegt die Ursache eventuell in einer Ihrer Änderungen.

Wenn Sie CI in Ihrem Repository einrichten, analysiert GitHub den Code in Ihrem Repository und empfiehlt CI-Workflows basierend auf der Sprache und dem Framework in Ihrem Repository. Wenn Sie beispielsweise Node.jsverwenden, schlägt GitHub eine Vorlagendatei vor, die Ihre Node.js-Pakete installiert und Ihre Tests ausführt. Sie können die von GitHubvorgeschlagene CI-Workflowvorlage verwenden, die vorgeschlagene Vorlage anpassen oder eine eigene benutzerdefinierte Workflowdatei zum Ausführen der CI-Tests erstellen.

Screenshot mit vorgeschlagenen Vorlagen für die fortlaufende Integration

Sie können nicht nur ci-Workflows für Ihr Projekt einrichten, sondern auch GitHub Actions verwenden, um Workflows über den gesamten Softwareentwicklungslebenszyklus hinweg zu erstellen. Sie können Ihr Projekt beispielsweise mithilfe von Aktionen bereitstellen, packen oder veröffentlichen. Weitere Informationen finden Sie unter "über GitHub Actions".

Eine Definition von gebräuchliche Begriffe finden Sie unter "Kernkonzepte für GitHub Actions".

Unterstützte Sprachen

GitHub bietet CI-Workflowvorlagen für eine Vielzahl von Sprachen und Frameworks.

Browse the complete list of CI workflow templates offered by GitHub in the actions/starter-workflows repository.

Skipping workflow runs

If you want to temporarily prevent a workflow from being triggered, you can add a skip instruction to the commit message. Workflows that would otherwise be triggered on: push or on: pull_request, won't be triggered if you add any any of the following strings to the commit message in a push, or the HEAD commit of a pull request:

  • [skip ci]
  • [ci skip]
  • [no ci]
  • [skip actions]
  • [actions skip]

Alternatively, you can end the commit message with two empty lines followed by either skip-checks: true or skip-checks:true.

You won't be able to merge the pull request if your repository is configured to require specific checks to pass first. To allow the pull request to be merged you can push a new commit to the pull request without the skip instruction in the commit message.

Note: Skip instructions only apply to the push and pull_request events. For example, adding [skip ci] to a commit message won't stop a workflow that's triggered on: pull_request_target from running.

Benachrichtigungen für Workflow-Läufe

Wenn Sie E-Mail- oder Webbenachrichtigungen für GitHub Actions aktivieren, erhalten Sie eine Benachrichtigung, wenn ein von Ihnen ausgelöster Workflow abgeschlossen ist. Die Benachrichtigung enthält den Status der Workflow-Ausführung (einschließlich erfolgreicher, fehlgeschlagener, neutraler und abgebrochener Ausführungen). Sie können auch auswählen, ob Sie nur dann eine Benachrichtigung erhalten möchten, wenn eine Workflow-Ausführung fehlgeschlagen ist.

Notifications for scheduled workflows are sent to the user who initially created the workflow. If a different user updates the cron syntax in the workflow file, subsequent notifications will be sent to that user instead. If a scheduled workflow is disabled and then re-enabled, notifications will be sent to the user who re-enabled the workflow rather than the user who last modified the cron syntax.

Du kannst den Status von Workflow-Ausführungen auch auf der Registerkarte „Actions“ (Aktionen) eines Repositorys einsehen. Weitere Informationen findest Du unter „Eine Workflow-Ausführung verwalten."

Status-Badges für Workflow-Läufe

Weitere Informationen finden Sie unter „Einen Workflow konfigurieren“.

Weiterführende Informationen

Did this doc help you?Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

Oder, learn how to contribute.