Jenkins Pipeline-Aktionen
Verwenden Sie diese Aktionen in Jenkins Pipeline, die mit interagiert werden soll DevOps Config Datenmodell.
Jenkins Geskriptete und deklarative Piplines werden unterstützt.
- SnDevOpsConfig
Kombinierte Aktion zum Hochladen, Validieren und Veröffentlichen von Konfigurationsdaten.
- SnDevOpsConfigUpload
Laden Sie Konfigurationsdaten in hoch DevOps ConfigÜber Agent-Auftrag.
- SnDevOpsConfigGetSnapshots
Ruft Snapshots für ein bestimmtes bereitstellbares Element oder alle betroffenen bereitstellbaren Elemente ab.
- SnDevOpsConfigPublish
Veröffentlichen Sie einen Snapshot für die angegebene Anwendung und das bereitstellbare Element.
- SnDevOpsConfigExport
Exportieren Sie einen Snapshot für eine bestimmte Anwendung und ein bestimmtes bereitstellbares Element.
- SnDevOpsConfigRegisterPipeline
Verknüpfen Sie ein Changeset und/oder einen Snapshot mit einer Pipeline-Ausführung.
- SnDevOpsConfigValidieren
Validieren Sie Konfigurationsdaten anhand Ihrer Organisationsrichtlinien.
- SnDevOpsChange
Erstellen Sie eine Change-Anforderung mit dem zugehörigen Snapshot.
SnDevOpsConfig
Laden Sie Konfigurationsdatenänderungen in einem Schritt hoch, validieren und veröffentlichen Sie sie.
Diese Aktion kombiniert die Aktionen snDevOpsConfigUpload, snDevOpsConfigGetSnapshots und snDevOpsConfigRegisterPipeline in einer Aktion, anstatt jede Aktion separat ausführen zu müssen.
- Eingabevariablen
ConfigFile Gibt die Konfigurationsdatendatei an, die in die Komponente oder den bereitstellbaren Pfad im Datenmodell hochgeladen werden soll. applicationName Gibt die Anwendung an, in die Konfigurationsdaten hochgeladen werden. Ziel Gibt das Datenmodellziel an, in das Konfigurationsdaten hochgeladen werden (z. B. Komponente , Sammlung , Bereitstellbar ). collectionName (Optional) Name der Sammlung, in die hochgeladen werden soll (erforderlich, wenn das Ziel „Sammlung“ ist). Bereitstellbarer Name (Optional) Name des bereitstellbaren Elements, in das hochgeladen werden soll (erforderlich, wenn das Ziel bereitstellbar ist). namePath Gibt den Namenspfad im Datenmodell an, in den Konfigurationsdaten hochgeladen werden.
Hinweis:Beim Hochladen in einen vars-Ordner müssen Sie den Namenspfad mit „vars/“ beginnen, um den Variablenordnerpfad anzugeben.Datenformat Gibt das Datenformat der Konfigurationsdatei an (z. B. JSON , YAML , XML , Usw.) Automatisches Commit Gibt an, ob Konfigurationsdaten nach dem Upload (wahr/falsch) festgeschrieben werden sollen. Der Standardwert ist „wahr“. Automatisch validieren Gibt an, ob Konfigurationsdaten während des Commits validiert werden sollen (wahr/falsch). Der Standardwert ist „wahr“. Automatisch veröffentlichen Gibt an, ob die Konfigurationsdaten nach der Validierung veröffentlicht werden sollen (wahr/falsch). Der Standardwert ist „wahr“. changesetNumber (Optional) gibt das (offene) Changeset an, dem diese Upload-Aktivität zugeordnet ist. Wenn nicht angegeben, wird ein neues Changeset erstellt.
Hinweis:Wird nur für mehrere Upload-Szenarien verwendet.Als fehlgeschlagen markieren (Optional) schlägt die Pipeline fehl, wenn der Validierungsversuch fehlgeschlagen ist (aufgrund eines Back-End-Problems). ShowResults (Optional) Validierungsergebnisse in anzeigen Jenkins Protokoll der Auftragskonsole. ContinueWithLatest (Optional) gibt an, ob der neueste Snapshot gemäß zurückgegeben werden soll ApplicatioName – Bereitstellbarer Name – ChangesetNumber Kombination, wenn keine Snapshots generiert werden (wahr/falsch). Die Standardeinstellung ist „false“. - Ausgabe
- Wenn erfolgreich, ein Snapshot oder eine Reihe von Snapshots.
- Bei einem Fehler wird eine API-/Back-End-Fehlermeldung angezeigt.
- Beispiel
- Eingabe:
snapshotObj = snDevOpsConfig( applicationName: "PaymentDemo", configFile: "config/application/Collection/Collection2/*.json", target: "collection", collectionName: "release-1.0", namePath: "settings/infrastructure/database", dataFormat: "json", autoCommit: 'true', autoValidate: 'true', autoPublish: 'true', continueWithLatest: 'true', markFailed: 'true', showResults: 'false' ) echo"*************************\n ${snapshotObj}" - Ausgabe
- Eingabe:
- Beispiel: Sammlung
- Hinweis:Beim Hochladen in eine Sammlung wird die verwendet CollectionName Argument ist erforderlich.
snDevOpsConfig( applicationName: 'PaymentDemo', target: 'collection', collectionName: 'release-1.0', namePath: 'web-api-v1.0', configFile: 'k8s/helm/*.yml', dataFormat: 'yaml', autoCommit: 'true', autoValidate: 'true', autoPublish: 'true' ) - Beispiel: Bereitstellbar
- Hinweis:Beim Hochladen in ein bereitstellbares Element wird die verwendet Bereitstellbarer Name Argument ist erforderlich.
snDevOpsConfig( applicationName: 'PaymentDemo', target: 'deployable', deployableName: 'Production', namePath: 'web-api-v1.0', configFile: 'k8s/helm/*.yml', dataFormat: 'yaml', autoCommit: 'true', autoValidate: 'true', autoPublish: 'true' ) - Mehrere Uploads in einem Commit
Um Konfigurationsdaten von verschiedenen Standorten hochzuladen oder einen Satz von Daten in mehrere Ziele (z. B. eine Komponente, ein bereitstellbares Element) hochzuladen, die als einzelner Commit in Ihr Datenmodell nachverfolgt werden, können Sie aufrufen SnDevOpsConfigUpload Aktion so oft wie erforderlich für den ersten Satz von Uploads, dann rufen Sie auf SnDevOpsConfig Aktion für den endgültigen Upload.
Hier ist ein Beispiel.
Erstellen Sie beim ersten Upload eine Variable (z. B. $Changeset), und weisen Sie ihr den Rückgabewert des Schritts zu, damit er in nachfolgenden Uploads wiederverwendet werden kann.
1 – XML-Datei in Komponente hochladen:$changeset = snDevOpsConfigUpload( applicationName: 'PaymentDemo', target: 'component', namePath: 'paymentService-v1.0', configFile: 'infra/v1/config.xml', dataFormat: 'xml', autoCommit: 'false', autoValidate: 'false', autoPublish: 'false' )Verwenden Sie bei nachfolgenden Uploads (und abschließendem Upload) die Variable als Eingabe.
2 – JSON-Datei in vars-Ordner des bereitstellbaren Elements hochladen:snDevOpsConfig( applicationName: 'PaymentDemo', target: 'deployable', deployableName: 'Production', namePath: 'vars/dbSettings', configFile: 'infra/prod/dbConfig.json', dataFormat: 'json', changesetNumber: ”${changeset}”, autoCommit: 'false', autoValidate: 'false', autoPublish: 'false', continueWithLatest: 'true' )
- Laden Sie mehrere Datenformate hoch
- Um Konfigurationsdaten in verschiedenen Dateiformaten hochzuladen, können Sie aufrufen SnDevOpsConfig Aktion mit diesen Spezifikationen.
- Stellen Sie sicher, dass ConfigFile Argument verwendet einen Platzhalter im Pfad.
- Geben Sie nicht an Datenformat Argument.
Hier ist ein Beispiel.
- Angenommen, wir haben diese Konfigurationsdateien.
- So laden Sie die Konfigurationsdateien mit hoch SnDevOpsConfig .
snDevOpsConfig( applicationName: 'PaymentDemo', target: 'component', namePath: 'paymentService-v1.0', configFile: 'infra/v1/*', autoCommit: 'true', autoValidate: 'true', autoPublish: 'true' )
SnDevOpsConfigUpload
Mit dieser Aktion wird eine Konfigurationsdatei an einen bestimmten Speicherort innerhalb eines Anwendungsdatenmodells hochgeladen.
Es soll iterativ verwendet werden, damit alle Konfigurationsdateien während der Pipeline in das Anwendungsdatenmodell hochgeladen werden.
- Hochladen in:
- Eine Komponente, eine Sammlung oder ein bereitstellbares Element.
- Der Variablenordner (vars) einer Komponente, einer Sammlung oder eines bereitstellbaren Elements.
- Muster des regulären Ausdrucks für die Konfigurationsdateieingabe.
- Möglichkeit, mehrmals in derselben Pipeline aufgerufen zu werden.
- Eingabevariablen
ConfigFile Gibt die Konfigurationsdatendatei an, die in die Komponente oder den bereitstellbaren Pfad im Datenmodell hochgeladen werden soll. applicationName Gibt die Anwendung an, in die Konfigurationsdaten hochgeladen werden. Ziel Gibt das Datenmodellziel an, in das Konfigurationsdaten hochgeladen werden (z. B. Komponente , Sammlung , Bereitstellbar ). collectionName (Optional) Name der Sammlung, in die hochgeladen werden soll (erforderlich, wenn das Ziel „Sammlung“ ist). Bereitstellbarer Name Name des bereitstellbaren Elements, in das hochgeladen werden soll (erforderlich, wenn das Ziel bereitstellbar ist). namePath Gibt den Namenspfad im Datenmodell an, in den Konfigurationsdaten hochgeladen werden.
Hinweis:Beim Hochladen in einen vars-Ordner müssen Sie den Namenspfad mit „vars/“ beginnen, um den Variablenordnerpfad anzugeben.Datenformat Gibt das Datenformat der Konfigurationsdatei an (z. B. JSON , YAML , XML , Usw.) ConvertPath (Optional) gibt an, ob die Verzeichnisstruktur von Konfigurationsdateien (in Bezug auf den Arbeitsbereich) beibehalten und das Verzeichnis in Pfade innerhalb des Datenmodells konvertiert werden soll. changesetNumber (Optional) gibt das (offene) Changeset an, dem diese Upload-Aktivität zugeordnet ist. Wenn nicht angegeben, wird ein neues Changeset erstellt.
Hinweis:Wird nur für mehrere Upload-Szenarien verwendet.Automatisches Commit Gibt an, ob Konfigurationsdaten nach dem Upload (wahr/falsch) festgeschrieben werden sollen. Die Standardeinstellung ist „false“. Automatisch validieren Gibt an, ob Konfigurationsdaten während des Commits validiert werden sollen (wahr/falsch). Die Standardeinstellung ist „false“. - Ausgabevariable
changesetNumber (Optional) gibt das (offene) Changeset an, dem diese Upload-Aktivität zugeordnet ist.
Wenn keine Changeset-Nummer angegeben wird, wird ein neues Changeset erstellt.
- Beispiel
- Eingabe:
Hier ist ein Beispiel für SnDevOpsConfigUpload Aktion. Zur Illustration weisen wir die Antwort einer Variablen zu, ChangeSetId , Die für Debugging-Szenarien in unser Konsolenprotokoll übernommen werden könnten.
changeSetId = snDevOpsConfigUpload( applicationName: "PaymentDemo", target: 'component', namePath: "web-api-v1.0", configFile: "k8s/helm/values.yml", dataFormat: "json", autoCommit: 'true', autoValidate: 'true' ) echo "Changeset: $changeSetId created" - Ausgabe:
Zusätzlich zu den Daten, die in unser Datenmodell in hochgeladen werden DevOps Config, Die Ausgabe würde so aussehen (mit dem Blue Ocean-Plugin zur Visualisierung der Konsolenausgabe).
- Eingabe:
- Beispiel – mehrere Uploads (Komponente)
- Sie können die Upload-Aktion mehrmals aufrufen, um Konfigurationsdaten in verschiedenen Dateiformaten von verschiedenen Standorten hochzuladen, während die Uploads weiterhin Teil eines Changesets bleiben.
- Benennen Sie im ersten Upload die Aktion, damit die Ausgabevariable changesetNumber in nachfolgenden Uploads wiederverwendet werden kann.YAML-Datei hochladen:
$changeset = snDevOpsConfigUpload( applicationName: 'PaymentDemo', target: 'component', namePath: 'wep-api-v1.0', configFile: 'k8s/helm/values.yml', dataFormat: 'yaml', autoCommit: 'false', autoValidate: 'false' ) - Verweisen Sie bei nachfolgenden Uploads auf die Ausgabevariable changesetNumber aus dem ersten Upload als Eingabevariable.3 JSON-Dateien hochladen:
snDevOpsConfigUpload( applicationName: 'PaymentDemo', target: 'component', namePath: 'wep-api-v1.0', configFile: 'infra/*.json', dataFormat: 'json', autoCommit: 'false', autoValidate: 'false', changesetNumber: ”${changeset}” ) - Legen Sie im letzten Aufruf nicht nur auf die Ausgabevariable changesetNumber aus dem ersten Upload als Eingabevariable, sondern auch „autocommit“ und „autoValidate“ auf fest Wahr .INI-Datei hochladen:
snDevOpsConfigUpload( applicationName: 'PaymentDemo', target: 'component', namePath: 'wep-api-v1.0', configFile: 'featureToggles/set1.ini', dataFormat: 'ini', autoCommit: 'true', autoValidate: 'true', changesetNumber: ”${changeset}” )
- Benennen Sie im ersten Upload die Aktion, damit die Ausgabevariable changesetNumber in nachfolgenden Uploads wiederverwendet werden kann.
- Beispiel – mehrere Uploads (Sammlung und vars)
- Sie können die Upload-Aktion mehrmals aufrufen, um Konfigurationsdaten in verschiedenen Dateiformaten von verschiedenen Standorten hochzuladen, während die Uploads weiterhin Teil eines Changesets bleiben.
- Erstellen Sie beim ersten Upload eine Variable (z. B. $Changeset), und weisen Sie ihr den Rückgabewert des Schritts zu, damit er in nachfolgenden Uploads wiederverwendet werden kann.XML-Datei hochladen:
$changeset = snDevOpsConfigUpload( applicationName: 'PaymentDemo', target: 'collection', collectionName: 'release-v1.0', namePath: 'v1-common-configs', configFile: 'infra/v1/config.xml', dataFormat: 'xml', autoCommit: 'false', autoValidate: 'false' ) - Verwenden Sie bei nachfolgenden Uploads die Variable als Eingabe.JSON-Datei hochladen:
snDevOpsConfigUpload( applicationName: 'PaymentDemo', target: 'deployable', deployableName: 'Production', namePath: 'vars/dbSettings', configFile: 'infra/prod/dbConfig.json', dataFormat: 'json', autoCommit: 'true', autoValidate: 'true', changesetNumber: ”${changeset}” )
Hinweis:Zum Hochladen in einen Variablenordner muss „uploadTarget“ auf festgelegt sein Bereitstellbar , Und die richtigen Werte müssen für „deployment ableName“ und „changesetNumber“ festgelegt werden. - Erstellen Sie beim ersten Upload eine Variable (z. B. $Changeset), und weisen Sie ihr den Rückgabewert des Schritts zu, damit er in nachfolgenden Uploads wiederverwendet werden kann.
SnDevOpsConfigGetSnapshots
Diese Aktion soll in verschiedenen Szenarien verwendet werden:
- Ruft alle Snapshots für alle betroffenen bereitstellbaren Elemente ab.
Wenn Konfigurationsdateien in ein Anwendungsdatenmodell hochgeladen werden, erstellt das System Snapshots für alle bereitstellbaren Elemente, die vom Upload betroffen sind. Wenn beim letzten Upload-Aufruf die Validierung aktiviert war, wird im nächsten Schritt die Liste der Snapshots iteriert und sichergestellt, dass alle die Validierung bestanden haben.
- Ruft einen bestimmten Snapshot ab.
Nach dem CD-Flow wird ein bestimmter Snapshot abgerufen, damit er veröffentlicht und dann exportiert werden kann, um ihn nachgelagert zu verwenden (z. B. um Infrastruktur oder Anwendung bereitzustellen).
- Rufen Sie die neuesten Snapshots für ein bereitstellbares Element einer Anwendung ab, falls ein Upload keine Snapshots generiert.
Ein Satz von Konfigurationsdaten ist verfügbar, um in einer Umgebung für eine Kombination aus „Application-bereitstellbaren-Changeset“ bereitzustellen, wenn keine Konfigurationsänderungen vorgenommen werden.
- Zeigen Sie die Ergebnisse der Richtlinienvalidierung in einer Pipeline-Ausführung an.
Zeigen Sie die Ergebnisse der Richtlinienvalidierung als Testergebnisse auf der Seite mit den Ergebnissen der Jenkins-Build-Tests an, einschließlich „konform mit Ausnahme“, wenn Sie einen Snapshot abrufen.
- Eingabedefinitionen
applicationName Gibt die Anwendung an, in die Konfigurationsdaten hochgeladen oder Daten exportiert werden sollen. Bereitstellbarer Name (Optional) gibt das bereitstellbare Element für die Anwendung an, für das die neuesten Snapshot-Daten abgerufen werden sollen. changesetNumber (Optional) gibt die Changeset-ID für den Satz von Konfigurationsänderungen an, an denen der Anwender interessiert ist. Ist validiert (Optional) gibt an, ob nur Snapshots zurückgegeben werden sollen, die übergeben wurden, oder ob sie mit Ausnahme (wahr/falsch) übergeben wurden. Der Standardwert ist „wahr“. ContinueWithLatest (Optional) gibt an, ob der neueste Snapshot gemäß zurückgegeben werden soll ApplicatioName – Bereitstellbarer Name – ChangesetNumber Kombination, wenn keine Snapshots generiert werden (wahr/falsch). Die Standardeinstellung ist „false“. - Ausgabe
- Wenn erfolgreich, ein Snapshot oder eine Reihe von Snapshots.
- Bei einem Fehler wird eine API-/Back-End-Fehlermeldung angezeigt.
- Beispiel
- Spezifischer Snapshot (angegeben):
$snapshots = snDevOpsConfigGetSnapshots( applicationName: 'PaymentDemo', deployableName: 'Production', changesetNumber: 'Chset-16', isValidated: 'true', continueWithLatest: 'true' ) - Letzter validierter Snapshot (gibt den neuesten Snapshot für die Kombination aus Anwendung und bereitstellbarem Element zurück):
$snapshots = snDevOpsConfigGetSnapshots( applicationName: 'PaymentDemo', deployableName: 'Production', isValidated: 'true' ) - Alle Changeset-Snapshots (gibt alle Snapshots für die Kombination aus Anwendung und bereitstellbarem Element zurück):
$snapshots = snDevOpsConfigGetSnapshots( applicationName: 'PaymentDemo', changesetNumber: 'Chset-16' ) - Zeigen Sie die Ergebnisse der Richtlinienvalidierung in einer Pipeline-Ausführung an.
- Weisen Sie dem Pfad der Datei eine Variable zu, die die während der generierten Snapshot-Validierungsergebnisse enthält SnDevOpsConfigGetSnapshots Aktion.
- Rufen Sie an JUnit-Aktion Zum Laden der Snapshot-Validierungsergebnisse in den Testabschnitt der Pipeline-Ausführung.
stage('Validate') { steps { script { changeSetResults = snDevOpsConfigGetSnapshots( … ) if (!changeSetResults) { echo "No snapshots were created" } else { def changeSetResultsObject = readJSON text: changeSetResults changeSetResultsObject.each { snapshotName = it.name snapshotObject = it } // STEP 1 validationResultsPath = "${snapshotName}_${currentBuild.projectName}_${currentBuild.number}.xml" } } } } post { always { // STEP 2 junit testResults: "${validationResultsPath}", skipPublishingChecks: true } }
- Spezifischer Snapshot (angegeben):
SnDevOpsConfigPublish
Mit dieser Aktion wird ein Snapshot für die angegebene Anwendung und das angegebene bereitstellbare Element veröffentlicht. Von hier aus kann der Snapshot über den Exportprozess verbraucht werden.
- Eingabedefinitionen
applicationName Gibt die Anwendung an, aus der Konfigurationsdaten veröffentlicht werden sollen. Bereitstellbarer Name Gibt das bereitstellbare Element für die Anwendung an, aus der Konfigurationsdaten veröffentlicht werden sollen. snapshotName Gibt den Namen des zu veröffentlichenden Snapshots an. - Ausgabe
- Wenn erfolgreich, „wahr“.
- Andernfalls „falsch“.
- Beispiel
snDevOpsConfigPublish( applicationName: 'PaymentDemo', deployableName: 'Production', snapshotName: 'Production-v23.dpl', )
SnDevOpsConfigExport
Mit dieser Aktion wird ein Snapshot für die angegebene Anwendung und das bereitstellbare Element exportiert.
Der Anwender muss den Exporter, relevante Exporter-Argumente, das Exportformat (z. B. YAML, JSON usw.) und den Ausgabeort für die exportierten Konfigurationsdaten angeben.
Von hier aus können die Konfigurationsdaten direkt als Eingabe für ein nachgelagertes Bereitstellungs- oder Bereitstellungstool in der Pipeline verwendet werden.
- Eingabeargumente
applicationName Gibt die Anwendung an, aus der Daten exportiert werden sollen. Bereitstellbarer Name Gibt die bereitstellbare Konfiguration für die Anwendung an, aus der Daten exportiert werden sollen. snapshotName (Optional) gibt den Snapshot an, aus dem Daten exportiert werden sollen.
Wenn kein Snapshot angegeben ist, wird der neueste Snapshot für das bereitstellbare Element verwendet.
ExporterName Gibt den Exporter an, der auf den Snapshot angewendet werden soll (z. B. UniqueCDIs ). ExporterArgumente (Optional) gibt Argumente an, die zusammen mit dem Exporter verwendet werden sollen. Exportformat Gibt das Format zum Exportieren der Snapshot-Daten an (z. B. INI , YAML , EIGENSCHAFTEN ). fileName Gibt die Datei an, in die Daten exportiert werden sollen (wird angenommen, dass sie sich im Arbeitsbereich befindet).
Wenn kein Dateiname angegeben ist, wird standardmäßig eine Verkettung aus Anwendungsname und Name des bereitstellbaren Elements (plus Dateierweiterung) verwendet.
- Ausgabe
- Wenn erfolgreich, „wahr“.
- Andernfalls „falsch“.
- Beispiel
snDevOpsConfigExport( applicationName: 'PaymentDemo', deployableName: 'Production', snapshotName: 'Production-v23.dpl', exporterFormat: 'yaml', exporterName: 'returnAllData-now', exporterArgs: '', fileName: 'exported_file-Production-20220302.yml' )
SnDevOpsConfigRegisterPipeline
Diese Aktion verknüpft ein Changeset und/oder einen Snapshot mit der Pipeline, sodass sie während der Pipeline-Ausführung nachverfolgt werden kann. In DevOps Change-Geschwindigkeit, Wird in der Pipeline-UI angezeigt.
Siehe Beschleunigen Sie Ihre DevOps Change-Prozess Weitere Informationen zu finden DevOps Change Acceleration-Funktion.
- Eingabeargumente
applicationName Gibt den Namen der Anwendung an. changesetNumber (Optional) gibt das Changeset an, das der Pipeline-Ausführung zugeordnet werden soll.
Hinweis:Geben Sie entweder „changesetNumber“ oder „snapshotName“ an, aber nicht beides.snapshotName (Optional) gibt den Namen des Snapshots an, der der Pipeline-Ausführung zugeordnet werden soll.
Hinweis:Geben Sie entweder „changesetNumber“ oder „snapshotName“ an, aber nicht beides.- Ausgabe
- Wenn erfolgreich, „wahr“.
- Andernfalls „falsch“.
- Beispiel
- Eingabe:
Hier ist ein Beispiel für SnDevOpsConfigRegisterPipeline Aktion. Zur Illustration weisen wir die Antwort einer Variablen zu, ChangeSetRegResult , Die für Debugging-Szenarien in unser Konsolenprotokoll übernommen werden könnten.
changeSetRegResult = snDevOpsConfigRegisterPipeline( applicationName: "PaymentDemo", changesetNumber: "Chset-122" ) echo "Pipeline registration result: ${changeSetRegResult}" - Ausgabe:
Zusätzlich zu den Daten, die in unser Datenmodell in hochgeladen werden DevOps Config, Die Ausgabe würde so aussehen (mit dem Blue Ocean-Plugin zur Visualisierung der Konsolenausgabe).
- Eingabe:
SnDevOpsConfigValidieren
Validieren Sie Konfigurationsdaten anhand Ihrer Organisationsrichtlinien.
- Eingabeargumente
applicationName Zu validierende Anwendung. Bereitstellbarer Name Bereitstellbar für die Anwendung zur Validierung. snapshotName (Optional) Name des zu validierenden Snapshots. Als fehlgeschlagen markieren (Optional) schlägt die Pipeline fehl, wenn der Validierungsversuch fehlgeschlagen ist (aufgrund eines Back-End-Problems). ShowResults (Optional) Validierungsergebnisse in anzeigen Jenkins Protokoll der Auftragskonsole. - Ausgabe
- Wenn erfolgreich, keine Ausgabe.
- Bei einem Fehler wird eine API-/Back-End-Fehlermeldung angezeigt.
- Beispiel
- Spezifischer Snapshot (angegeben):
snDevOpsConfigValidate( applicationName: 'PaymentDemo', deployableName: 'Production', snapshotName: 'Production-v23.dpl', ) - Aktueller Snapshot (ruft den neuesten Snapshot für die Kombination aus Anwendung und bereitstellbarem Element ab und validiert ihn):
$changeset = snDevOpsConfigValidate( applicationName: 'PaymentDemo', deployableName: 'Production' )
- Spezifischer Snapshot (angegeben):
SnDevOpsChange
Erstellen Sie eine Change-Anforderung, und hängen Sie einen Snapshot zur Referenz an.
Siehe Beschleunigen Sie Ihre DevOps Change-Prozess Weitere Informationen zu finden DevOps Change Acceleration-Funktion.
- Eingabeargumente
applicationName Gibt den Namen der Anwendung an. snapshotName Gibt den Namen des Snapshots an, der der Change-Anforderung zugeordnet werden soll. - Beispiel
snDevOpsChange( applicationName: 'PaymentDemo', snapshotName: 'Production-v23.dpl' )
Beispiel für Jenkins-Pipeline
pipeline {
environment {
buildArtifactsPath = "build_artifacts/${currentBuild.number}"
validationResultsPath = ""
}
agent any
stages {
// Initialize pipeline
stage('Initialize') {
steps {
script {
// DevOps Config application related information
appName = 'PaymentDemo'
deployableName = 'Production'
componentName = "web-api-v1.0"
collectionName = "release-1.0"
// Configuration file information
exportFormat = 'yaml'
configFilePath = "k8s/helm/values.yml"
// Exporter related information
exporterName = 'returnAllData-nowPreview'
exporterArgs = ''
// Jenkins variables declared to be used in pipeline
exportFileName = "${buildArtifactsPath}/export_file-${appName}-${deployableName}-${currentBuild.number}.${exportFormat}"
changeSetId = ""
snapshotName = ""
snapshotObject = ""
isSnapshotValidateionRequired = false
isSnapshotPublisingRequired = false
}
}
}
// Validate configuration data changes
stage('Validate') {
parallel {
stage('Config') {
stages('Config Steps') {
// Upload configuration data to DevOps Config
stage('Upload, Validate, & Publish') {
steps {
sh "echo uploading and auto-validating configuration file: ${configFilePath}"
script {
changeSetResults = snDevOpsConfig(
applicationName: "${appName}",
target: 'component',
namePath: "${componentName}",
configFile: "${configFilePath}",
dataFormat: "${configFileFormat}",
autoCommit: 'true',
autoValidate: 'true',
autoPublish: 'true',
isValidated: 'true',
continueWithLatest: 'true',
markFailed: 'true'
)
echo "Snapshots generated, validated, and published: ${changeSetResults}"
def changeSetResultsObject = readJSON text: changeSetResults
changeSetResultsObject.each {
snapshotName = it.name
snapshotObject = it
}
validationResultsPath = "${snapshotName}_${currentBuild.projectName}_${currentBuild.number}*.xml"
}
}
}
// Export published snapshot to be used by downstream deployment tools
stage('Export') {
steps {
script {
// create build artifacts dir to store export file
sh "mkdir -p ${buildArtifactsPath}"
exportResponse = snDevOpsConfigExport(
applicationName: "${appName}",
snapshotName: "${snapshotObject.name}",
deployableName: "${deployableName}",
exporterFormat: "${exportFormat}",
fileName: "${exportFileName}",
exporterName: "${exporterName}",
exporterArgs: "${exporterArgs}"
)
}
}
}
}
}
}
}
// Create change request and attach snapshot for reference
stage('Change Management') {
steps {
script {
// Trigger change request
snDevOpsChange(
applicationName: "${appName}",
snapshotName: "${snapshotName}"
)
}
}
}
}
// NOTE: attach snapshot validation results to run (if the snapshot fails validation)
post {
always {
// attach policy validation results
junit testResults: "${validationResultsPath}", skipPublishingChecks: true
}
}
}