Tools für kontinuierliche Integration konfigurieren
Application Dependency Management (ADM) erfordert eine Autorisierung für den Zugriff auf das Tool für kontinuierliche Integration.
Sie müssen dies als Token angeben, das als Secret in einem Vault gespeichert ist. Jedes der externen Tools für kontinuierliche Integration bietet eine Möglichkeit, dieses Token zu generieren. Für die OCI-Build-Pipeline DevOps ist kein Token erforderlich.
Dieser Abschnitt umfasst die Konfiguration der folgenden Pipelines und Workflows:
DevOps-Build-Pipeline konfigurieren
Erstellen Sie eine Build-Pipeline im DevOps-Service, wenn sie nicht vorhanden ist. Weitere Informationen finden Sie unter Erstellen einer Build-Pipeline.
Workflow für GitHub-Aktionen konfigurieren
Um einen GitHub Actions-Workflow zu konfigurieren, erstellen Sie ein persönliches Zugriffstoken (Personal Access Token, PAT) mit den Anweisungen in der GitHub-Dokumentation. Siehe Token erstellen. Das Token muss dem Principle of Least Privilege entsprechen und nur über die Berechtigung für den Zugriff auf das Repository verfügen, das vom Application Dependency Management-Service überwacht wird.
Konfigurieren Sie das Token mit den folgenden Parametern:
Parameter | Festlegen |
---|---|
Ablauf | Wählen Sie einen für das Projekt geeigneten Zeitraum aus. |
Repositorys | Wählen Sie die Option der obersten Ebene aus. Dies gilt nur, wenn Sie das Repository GitHub verwenden. Verwenden Sie dasselbe Token, mit dem das Repository GitHub konfiguriert wird. |
Workflow | Workflow auswählen. |
Kopieren Sie das Token sofort in einen sicheren Speicherort, weil Sie es später nicht mehr abrufen können. Speichern Sie das Token als Secret im Vault. Siehe Vault-Secrets verwalten.
Geben Sie die folgenden Informationen an, um einen Workflow für GitHub-Aktionen zu konfigurieren:
- URL des Projekts GitHub, das den Workflow enthält. Beispiel:
https://github.com/example/project
. - Benutzername für das Repository (entspricht dem Token).
- Name des Vaults und Secrets mit einem persönlichen Zugriffstoken für den Workflow.
- Name des Workflows oder Dateiname des Workflows.
- (Optional) Zusätzliche Parameter, die vom Workflow benötigt werden.
Der Zugriff auf ein GitHub-Projekt wird mit dem persönlichen Zugriffstoken eines Benutzeraccounts erteilt. Es wird empfohlen, einen Rechnerbenutzer-Account zu erstellen, ihm die erforderliche Mindestmenge an Projektzugriff bereitzustellen und ihn als Mitwirkender zum Projekt hinzuzufügen. Weitere Informationen finden Sie unter Rechnerbenutzer.
GitLab-Pipeline konfigurieren
Um eine GitLab-Pipeline zu konfigurieren, erstellen Sie ein persönliches Zugriffstoken (Personal Access Token, PAT) mit den Anweisungen in der GitLab-Dokumentation. Siehe Persönliches Zugriffstoken erstellen. Das Token muss dem Principle of Least Privilege entsprechen und nur über die Berechtigung für den Zugriff auf das Repository verfügen, das vom Application Dependency Management-Service überwacht wird.
Konfigurieren Sie das Token mit den folgenden Berechtigungen:
Berechtigung | Beschreibung |
---|---|
api | Umfang für die Steuerung einer Pipeline |
Kopieren Sie das Token sofort in einen sicheren Speicherort, weil Sie es später nicht mehr abrufen können. Speichern Sie das Token als Secret im Vault. Siehe Vault-Secrets verwalten.
Erstellen Sie ein Triggertoken mit den Anweisungen in der Dokumentation GitLab, und speichern Sie es als Secret im Vault. Siehe Trigger-Token erstellen.
Geben Sie die folgenden Informationen an, um eine GitLab-Pipeline zu konfigurieren:
- URL des Projekts GitLab, das die Pipeline enthält. Beispiel:
https://gitlab.com/example/project
. - Benutzername für das Repository (entspricht dem Zugriffstoken).
- Name des Vaults und Secrets mit einem persönlichen Zugriffstoken für die Pipeline.
- Name des Vaults und Secrets mit dem Trigger-Token für die Pipeline.
- (Optional) Zusätzliche Parameter, die von der Pipeline benötigt werden.
Der Zugriff auf ein GitLab-Projekt wird mit dem persönlichen Zugriffstoken eines Benutzeraccounts erteilt. Es wird empfohlen, einen Service-Account zu erstellen (ein separater Account, der für den Zugriff auf GitLab-APIs autorisiert ist), ihm den minimalen erforderlichen Projektzugriff einschließlich Zugriff auf das Repository zu gewähren und ihn als Mitwirkender zum Projekt hinzuzufügen.