GitHub Actions-Konfigurationen
Konfigurationsinformationen zu GitHub Actions, z. B. Geheimnisse, Workflows und Einschränkungen.
Geheimnisse in GitHub Actions
Erstellen Sie Geheimnisse (Anmeldeinformationen) in GitHub einem -Repository oder GitHub einer -Organisation. Geheimnisse sind Umgebungsvariablen (verschlüsselt), die Sie in einer Organisation oder einem Repository erstellen. Diese Geheimnisse können in Workflows GitHub Actions von verwendet werden. Weitere Informationen finden Sie unter Verschlüsselte Geheimnisse.
| Geheimer Schlüssel | Beschreibung |
|---|---|
| SN_INSTANCE_URL | ServiceNow Instanz-URL. Beispiel: https://<instance_name> .service-now.com |
| SN_ORCHESTRATION_TOOL_ID | Sys_id für das Tool GitHub, das in der Instanz ServiceNow erstellt wurde. |
| SN_DEVOPS_INTEGRATION_TOKEN | Geheimes Token für das in GitHub erstellte Tool DevOps (Parameter „devops-integration-token“ ). Um auf Ihr geheimes Token zuzugreifen, navigieren Sie zu Ihrem Tooldatensatz GitHub in ServiceNow (Alle > Tools > Orchestration-Tools), und wählen Sie in der klassischen Anwenderoberfläche Token kopieren aus. |
Workflows im Repository GitHub
Erstellen Sie eine YAML-Datei, um die Workflow-Konfiguration im -Repository GitHub zu definieren.
Bei der Definition des Workflows müssen die folgenden Punkte berücksichtigt werden:
- Alle Workflows Ihres Repositorys müssen entweder die Dateierweiterung „.yml“ oder „.yaml“ aufweisen. Alle Workflows müssen sich im Verzeichnis
„.github/workflows“befinden und der in der Workflow-Syntax für GitHub-Aktionendefinierten Syntax entsprechen. - Der Name des Workflows muss mit dem Workflow-Dateinamen übereinstimmen.
- Die Namen der Workflows unter Alle Workflows auf der Registerkarte „Aktionen“ müssen mit den Workflows übereinstimmen, die im Verzeichnis
„.github/workflows“Ihres Repositorys gespeichert sind.
- Ein Anzeigename muss für jeden Auftrag angegeben werden und muss für jeden Auftrag im Workflow eindeutig sein. Der Job-Name muss mit dem Phasennamen in der anwenderdefinierten Aktion übereinstimmen.
- Verwenden Sie das Ereignis
workflow_dispatch, um einen Workflow manuell auszulösen.
GitHub Actions Workflow-Ausführungsdetails in DevOps
Nachdem Sie die Webhooks konfiguriert haben, werden die Benachrichtigungen von GitHub Actions immer dann an ServiceNow DevOps gesendet, wenn ein Workflow ausgeführt oder ausgelöst wird.
Die folgenden Details werden an die Instanz ServiceNow gesendet, wenn ein Workflow manuell in einem GitHub -Repository ausgeführt oder automatisch ausgelöst wird.
- Der Webhook workflow_job benachrichtigt die Instanz ServiceNow mit dem Status des Auftrags (in Warteschlange, in Bearbeitung, abgeschlossen), wenn der Workflow manuell ausgeführt oder automatisch in einem GitHub -Repository ausgelöst wird.
- Eingehende Ereignisse werden in der Instanz ServiceNow für den Status des Auftrags (in der Warteschlange, in_progress und abgeschlossen) erstellt, und in_progress-Ereignisse werden ignoriert.
- In der Warteschlange platzierte und abgeschlossene eingehende Ereignisse werden verarbeitet, und für im Workflow konfigurierte Aufgaben werden Pipelineschritte ServiceNow DevOps und Orchestration-Aufgaben erstellt.
- Die Pipeline-Ausführung wird für jede Workflow-Ausführung erstellt, wobei für jeden in der Workflow-Ausführung ausgeführten Auftrag die Datensätze Aufgabenausführungen und Schrittausführungen erstellt werden.
- Sie können die Pipeline-UI verwenden, um Interaktionen und Ergebnisse in einer Pipelineausführung zu visualisieren.
GitHub wird erneut ausgeführt
Für GitHub erstellte Change-Anforderungen werden wiederverwendet, wenn sie sich in den Phasen „Implementieren“ und „Post-Implementierung“ befinden. Beispiel für eine Pipeline-Ausführung:
- Wenn ein Auftrag fehlschlägt, bevor sich die Change-Anforderung in der Implementierungsphase befindet, wird der erstellte Change-Anforderung nicht wiederverwendet, wenn die fehlgeschlagenen Aufträge erneut ausgeführt werden.
- Wenn die fehlgeschlagenen Aufträge oder alle Aufträge erneut ausgeführt werden, wird ein neuer Change Request erstellt.
- Wenn nun ein Auftrag fehlschlägt, während sich die Change-Anforderung in der Implementierungs- oder Nachimplementierungsphase befindet, wird die Change-Anforderung erneut verwendet, wenn die fehlgeschlagenen Aufträge oder alle Aufträge erneut ausgeführt werden.Hinweis:Wenn die Change-Anforderung bereits in einem vorherigen Schritt vor dem Fehlschlagen des Auftrags implementiert wurde, wird die Pipeline-Ausführung während erneuter Ausführungen nicht angehalten. Die Change-Anforderung gilt als bereits genehmigt und implementiert.
Zusammengesetzte Workflows
Bei zusammengesetzten Workflows, bei denen ein Workflow einen anderen Workflow aufruft und der Change-Schritt sich im untergeordneten Workflow befindet, muss der Parameter job-name für den Change-Schritt das folgende Format aufweisen : job-name:<parent-workflow-name> /<child-workflow-name> “ . Hier ist das Leerzeichen vor und nach dem Schrägstrich (/) obligatorisch.
GitHub Actions Einschränkungen für die DevOps Change-Geschwindigkeit Integration
- Die UmgebungenGitHub Actions und GitHub werden im Server GitHub Enterprise ab Version 3.3 unterstützt.
- Ausführliche Informationen zu Umgebungen GitHub finden Sie unter Umgebungen für Bereitstellung verwenden.
- GitHub -Umgebungen sind nur für private Repositorys in der GitHub Enterprise -Cloud verfügbar.
- Verwenden Sie für GitHub Organisationen ein bestimmtes Konto (mit Zugriff auf die erforderlichen Organisationen) mit persönlichem Zugriffstoken für die Integration mit ServiceNow DevOps, oder Sie können auch GitHub Apps über den Autorisierungscode 2.0 oder JWT verwenden.
Für die Tool-Erstellung mit GitHub Apps - JWT müssen Sie ein separates Tool für eine separate Organisation erstellen.
- Nur die neuesten GitHub Actions Scanergebnisse können für eine Workflow-Ausführung aus einer Instanz abgerufen werden.
- ServiceNow DevOps Change-Automatisierung mit anwenderdefinierter Aktion oder Umgebung wird für parallele Aufträge nicht unterstützt. Bei parallelen Aufträgen enthält die Nutzlast der Webhook-Benachrichtigung keine Informationen zu den parallel ausgeführten Aufträgen mit einer Sequenznummer. Aufgrund dieser Einschränkung hängt die Reihenfolge der Aufträge von der Ausführungsreihenfolge ab, die von der Antwort der API (/repos/{owner}/{repo}/actions/runs/{run_id}/jobs) zurückgegeben wird.
- Die Rückruf-URL zum Anhalten und Fortsetzen der Workflow-Ausführung von der Instanz ServiceNow wird nur mit der Funktion „Bereitstellungs-Gates GitHub Actions “ unterstützt. Die Change-Erstellung ist jedoch sowohl über Bereitstellungs-Gates als auch über die anwenderdefinierte GitHub-Aktion möglich.
- Der Anwender, der das Tool GitHub in der Instanz ServiceNow erstellt, muss ein Überprüfer sein, um den Workflow für die Umgebungen GitHub zu genehmigen.