CI/CD avec Jenkins sur Databricks
Cet article couvre Jenkins, qui est développé par un tiers. Pour contacter le fournisseur, consultez l’aide Jenkins.
Cet article décrit comment utiliser le serveur d’automatisation Jenkins avec Databricks pour mettre en œuvre un workflow de développement CI/CD.
Pour un aperçu de la CI/CD avec Databricks, consultez CI/CD sur Databricks. Pour les meilleures pratiques, consultez les workflows CI/CD sur Databricks et les meilleures pratiques de développement sur Databricks.
Configuration de la machine de développement local
L'exemple de cet article utilise Jenkins pour demander à la CLI Databricks et aux Declarative Automation Bundles d'effectuer les opérations suivantes :
- Créez un fichier Python wheel sur votre machine de développement locale.
- Déployez le fichier Python wheel créé, ainsi que des fichiers Python supplémentaires et des Notebooks Python depuis votre machine de développement locale vers un Workspace Databricks.
- Testez et exécutez le fichier Python wheel chargé et les Notebooks dans ce workspace.
Pour configurer votre machine de développement locale afin d'indiquer à votre Databricks Workspace d'effectuer les étapes de build et d'upload pour cet exemple, procédez comme suit sur votre machine de développement locale :
Étape 1 : Installer les outils requis
Dans cette étape, vous installez Databricks CLI, Jenkins, jq, et les outils de construction Python wheel sur votre machine de développement locale. Ces outils sont nécessaires pour exécuter cet exemple.
-
Installez Databricks CLI version 0,205 ou ultérieure, si ce n'est pas déjà fait. Jenkins utilise la CLI Databricks pour transmettre les instructions de test et d'exécution de cet exemple à votre workspace. Consultez Installer ou mettre à jour la CLI Databricks.
-
Installez et start Jenkins, si ce n'est pas déjà fait. Voir l'installation de Jenkins pour Linux, macOS ou Windows.
-
Installez jq. Cet exemple utilise
jqpour analyser une sortie de commande au format JSON. -
Utilisez
pippour installer les outils de build Python wheel avec la commande suivante (certains systèmes pourraient vous demander d'utiliserpip3au lieu depip) :Bashpip install --upgrade wheel
Étape 2 : créer un pipeline Jenkins
Dans cette étape, vous utilisez Jenkins pour créer un pipeline Jenkins pour l'exemple de cet article. Jenkins propose différents types de projets pour créer des pipelines CI/CD. Les pipelines Jenkins fournissent une interface pour définir des étapes dans un pipeline Jenkins en utilisant le code Groovy pour appeler et configurer des plugins Jenkins.
Pour créer le pipeline Jenkins dans Jenkins :
- Après avoir start Jenkins, depuis votre Tableau de bord Jenkins, cliquez sur Nouvel élément .
- Pour Entrer un nom d'élément , saisissez un nom pour le pipeline Jenkins, par exemple
jenkins-demo. - Cliquez sur l’icône du type de projet Pipeline .
- Cliquez sur **OK**. La page de Configuration du pipeline Jenkins apparaît.
- Dans la zone Pipeline , dans la liste déroulante Définition , sélectionnez Script de pipeline à partir de SCM .
- Dans la liste déroulante SCM , sélectionnez Git .
- Pour l’ URL du repository , saisissez l’URL du repository hébergé par votre fournisseur Git tiers.
- Pour le Branch Specifier , saisissez
*/<branch-name>, où<branch-name>est le nom de la Branch dans votre repository que vous souhaitez utiliser, par exemple*/main. - Pour Chemin du script , saisissez
Jenkinsfile, s'il n'est pas déjà défini. Vous créez leJenkinsfileplus tard dans cet article. - Décochez la case intitulée Lightweight checkout , si elle est déjà cochée.
- Cliquez sur Enregistrer .
Étape 3 : Ajouter des variables d'environnement globales à Jenkins
Dans cette étape, vous ajoutez trois variables d'environnement globales à Jenkins. Jenkins transmet ces variables d'environnement au CLI Databricks. Le CLI Databricks a besoin des valeurs de ces variables d'environnement pour s'authentifier auprès de votre Workspace Databricks. Cet exemple utilise l'authentification OAuth machine-à-machine (M2M) pour un Service Principal (bien que d'autres types d'authentification soient également disponibles). Pour configurer l'authentification OAuth M2M pour votre Workspace Databricks, consultez Autoriser l'accès d'un Service Principal à Databricks avec OAuth.
Les trois variables d'environnement globales pour cet exemple sont :
DATABRICKS_HOST, défini sur l'URL de votre Databricks Workspace, commençant parhttps://. Voir Noms d'instances, URL et ID de Workspace.DATABRICKS_CLIENT_ID, défini sur l'ID client du Service Principal, également connu sous le nom d'ID d'application.DATABRICKS_CLIENT_SECRET, défini sur le secret OAuth Databricks du Service Principal.
Pour définir des variables d'environnement globales dans Jenkins, depuis votre Tableau de bord Jenkins :
- Dans la barre latérale, cliquez sur Gérer Jenkins .
- Dans la section Configuration du système , cliquez sur Système .
- Dans la section Propriétés globales , cochez la case intitulée Variables d'environnement .
- Cliquez sur Ajouter , puis saisissez le Nom et la Valeur de la variable d'environnement. Répétez cette opération pour chaque variable d'environnement supplémentaire.
- Lorsque vous avez terminé d'ajouter des variables d'environnement, cliquez sur Enregistrer pour revenir à votre Tableau de bord Jenkins.
Concevoir le pipeline Jenkins
Jenkins propose plusieurs types de projets pour créer des pipelines CI/CD. Cet exemple met en œuvre un pipeline Jenkins. Les pipelines Jenkins fournissent une interface pour définir des étapes dans un pipeline Jenkins en utilisant le code Groovy pour appeler et configurer des plugins Jenkins.
Vous rédigez une définition de pipeline Jenkins dans un fichier texte appelé un Jenkinsfile , qui, à son tour, est archivé dans le repository de contrôle de code source d'un projet. Pour plus d'informations, consultez Jenkins Pipeline. Voici le pipeline Jenkins pour l'exemple de cet article. Dans cet exemple Jenkinsfile, remplacez les placeholders suivants :
- Remplacez
<user-name>et<repo-name>par le nom d'utilisateur et le nom du repository hébergés par votre fournisseur Git tiers. Cet article utilise une URL GitHub comme exemple. - Remplacez
<release-branch-name>par le nom de la release branch dans votre repository. Par exemple, cela pourrait êtremain. - Remplacez
<databricks-cli-installation-path>par le chemin d’accès sur votre machine de développement locale où la CLI Databricks est installée. Par exemple, sur macOS, cela pourrait être/usr/local/bin. - Remplacez
<jq-installation-path>par le chemin d'accès sur votre machine de développement locale oùjqest installé. Par exemple, sur macOS, cela pourrait être/usr/local/bin. - Remplacez
<job-prefix-name>par une chaîne pour aider à identifier de manière unique les Jobs créés dans votre Workspace pour cet exemple. Par exemple, cela pourrait êtrejenkins-demo. - Notez que
BUNDLETARGETest défini surdev, qui est le nom de la cible des bundles d'automatisation déclarative qui est définie plus loin dans cet article. Dans les implémentations réelles, modifiez ceci par le nom de votre propre cible de bundle. Plus de détails sur les cibles de bundle sont fournis plus loin dans cet article.
Voici le Jenkinsfile, qui doit être ajouté à la racine de votre repository :
// Filename: Jenkinsfile
node {
def GITREPOREMOTE = "https://github.com/<user-name>/<repo-name>.git"
def GITBRANCH = "<release-branch-name>"
def DBCLIPATH = "<databricks-cli-installation-path>"
def JQPATH = "<jq-installation-path>"
def JOBPREFIX = "<job-prefix-name>"
def BUNDLETARGET = "dev"
stage('Checkout') {
git branch: GITBRANCH, url: GITREPOREMOTE
}
stage('Validate Bundle') {
sh """#!/bin/bash
${DBCLIPATH}/databricks bundle validate -t ${BUNDLETARGET}
"""
}
stage('Deploy Bundle') {
sh """#!/bin/bash
${DBCLIPATH}/databricks bundle deploy -t ${BUNDLETARGET}
"""
}
stage('Run Unit Tests') {
sh """#!/bin/bash
${DBCLIPATH}/databricks bundle run -t ${BUNDLETARGET} run-unit-tests
"""
}
stage('Run Notebook') {
sh """#!/bin/bash
${DBCLIPATH}/databricks bundle run -t ${BUNDLETARGET} run-dabdemo-notebook
"""
}
stage('Evaluate Notebook Runs') {
sh """#!/bin/bash
${DBCLIPATH}/databricks bundle run -t ${BUNDLETARGET} evaluate-notebook-runs
"""
}
stage('Import Test Results') {
def DATABRICKS_BUNDLE_WORKSPACE_ROOT_PATH
def getPath = "${DBCLIPATH}/databricks bundle validate -t ${BUNDLETARGET} | ${JQPATH}/jq -r .workspace.file_path"
def output = sh(script: getPath, returnStdout: true).trim()
if (output) {
DATABRICKS_BUNDLE_WORKSPACE_ROOT_PATH = "${output}"
} else {
error "Failed to capture output or command execution failed: ${getPath}"
}
sh """#!/bin/bash
${DBCLIPATH}/databricks workspace export-dir \
${DATABRICKS_BUNDLE_WORKSPACE_ROOT_PATH}/Validation/Output/test-results \
${WORKSPACE}/Validation/Output/test-results \
-t ${BUNDLETARGET} \
--overwrite
"""
}
stage('Publish Test Results') {
junit allowEmptyResults: true, testResults: '**/test-results/*.xml', skipPublishingChecks: true
}
}
Le reste de cet article décrit chaque étape de ce pipeline Jenkins et comment configurer les artefacts et les commandes pour que Jenkins s'exécute à cette étape.
Extraire les derniers artefacts du repository tiers
La 1re étape de ce pipeline Jenkins, l’étape Checkout, est définie comme suit :
stage('Checkout') {
git branch: GITBRANCH, url: GITREPOREMOTE
}
Cette étape garantit que le répertoire de travail que Jenkins utilise sur votre machine de développement locale contient les derniers artefacts de votre repository Git tiers. Généralement, Jenkins définit ce répertoire de travail sur <your-user-home-directory>/.jenkins/workspace/<pipeline-name>. Cela vous permet, sur la même machine de développement locale, de conserver votre propre copie des artefacts en développement séparément des artefacts que Jenkins utilise à partir de votre repository Git tiers.
Valider le bundle d'assets Databricks
La deuxième étape de ce pipeline Jenkins, l’étape Validate Bundle, est définie comme suit :
stage('Validate Bundle') {
sh """#!/bin/bash
${DBCLIPATH}/databricks bundle validate -t ${BUNDLETARGET}
"""
}
Cette étape s'assure que le bundle, qui définit les workflows pour tester et exécuter vos artefacts, est syntaxiquement correct. Les Declarative Automation Bundles permettent d’exprimer des projets complets de données, d'analytique et de ML sous forme de collection de fichiers sources. Consultez Qu’est-ce qu’un Declarative Automation Bundles ?.
Pour définir le bundle de cet article, créez un fichier nommé databricks.yml à la racine du repository cloné sur votre machine locale. Dans cet exemple de fichier databricks.yml, remplacez les espaces réservés suivants :
- Remplacez
<bundle-name>par un nom de programme unique pour le bundle. Par exemple, cela pourrait êtrejenkins-demo. - Remplacez
<job-prefix-name>par une chaîne pour aider à identifier de manière unique les Jobs créés dans votre Workspace pour cet exemple. Par exemple, cela pourrait êtrejenkins-demo. Il doit correspondre à la valeurJOBPREFIXdans votre Jenkinsfile. - Remplacez
<spark-version-id>par l'ID de version de Databricks Runtime pour vos clusters de Job, par exemple13.3.x-scala2.12. - Remplacez
<cluster-node-type-id>par l'ID de type de nœud de vos clusters Job, par exemplei3.xlarge. - Notez que
devdans le mappagetargetsest le même que leBUNDLETARGETdans votre Jenkinsfile. Une cible de bundle spécifie l'hôte et les comportements de déploiement associés.
Voici le fichier databricks.yml, qui doit être ajouté à la racine de votre repository pour que cet exemple fonctionne correctement :
# Filename: databricks.yml
bundle:
name: <bundle-name>
variables:
job_prefix:
description: A unifying prefix for this bundle's job and task names.
default: <job-prefix-name>
spark_version:
description: The cluster's Spark version ID.
default: <spark-version-id>
node_type_id:
description: The cluster's node type ID.
default: <cluster-node-type-id>
artifacts:
dabdemo-wheel:
type: whl
path: ./Libraries/python/dabdemo
resources:
jobs:
run-unit-tests:
name: ${var.job_prefix}-run-unit-tests
tasks:
- task_key: ${var.job_prefix}-run-unit-tests-task
new_cluster:
spark_version: ${var.spark_version}
node_type_id: ${var.node_type_id}
num_workers: 1
spark_env_vars:
WORKSPACEBUNDLEPATH: ${workspace.root_path}
notebook_task:
notebook_path: ./run_unit_tests.py
source: WORKSPACE
libraries:
- pypi:
package: pytest
run-dabdemo-notebook:
name: ${var.job_prefix}-run-dabdemo-notebook
tasks:
- task_key: ${var.job_prefix}-run-dabdemo-notebook-task
new_cluster:
spark_version: ${var.spark_version}
node_type_id: ${var.node_type_id}
num_workers: 1
data_security_mode: SINGLE_USER
spark_env_vars:
WORKSPACEBUNDLEPATH: ${workspace.root_path}
notebook_task:
notebook_path: ./dabdemo_notebook.py
source: WORKSPACE
libraries:
- whl: '/Workspace${workspace.root_path}/files/Libraries/python/dabdemo/dist/dabdemo-0.0.1-py3-none-any.whl'
evaluate-notebook-runs:
name: ${var.job_prefix}-evaluate-notebook-runs
tasks:
- task_key: ${var.job_prefix}-evaluate-notebook-runs-task
new_cluster:
spark_version: ${var.spark_version}
node_type_id: ${var.node_type_id}
num_workers: 1
spark_env_vars:
WORKSPACEBUNDLEPATH: ${workspace.root_path}
spark_python_task:
python_file: ./evaluate_notebook_runs.py
source: WORKSPACE
libraries:
- pypi:
package: unittest-xml-reporting
targets:
dev:
mode: development
Pour plus d'informations sur le fichier databricks.yml, consultez la configuration des Declarative Automation Bundles.
Déployer le bundle vers votre Workspace
La troisième étape du Pipeline Jenkins, intitulée Deploy Bundle, est définie comme suit :
stage('Deploy Bundle') {
sh """#!/bin/bash
${DBCLIPATH}/databricks bundle deploy -t ${BUNDLETARGET}
"""
}
Cette étape fait deux choses :
- Étant donné que le mappage
artifactdans le fichierdatabricks.ymlest défini surwhl, cela indique au Databricks CLI de créer le fichier Python wheel en utilisant le fichiersetup.pyà l'emplacement spécifié. - Une fois le fichier Python wheel créé sur votre machine de développement locale, l'interface de ligne de commande Databricks déploie le fichier Python wheel créé ainsi que les fichiers Python et les notebooks spécifiés dans votre workspace Databricks. default, les Declarative Automation Bundles déploient le fichier Python wheel et d'autres fichiers vers
/Workspace/Users/<your-username>/.bundle/<bundle-name>/<target-name>.
Pour permettre la création du fichier Python wheel tel que spécifié dans le fichier databricks.yml, créez les dossiers et les fichiers suivants à la racine de votre repository cloné sur votre machine locale.
Pour définir la logique et les tests unitaires du fichier Python wheel sur lequel le Notebook s'exécutera, créez deux fichiers nommés addcol.py et test_addcol.py, et ajoutez-les à une structure de dossiers nommée python/dabdemo/dabdemo dans le dossier Libraries de votre repository :
├── ...
├── Libraries
│ └── python
│ └── dabdemo
│ └── dabdemo
│ ├── addcol.py
│ └── test_addcol.py
├── ...
Le fichier addcol.py contient une fonction de bibliothèque qui est ensuite intégrée dans un fichier Python wheel, puis installée sur un cluster Databricks. Cette fonction ajoute une nouvelle colonne, remplie par un littéral, à un DataFrame Apache Spark :
# Filename: addcol.py
import pyspark.sql.functions as F
def with_status(df):
return df.withColumn("status", F.lit("checked"))
Le fichier test_addcol.py contient des tests pour passer un objet DataFrame fictif à la fonction with_status, définie dans addcol.py. Le
résultat est ensuite comparé à un objet DataFrame contenant les valeurs attendues. Si les valeurs correspondent, ce qui est le cas ici, le test est réussi :
# Filename: test_addcol.py
import pytest
from pyspark.sql import SparkSession
from dabdemo.addcol import *
class TestAppendCol(object):
def test_with_status(self):
spark = SparkSession.builder.getOrCreate()
source_data = [
("paula", "white", "paula.white@example.com"),
("john", "baer", "john.baer@example.com")
]
source_df = spark.createDataFrame(
source_data,
["first_name", "last_name", "email"]
)
actual_df = with_status(source_df)
expected_data = [
("paula", "white", "paula.white@example.com", "checked"),
("john", "baer", "john.baer@example.com", "checked")
]
expected_df = spark.createDataFrame(
expected_data,
["first_name", "last_name", "email", "status"]
)
assert(expected_df.collect() == actual_df.collect())
Pour permettre à l'interface CLI Databricks d'empaqueter correctement ce code de bibliothèque dans un fichier Python wheel, créez deux fichiers nommés __init__.py et __main__.py dans le même dossier que les deux fichiers précédents. De plus, créez un fichier nommé setup.py dans le dossier python/dabdemo :
├── ...
├── Libraries
│ └── python
│ └── dabdemo
│ ├── dabdemo
│ │ ├── __init__.py
│ │ ├── __main__.py
│ │ ├── addcol.py
│ │ └── test_addcol.py
│ └── setup.py
├── ...
Le fichier __init__.py contient le numéro de version et l'auteur de la bibliothèque. Remplacez <my-author-name> par votre nom :
# Filename: __init__.py
__version__ = '0.0.1'
__author__ = '<my-author-name>'
import sys, os
sys.path.append(os.path.join(os.path.dirname(__file__), "..", ".."))
Le fichier __main__.py contient le point d'entrée de la bibliothèque :
# Filename: __main__.py
import sys, os
sys.path.append(os.path.join(os.path.dirname(__file__), "..", ".."))
from addcol import *
def main():
pass
if __name__ == "__main__":
main()
Le fichier setup.py contient des paramètres supplémentaires pour la création de la bibliothèque sous forme de fichier Python wheel. Remplacez <my-url>, <my-author-name>@<my-organization> et <my-package-description> par des valeurs significatives :
# Filename: setup.py
from setuptools import setup, find_packages
import dabdemo
setup(
name = "dabdemo",
version = dabdemo.__version__,
author = dabdemo.__author__,
url = "https://<my-url>",
author_email = "<my-author-name>@<my-organization>",
description = "<my-package-description>",
packages = find_packages(include = ["dabdemo"]),
entry_points={"group_1": "run=dabdemo.__main__:main"},
install_requires = ["setuptools"]
)
Testez la logique des composants du Python wheel
L'étape Run Unit Tests, la quatrième étape de ce pipeline Jenkins, utilise pytest pour tester la logique d'une bibliothèque afin de s'assurer qu'elle fonctionne comme prévu. Cette étape est définie comme suit :
stage('Run Unit Tests') {
sh """#!/bin/bash
${DBCLIPATH}/databricks bundle run -t ${BUNDLETARGET} run-unit-tests
"""
}
Cette étape utilise l'interface CLI de Databricks pour exécuter un job de notebook. Ce job exécute le notebook Python avec le nom de fichier run-unit-test.py. Ce notebook exécute pytest par rapport à la logique de la bibliothèque.
Pour exécuter les tests unitaires de cet exemple, ajoutez un fichier Notebook Python nommé run_unit_tests.py avec le contenu suivant à la racine de votre repository cloné sur votre machine locale :
# Databricks notebook source
# COMMAND ----------
# MAGIC %sh
# MAGIC
# MAGIC mkdir -p "/Workspace${WORKSPACEBUNDLEPATH}/Validation/reports/junit/test-reports"
# COMMAND ----------
# Prepare to run pytest.
import sys, pytest, os
# Skip writing pyc files on a readonly filesystem.
sys.dont_write_bytecode = True
# Run pytest.
retcode = pytest.main(["--junit-xml", f"/Workspace{os.getenv('WORKSPACEBUNDLEPATH')}/Validation/reports/junit/test-reports/TEST-libout.xml",
f"/Workspace{os.getenv('WORKSPACEBUNDLEPATH')}/files/Libraries/python/dabdemo/dabdemo/"])
# Fail the cell execution if there are any test failures.
assert retcode == 0, "The pytest invocation failed. See the log for details."
Utilisez le Python wheel intégré
La cinquième étape de ce Jenkins Pipeline, intitulée Run Notebook, exécute un Notebook Python qui appelle la logique du fichier Python wheel généré, comme suit :
stage('Run Notebook') {
sh """#!/bin/bash
${DBCLIPATH}/databricks bundle run -t ${BUNDLETARGET} run-dabdemo-notebook
"""
}
Cette étape exécute le CLI Databricks, qui à son tour demande à votre Workspace d'exécuter un job de notebook. Ce Notebook crée un objet DataFrame, le transmet à la fonction with_status de la bibliothèque, affiche le résultat et signale les résultats d'exécution du Job. Créez le notebook en ajoutant un fichier notebook Python nommé dabdaddemo_notebook.py avec le contenu suivant à la racine de votre repository cloné sur votre machine de développement locale :
# Databricks notebook source
# COMMAND ----------
# Restart Python after installing the wheel.
dbutils.library.restartPython()
# COMMAND ----------
from dabdemo.addcol import with_status
df = (spark.createDataFrame(
schema = ["first_name", "last_name", "email"],
data = [
("paula", "white", "paula.white@example.com"),
("john", "baer", "john.baer@example.com")
]
))
new_df = with_status(df)
display(new_df)
# Expected output:
#
# +------------+-----------+-------------------------+---------+
# │first_name │last_name │email │status |
# +============+===========+=========================+=========+
# │paula │white │paula.white@example.com │checked |
# +------------+-----------+-------------------------+---------+
# │john │baer │john.baer@example.com │checked |
# +------------+-----------+-------------------------+---------+
Évaluer les résultats d'exécution du notebook job
L'étape Evaluate Notebook Runs, la sixième étape de ce pipeline Jenkins, évalue les résultats de l'exécution du Job de Notebook précédent. Cette étape est définie comme suit :
stage('Evaluate Notebook Runs') {
sh """#!/bin/bash
${DBCLIPATH}/databricks bundle run -t ${BUNDLETARGET} evaluate-notebook-runs
"""
}
Cette étape exécute la CLI Databricks, qui à son tour demande à votre Workspace d'exécuter un job de fichier Python. Ce fichier Python détermine les critères d'échec et de réussite pour l'exécution du job du Notebook et rapporte ce résultat d'échec ou de réussite. Créez un fichier nommé evaluate_notebook_runs.py avec le contenu suivant à la racine de votre repository cloné sur votre machine de développement locale :
import unittest
import xmlrunner
import json
import glob
import os
class TestJobOutput(unittest.TestCase):
test_output_path = f"/Workspace${os.getenv('WORKSPACEBUNDLEPATH')}/Validation/Output"
def test_performance(self):
path = self.test_output_path
statuses = []
for filename in glob.glob(os.path.join(path, '*.json')):
print('Evaluating: ' + filename)
with open(filename) as f:
data = json.load(f)
duration = data['tasks'][0]['execution_duration']
if duration > 100000:
status = 'FAILED'
else:
status = 'SUCCESS'
statuses.append(status)
f.close()
self.assertFalse('FAILED' in statuses)
def test_job_run(self):
path = self.test_output_path
statuses = []
for filename in glob.glob(os.path.join(path, '*.json')):
print('Evaluating: ' + filename)
with open(filename) as f:
data = json.load(f)
status = data['state']['result_state']
statuses.append(status)
f.close()
self.assertFalse('FAILED' in statuses)
if __name__ == '__main__':
unittest.main(
testRunner = xmlrunner.XMLTestRunner(
output = f"/Workspace${os.getenv('WORKSPACEBUNDLEPATH')}/Validation/Output/test-results",
),
failfast = False,
buffer = False,
catchbreak = False,
exit = False
)
Importer et rapporter les résultats des tests
La 7ᵉ étape de ce pipeline Jenkins, intitulée Import Test Results, utilise la CLI Databricks pour envoyer les résultats des tests de votre Workspace vers votre machine de développement locale. La huitième et dernière étape, intitulée Publish Test Results, publie les résultats des tests sur Jenkins à l'aide du plugin Jenkins junit. Ceci vous permet de visualiser les rapports et les tableaux de bord liés à l'état des résultats des tests. Ces étapes sont définies comme suit :
stage('Import Test Results') {
def DATABRICKS_BUNDLE_WORKSPACE_FILE_PATH
def getPath = "${DBCLIPATH}/databricks bundle validate -t ${BUNDLETARGET} | ${JQPATH}/jq -r .workspace.file_path"
def output = sh(script: getPath, returnStdout: true).trim()
if (output) {
DATABRICKS_BUNDLE_WORKSPACE_FILE_PATH = "${output}"
} else {
error "Failed to capture output or command execution failed: ${getPath}"
}
sh """#!/bin/bash
${DBCLIPATH}/databricks workspace export-dir \
${DATABRICKS_BUNDLE_WORKSPACE_FILE_PATH}/Validation/Output/test-results \
${WORKSPACE}/Validation/Output/test-results \
--overwrite
"""
}
stage('Publish Test Results') {
junit allowEmptyResults: true, testResults: '**/test-results/*.xml', skipPublishingChecks: true
}
Envoyer toutes les modifications de code vers votre repository tiers
Vous devriez maintenant pousser le contenu de votre repository cloné sur votre machine de développement locale vers votre repository tiers. Avant de pousser, vous devez d'abord ajouter les entrées suivantes au fichier .gitignore dans votre repository cloné, car vous ne devriez probablement pas pousser les fichiers de travail de bundle interne, les rapports de validation, les fichiers de construction Python et les caches Python dans votre repository tiers. En général, vous souhaiterez régénérer de nouveaux rapports de validation et les dernières versions de Python wheel dans votre Workspace Databricks, au lieu d'utiliser des rapports de validation et des versions de Python wheel potentiellement obsolètes :
.databricks/
.vscode/
Libraries/python/dabdemo/build/
Libraries/python/dabdemo/__pycache__/
Libraries/python/dabdemo/dabdemo.egg-info/
Validation/
Exécuter votre pipeline Jenkins
Vous êtes maintenant prêt à exécuter votre pipeline Jenkins manuellement. Pour ce faire, depuis votre tableau de bord Jenkins :
- Cliquez sur le nom de votre pipeline Jenkins.
- Dans la barre latérale, cliquez sur Build Now .
- Pour voir les résultats, cliquez sur la dernière exécution du pipeline (par exemple,
#1), puis sur Sortie Console .
À ce stade, le pipeline CI/CD a terminé un cycle d'intégration et de déploiement. En automatisant ce processus, vous pouvez vous assurer que votre code a été testé et déployé par un processus efficace, cohérent et reproductible. Pour demander à votre fournisseur Git tiers d'exécuter Jenkins chaque fois qu'un événement spécifique se produit, tel qu'une pull request de repository, consultez la documentation de votre fournisseur Git tiers.