pipelinectl

pipelinectl est un magasin clé-valeur léger que vous pouvez utiliser dans les pipelines d' DevSecOps s pour partager des données entre les tâches et les scripts d'automatisation de la conformité.

Pour plus d'informations sur l'utilisation de cet outil, voir Ajout d'étapes de test et de génération à des pipelines.

Cloud Object Storage configuration des données de pipeline

Cloud Object Storage (COS) offre un espace de stockage illimité et durable pour les données de pipeline, telles que les artefacts de compilation, les rapports de test et les fichiers intermédiaires. Contrairement au stockage local par défaut, les fichiers stockés sur COS sont conservés d'une exécution de pipeline à l'autre et peuvent être partagés entre différents pipelines.

pipelinectl Les commandes prenant en charge les compartiments COS en tant que stockage persistant explicite sont les suivantes :

Le compartiment de données COS doit être distinct de votre compartiment de stockage des preuves, conformément aux exigences en matière d'audit et de conformité.

Configurer le COS pour les données du pipeline

Pour utiliser COS avec les opérations sur les fichiers de pipelinectl, procédez comme suit :

  1. Créer un compartiment de données
  • Vous pouvez utiliser une instance existante d' Cloud Object Storage ou en créer une nouvelle. Suivez les instructions fournies dans la section « Configuration d' Cloud Object Storage » pour :
  • Créez un compartiment de données (qui doit être distinct de votre compartiment de conservation des preuves)
  • Créer des informations d'identification de service pour le compartiment
  1. Configurer les autorisations IAM

Attribuez les rôles suivants à vos identifiants de service pour le compartiment de données : Writer, Object Writer, Reader et Content Reader.

Pour obtenir des instructions détaillées, consultez la section « Autorisations d'accès aux compartiments ».

  1. Configurer les propriétés d'environnement

Ajoutez les propriétés d'environnement suivantes à votre pipeline d' DevSecOps:

Propriété Type Valeur Description
data-cos-api-key Sécurisé Votre clé API COS Clé API issue des informations d'identification du service
data-cos-bucket-name Texte Le nom de votre seau Nom de votre compartiment de données
data-cos-endpoint Texte Point de terminaison COS URL Point de terminaison pour la région de votre compartiment

Pour trouver l'adresse de votre point de terminaison COS URL, rendez-vous sur la page de configuration de votre compartiment et copiez l'adresse correspondant à la région de votre compartiment (par exemple, s3.us-south.cloud-object-storage.appdomain.cloud). Utilisez si possible l'adresse directe ou privée pour bénéficier de meilleures performances et d'une sécurité accrue.

Enregistrez la clé API en tant que propriété sécurisée afin de protéger les informations d'identification sensibles.

  1. Configurer le cycle de vie du compartiment (recommandé)

Définissez une politique de cycle de vie pour supprimer automatiquement les anciennes données du pipeline. Il est recommandé d'appliquer une règle d'expiration de 7 jours pour la plupart des données de pipeline. Pour plus d'informations, consultez la section « Politiques de cycle de vie ».

Comprendre la portée des données COS

Contrairement aux commandes save_result et set_env, dont la portée est automatiquement limitée à chaque exécution individuelle du pipeline, les opérations sur les fichiers utilisant le backend COS (--storage=cos) s'effectuent sur un compartiment partagé qui persiste d'une exécution à l'autre du pipeline.

Comportements clés :

Pas d'isolation automatique des exécutions: les fichiers enregistrés avec la même clé lors de différentes exécutions du pipeline s'écrasent mutuellement.

Espace de noms de compartiment partagé: toutes les exécutions de pipeline utilisant la même configuration COS partagent le même espace de noms de compartiment.

Stockage persistant: les fichiers restent dans COS jusqu'à ce qu'ils soient explicitement supprimés ou qu'ils arrivent à expiration conformément aux règles de cycle de vie du compartiment.

Comparaison des portées :

Tableau 1. Comparaison de la portée des commandes
Commande Portée Persistance
save_result Tronçon de pipeline unique Spécifique à la course
set_env Tronçon de pipeline unique Spécifique à la course
save_file (local) Tronçon de pipeline unique Spécifique à la course
save_file --storage=cos Partagés pour toutes les séries Persévérant

Lorsque vous utilisez la commande list_files --storage=cos``, celle-ci renvoie TOUS les fichiers du compartiment configuré, et pas seulement ceux issus de l'exécution actuelle du pipeline. Utilisez le filtrage par préfixe pour affiner les résultats.

Bonnes pratiques pour les opérations sur les fichiers COS

Suivez ces bonnes pratiques pour organiser et gérer efficacement vos fichiers dans l' Cloud Object Storage, et éviter tout écrasement involontaire des données.

Éviter les conflits

Pour éviter les écrasements de données et les conflits :

  • Inclure des identifiants uniques dans les clés (par exemple, l'identifiant de l'exécution du pipeline, l'horodatage)
  • Utilisez des modèles de clés hiérarchiques : project/component/run-id/filename
  • Évitez les clés génériques telles que « build-artifact » sans qualificatifs

Exemple de conflit :

# Pipeline Run 1
save_file --storage=cos build-artifact ./dist/app-v1.0.0.tar.gz
# Pipeline Run 2 (overwrites Run 1's file!)
save_file --storage=cos build-artifact ./dist/app-v2.0.0.tar.gz

Exemple d'utilisation sans danger :

# Pipeline Run 1
save_file --storage=cos "build-artifact-${PIPELINE_RUN_ID}" ./dist/app-v1.0.0.tar.gz
# Pipeline Run 2 (separate key, no conflict)
save_file --storage=cos "build-artifact-${PIPELINE_RUN_ID}" ./dist/app-v2.0.0.tar.gz

Conventions de nommage des clés

Utiliser des modèles hiérarchiques

Organisez vos fichiers à l'aide de noms de clés descriptifs et hiérarchiques :

# Good: Organized, descriptive
save_file --storage=cos "artifacts/build/${PIPELINE_RUN_ID}/app.tar.gz" ./dist/app.tar.gz
save_file --storage=cos "reports/security/${BUILD_NUMBER}/scan.json" ./scan-results.json
# Avoid: Flat, generic
save_file --storage=cos "artifact" ./dist/app.tar.gz

Inclure des identifiants uniques

Utilisez des variables pour garantir l'unicité des clés à chaque exécution du pipeline :

  • ID d'exécution du pipeline : ${PIPELINE_RUN_ID}
  • Numéro de version : ${BUILD_NUMBER}
  • Horodatage : $(date +%Y%m%d-%H%M%S)
  • Git SHA du commit : ${GIT_COMMIT}

Utilisez des noms descriptifs

Choisissez des noms clairs et pertinents qui indiquent l'objectif du fichier :

# Good: Clear purpose
save_file --storage=cos "ui-service-image-${VERSION}" ./image.tar
# Avoid: Ambiguous
save_file --storage=cos "img" ./image.tar

Évitez les préfixes réservés

N'utilisez PAS de clés commençant par devsecops-pipeline-data/ (par exemple, devsecops-pipeline-data/path/to/file). Le préfixe devsecops-pipeline-data/ est réservé aux opérations internes du pipeline. L'utilisation de préfixes réservés peut entraîner une corruption des données ou des défaillances du pipeline.

Filtrage et recherche

Utilisez le filtrage par préfixe pour affiner les résultats lors de l'affichage des fichiers :

# List all artifacts for a specific project
list_files --storage=cos "myproject/artifacts/"
# List security reports for a specific date
list_files --storage=cos "reports/security/2024-01-15"

Supprimer explicitement les fichiers temporaires

Lorsque les fichiers ne sont plus nécessaires, supprimez-les explicitement :

remove_file --storage=cos "temp/build-${PIPELINE_RUN_ID}/cache.tar"

Remarques relatives à la sécurité

  • Gestion des clés API: veillez à toujours enregistrer l' data-cos-api-key e dans une propriété sécurisée. N'inscrivez jamais de clés API en dur dans les scripts ou les fichiers de configuration.
  • Principe du privilège minimal: n'accordez que les autorisations IAM minimales requises énumérées ci-dessus.
  • Séparation des compartiments: utilisez un compartiment dédié aux données de pipeline, distinct de celui de votre casier de preuves.

Utilisation

pipelinectl fournit un seul fichier binaire. Son comportement dépend de son nom (comme dans busybox). Lorsqu'il est appelé pipelinectl, le programme doit être fourni comme premier argument, par exemple, pipelinectl get_data.

Alias et méthodes disponibles:

set_env

# <key>: The name of the environment variable e.g. pipeline-namespace, app-name
# <value>: Value of the key
set_env <key> # reads <value> from `stdin`
set_env <key> <value>

Sauvegarde une chaîne arbitraire qui peut être extraite ultérieurement avec get_env.

Si <value> l'argument est absent, set_env lit à partir de l'entrée standard. prend set_env également en charge le passage de plusieurs paires clé-valeur à définir en une seule fois.

Exemple :

# set value provided as argument
set_env app-name "my-app-name"
# set value provided via stdin
echo "my-app-name" | set_env app-name
set_env my-api-key < /config/my-api-key
# set multiple key value pairs
set_env key-1 "value-1" \
  key-2 "value-2" \
  key-n "value-n"

set_envc

# <key>: The name of the environment variable e.g. pipeline-namespace, app-name
# <value>: Value of the key
set_envc <key> # reads <value> from `stdin`
set_envc <key> <value>

Enregistre une chaîne de caractères arbitraire et immuable qui peut être récupérée ultérieurement à l'aide de get_env. Une fois enregistré avec set_envc, il ne peut plus être modifié par d'autres set_env appels set_envc /.

Si <value> l'argument est absent, set_envc lit à partir de l'entrée standard. prend set_envc également en charge le passage de plusieurs paires clé-valeur à définir en une seule fois.

  • Une fois définie avec set_envc, la clé ne peut pas être écrasée par d'autres invocations de set_envc ou set_env.
  • Les variables déjà définies avec set_env ne peuvent pas être remplacées avec set_envc.

Exemple :

# set value provided as argument
set_envc app-name "my-app-name"
# set value provided via stdin
echo "my-app-name" | set_envc app-name
set_envc my-api-key < /config/my-api-key
# set multiple key value pairs
set_envc key-1 "value-1" \
  key-2 "value-2" \
  key-n "value-n"

get_env

# <key>: The name of the environment variable e.g. pipeline-namespace, app-name
get_env <key> [default]

Imprimer la valeur de configuration stockée (dans cet ordre) :

  • Si l'alias set_env a déjà été utilisé avec key, il extrait cette valeur
  • Il tente de lire le fichier $CONFIG_DIR/$key (par défaut, CONFIG_DIR prend la valeur /config)
  • Il imprime la valeur par défaut qui est spécifiée (le cas échéant)
  • Il affiche un message d'erreur et renvoie un code de sortie différent de zéro

Exemple :

get_env app-name "default-app-name"

liste_env

list_env

Affiche les clés et les variables d'environnement enregistrées dans le processus " set_env.

Exemple :

list_env

définir_secret

# <key>: The name of the secret e.g. artifactory-token, (short-lived) iam-token
# <value>: Value of the secret
set_secret <key> # reads <value> from `stdin`
set_secret <key> <value>

Sauvegarde un secret qui peut être récupéré ultérieurement avec get_secret.

Si l'argument <value> est manquant, le programme le lit set_secret à partir de l'entrée standard.

  • Le contenu défini par set_secret n'est pas sérialisé et n'est donc pas disponible dans les sous-pipelines / les pipelineruns asynchrones.
  • Désactivez la journalisation de débogage lors de l’exécution de cette commande, afin de vous assurer que le contenu du secret enregistré n’apparaisse pas, même dans les journaux de débogage.
  • Veillez à ce que les scripts et la logique ne dépendent pas de la sortie de set_secret (une instruction d'impression est utilisée pour masquer la valeur secrète en utilisant la fonctionnalité ::add-mask: : )

Exemple :

# set value provided as argument
set_secret my-secret-key "my-secret-content"
# set value provided via stdin
echo "my-secret-content" | set_secret my-secret
set_secret my-api-key < /config/my-api-key
# set multiple key value pairs
set_secret secret-key-1 "value-1" \
  secret-key-2 "value-2" \
  secret-key-n "value-n"

obtenir_secret

# <key>: The name of the secret set with set_secret or set as Secure Value in pipeline UI
get_secret <key> [default]

Récupérez la valeur secrète stockée (dans cet ordre):

  • Si l'alias set_secret a déjà été utilisé avec key, il extrait cette valeur
  • Il tente de lire le fichier $SECRET_CONFIG_DIR/$key (par défaut, SECRET_CONFIG_DIR prend la valeur /config/secure-properties)
  • Il imprime la valeur par défaut qui est spécifiée (le cas échéant)
  • Il affiche un message d'erreur et renvoie un code de sortie différent de zéro

Exemple :

get_secret cookie-token "default-token"
get_secret specific-account-ibmcloud-api-key "$(get_secret ibmcloud-api-key "")"

Mettez toujours entre guillemets les variables contenant des valeurs confidentielles

Lorsque vous stockez une valeur secrète dans une variable de shell et que vous utilisez ensuite cette variable, veillez à toujours la placer entre guillemets doubles. Sans guillemets, le shell peut fractionner la valeur en plusieurs mots avant de la transmettre à une commande.

N'utilisez pas de variables non mises entre guillemets contenant des valeurs confidentielles.

export API_KEY=$(get_secret my-api-key)
# Unsafe: a multi-line secret value is not passed intact.
# Parts of the secret may appear unmasked in the pipeline log.
some-cli login --apikey $API_KEY

Mettez toujours la variable entre guillemets pour conserver sa valeur.

export API_KEY=$(get_secret my-api-key)
# Safe: the value is passed as a single, intact string.
some-cli login --apikey "$API_KEY"

La même règle s'applique partout où la variable est utilisée : dans les arguments de commande, dans l'interpolation de chaînes ou lors de l'écriture de valeurs dans un fichier.

# Safe
curl -H "Authorization: Bearer $API_KEY" https://example.com/api
echo "$API_KEY" > /tmp/credentials.txt

liste_des_secrets

list_secrets

Affiche les clés sauvegardées du processus set_secret et les variables d'environnement de type Secure Value dans l'interface utilisateur du pipeline.

Exemple :

list_secrets

supprimer_secret

remove_secret <key>

Cette commande annule le secret stocké dans le pipelinectl, qui a été sauvegardé à l'aide de set_secret.

save_file

# <identifier>: Name used to store and retrieve the file (for example, 'build-artifact', 'my-report')
# <path>: Path to the file on the local filesystem (for example, './dist/app.tar.gz')
save_file <identifier> <path>

Sauvegarde un fichier arbitraire qui peut être extrait ultérieurement avec load_file.

Les répertoires ne sont pas pris en charge.

Stockage local (par défaut):

Les fichiers sont stockés dans l'espace de travail du pipeline et ne sont valables que pour l'exécution en cours du pipeline.

save_file some_config ./config.yaml

Stockage COS :

Les fichiers sont stockés dans Cloud Object Storage et sont conservés d'une exécution du pipeline à l'autre. Consultez la section « Portée et persistance des données » pour obtenir des informations importantes sur le comportement des compartiments partagés.

Conditions préalables : assurez-vous que COS est configuré. Voir la configuration d' Cloud Object Storage.

# Save with run-specific key
save_file --storage=cos "build-artifact-${PIPELINE_RUN_ID}" ./dist/app-v1.2.3.tar.gz
# Save with hierarchical key
save_file --storage=cos "artifacts/ui-service/${BUILD_NUMBER}/image.tar" ./image.tar
# Save report with timestamp
save_file --storage=cos "reports/security/$(date +%Y%m%d)/scan.json" ./scan-results.json

load_file

# <identifier>: Name of the file to retrieve (for example, 'build-artifact', 'my-report')
load_file <identifier>

Imprime le fichier sauvegardé dans stdout.

Stockage local (par défaut):

Récupère les fichiers enregistrés dans l'espace de travail du pipeline pour l'exécution en cours.

load_file some_config > some_config.yaml

Stockage COS :

Récupère les fichiers depuis Cloud Object Storage.

Conditions préalables : assurez-vous que COS est configuré. Voir la configuration d' Cloud Object Storage.

# Load file and print to stdout
load_file --storage=cos "build-artifact-${PIPELINE_RUN_ID}"
# Load file and save to local filesystem
load_file --storage=cos "artifacts/ui-service/${BUILD_NUMBER}/image.tar" > ./downloaded-image.tar

liste_fichiers

Liste de tous les fichiers enregistrés via save_file, éventuellement filtrés par un préfixe de clé.

# <prefix>: (optional) Filter results to keys starting with this prefix
list_files <prefix>

Affiche la liste des clés de fichiers dans stdout.

Stockage local (par défaut):

Affiche la liste des fichiers stockés dans l'espace de travail du pipeline pour l'exécution en cours.

list_files # lists all saved files
list_files saved-reports- # lists files with "saved-reports-" prefix

Stockage COS :

Répertorie les fichiers disponibles sur Cloud Object Storage. Renvoie TOUS les fichiers du compartiment configuré, et pas seulement ceux issus de l'exécution actuelle du pipeline. Utilisez le paramètre « prefix » (facultatif) pour filtrer les résultats et cibler des fichiers spécifiques.

Conditions préalables : assurez-vous que COS est configuré. Voir la configuration d' Cloud Object Storage.

# List all files in bucket (may include files from multiple runs)
list_files --storage=cos
# List files with specific prefix to narrow results
list_files --storage=cos "artifacts/ui-service/"
# List files for specific date
list_files --storage=cos "reports/security/20240115"

supprimer_fichier

Supprime un fichier enregistré.

# <identifier>: Name of the file to remove (for example, 'build-artifact', 'my-report')
remove_file <identifier>

Stockage local (par défaut):

Supprime les fichiers de l'espace de travail du pipeline pour l'exécution en cours.

remove_file my-report

Stockage COS :

Supprime les fichiers de Cloud Object Storage.

Conditions préalables : assurez-vous que COS est configuré. Voir la configuration d' Cloud Object Storage.

# Remove specific file
remove_file --storage=cos "build-artifact-${PIPELINE_RUN_ID}"
# Remove temporary file
remove_file --storage=cos "temp/cache-${BUILD_NUMBER}.tar"

save_repo

# <key>:  Key of the repository e.g. repository name
# <prop>: Type of the property, e.g. url, branch, commit etc.
# <value>: Value of the property
save_repo <key> [<prop>=<value> ...]

Enregistre un nouveau référentiel avec le pipeline ou met à jour un référentiel existant.

Propriétés prises en charge :

  • url: L' URL e permettant de cloner le référentiel.
  • path : Emplacement du référentiel cloné par rapport à la racine d'espace de travail.

D'autres noms de propriétés peuvent également être utilisés, mais pour éviter les conflits de nommage, ils doivent être précédés d'un identifiant spécifique au service; par exemple, au lieu d'utiliser foo, utilisez my-service.foo.

Exemple :

save_repo app_ui "url=${REPO_URL}" "path=app_ui_repo"
save_repo app_ui "branch=${REPO_BRANCH}"
save_repo app_ui "commit=${REPO_SHA}"
# any additional property can be added
save_repo app_ui "commit=${REPO_SHA}"

Utilisation de stdin comme source de valeur

Des valeurs peuvent être fournies à partir de stdin, si les conditions suivantes sont remplies:

  • Le contenu est diffusé pour la commande
  • Une propriété n'a pas de valeur et =

Exemple :

command_with_large_output | save_repo app_ui "issues"
# this also works with multiple properties,
# but stdin can provide value for only a single one
command_with_large_output | save_repo app_ui "issues" "result=success" "commit=${REPO_SHA}"

Si plusieurs valeurs sont manquantes avec =, la commande se termine avec une erreur, car elle ne peut pas déterminer quelle propriété appartient à la valeur sur stdin.

Les propriétés sans valeur mais qui ajoutent toujours = ont une chaîne vide comme valeur.

save_repo app_ui "bar="
load_repo app_ui bar # returns an empty string

list_repos

list_repos

Répertorie les <key> des dépôts stockés vers stdout.

Exemple :

list_repos
# returns the list of stored repository keys to stdout for example:
#  app_ui
#  app_repo

load_repo

# <key>: Key of the repository, e.g. repository name
# <prop>: Name of the property, e.g. commit, branch, url
load_repo <key> [<prop>]

Imprime la valeur de la propriété spécifiée du référentiel. Liste toutes les propriétés disponibles pour le référentiel lorsque seul le référentiel est fourni. Renvoie une erreur indiquant qu'aucune propriété correspondante n'a été trouvée si le référentiel ou la propriété fournis ne sont pas valides.

Description :

  • Affiche la valeur de la propriété spécifiée du référentiel, si les valeurs et sont fournies.
  • Répertorie toutes les propriétés disponibles pour le référentiel lorsque seul le est fourni.
  • Renvoie une erreur indiquant qu'aucune propriété correspondante n'a été trouvée si la valeur fournie n'est pas valide.

Exemple 1 : Recherche d'un bien spécifique :

REPO_SHA=$(load_repo app_ui commit)

Exemple 2 : Liste de toutes les propriétés d'un référentiel donné :

REPO_SHA=$(load_repo app_ui)

Utilisé avec " list_repos pour récupérer les valeurs des propriétés

#
# iterate over all repos and print their URLs
#
while read -r key; do
  url=$(load_repo $key url)
  echo "Repository saved as '$key' is at: '$url'"
done < <(list_repos)

Affiche les lignes suivantes dans la console:

Lors de la recherche d'une propriété spécifique :

 Repository saved as 'my-frontend' is at: 'github.com/my-team/frontend'
 Repository saved as 'my-backend' is at: 'github.com/my-team/backend'

Lors de l'établissement de la liste de toutes les propriétés d'un dépôt donné :

 Properties available for '$key'.

save_result

# <stage>: Stage name e.g. test, detect-secrets, static-scan
# <path>: Path where will be stored the file, string
save_result  <stage> <path>

Enregistre un test arbitraire et le fichier de résultats d’analyse pour une étape. Ce fichier pourra ensuite être récupéré à l'aide de load_result. Par défaut, les données sont enregistrées avec le chemin relatif à l'espace de travail comme clé.

A l'aide de l'indicateur de fonction PIPELINECTL_USE_PATH_AS_KEY, les données sont sauvegardées avec le chemin fourni comme clé.

Exemple :

#
# save the contents of the file ./results/mocha_results.json
# as an entry named "mocha_results.json" for the "test" stage
#
save_result test ./results/mocha_results.json
#
# save the contents of the file ../data/coverage.xml
# as an entry named "coverage.xml" for the "test" stage
#
save_result test ../data/coverage.xml
#
# Using the `PIPELINECTL_USE_PATH_AS_KEY` environment variable
# save the contents of the file ../data/coverage.xml
# as an entry named "../data/coverage.xml" for the "test" stage
#
PIPELINECTL_USE_PATH_AS_KEY=1 save_result test ../data/coverage.xml

list_results

# <stage>: Stage name
list_results <stage>

Répertorie les noms des fichiers enregistrés pour une étape.

Exemple :

list_results test
# mocha_results.json
# coverage.xml

load_result

# <stage>: Stage name e.g. test, detect-secrets, static-scan
# <file>: File name e.g. mocha_results.json
load_result <stage> <file>

Imprime les clés de fichier sauvegardées dans stdout. Par défaut, une clé correspond au chemin d'accès relatif à l'espace de travail du chemin d'accès au fichier fourni dans save_result. A l'aide de l'indicateur de fonction PIPELINECTL_USE_PATH_AS_KEY, une clé est le chemin d'accès au fichier fourni dans save_result. Pour obtenir la liste de clés exacte, utilisez list_results.

Exemple :

load_result test mocha_results.json
#
# Using the `PIPELINECTL_USE_PATH_AS_KEY` environment variable
PIPELINECTL_USE_PATH_AS_KEY=1 load_result test ../data/coverage.xml

Utilisé conjointement avec list_results

#
# iterate over all results stored for "test"
# and write them to the filename they were registered with
#
while read -r filename; do
  load_result test "$filename" > "./$filename"
done < <(list_results test)

save_artifact

# <key>: Key of the artifact e.g. app-image, baseimage etc.
# <prop>: Type of property e.g. name, type, tags, signature
# <value>: Value of the property
save_artifact <key> [<prop>=<value> ...]

Enregistre un nouvel artefact de génération avec le pipeline ou met à jour un artefact existant.

Images de conteneur

Quelques propriétés suggérées que vous pouvez utiliser:

  • type: peut être n'importe quel type d'artefact, y compris image.
  • name: nom qualifié complet de l'artefact. Par exemple, pour une image, quelque chose qui peut être utilisé par docker pull.
  • signature: signature valide.
  • digest: prétraitement sha256.
  • source: par exemple, http://<some-git-url>/blob/<commithash>/<path-to-file>

Toutes les propriétés peuvent être définies en plus de ces propriétés.

Pour une image, la propriété name doit également contenir la balise de l'image.

Exemple :

save_artifact ui_service "name=us.icr.io/team_namespace/ui_service:2.4.3"
save_artifact ui_service "type=image"
# any additional property can be added
save_artifact ui_service "tags=latest,2.4.3,feat-something"
# later, when the image was signed, and we have signature data
save_artifact ui_service "signature=${SIGNATURE}"

Utilisation de stdin comme source de valeur

Des valeurs peuvent être fournies à partir de stdin, si les conditions suivantes sont remplies:

  • Le contenu est diffusé pour la commande
  • Une propriété n'a pas de valeur et =

Exemple :

command_with_large_output | save_artifact ui_service "issues"
# this also works with multiple properties,
# but stdin can provide value for only a single one
command_with_large_output | save_artifact ui_service "issues" "result=success" "signature=${SIGNATURE}"

Si plusieurs valeurs sont manquantes avec =, la commande se termine avec une erreur, car elle ne peut pas déterminer quelle propriété appartient à la valeur sur stdin.

Les propriétés sans valeur mais qui ajoutent toujours = ont une chaîne vide comme valeur.

save_artifact ui_service "bar="
load_artifact ui_service bar # returns an empty string

list_artifacts

list_artifacts

Répertorie les <key> des artefacts stockés dans stdout.

Exemple :

list_artifacts
# returns the list of stored artifact keys to stdout for example:
#
# ui_service
# app_service

load_artifact

# <key>: Name of the artifact e.g. app-image, baseimage etc.
# <prop>: Type of property e.g. name, type, tags, signature
load_artifact <key> [<prop>]

Description :

  • Affiche la valeur de la propriété spécifiée du référentiel, si les valeurs et sont fournies.
  • Répertorie toutes les propriétés disponibles pour le référentiel lorsque seul le est fourni.

Exemple 1 : Recherche d'un bien spécifique :

SIGNATURE=$(load_artifact ui_service signature)

Example2: Liste de toutes les propriétés d'un artefact donné :

load_artifact ui_service

Utilisé avec " list_repos pour récupérer les valeurs des propriétés

#
# iterate over all artifacts and print their image names
#
while read -r key; do
  image=$(load_artifact $key name)
  echo "Artifact saved as '$key' is named: '$image'"
done < <(list_artifacts)

Affiche les lignes suivantes dans la console:

Lors de la recherche d'une propriété spécifique :

 Artifact saved as 'ui_service' is named: 'us.icr.io/team_namespace/ui_service:2.4.3'
 Artifact saved as 'backend_service' is named: 'us.icr.io/team_namespace/backend_service:2.4.3'

Lors de l'établissement de la liste de toutes les propriétés d'un artefact donné :

 Properties available for 'ui_service': name, type, tags, signature

Sérialiser

Sérialisez les données pipelinectl dans un fichier JSON transférable à utiliser comme contenu pour les déclencheurs de webhook de pipeline. Il peut sérialiser les référentiels définis par save_repo, les artefacts définis par save_artifact et les variables d'environnement définies par set_env.

(Facultatif) Indicateurs:

--all-repos         # all the repository information set by `pipelinectl`
--all-artifacts     # all the artifacts information set by `pipelinectl`

Exemple :

Le code suivant sauvegarde tous les référentiels, tous les artefacts et <env_variable1>, <env_variable2> dans le fichier foo.json:

pipelinectl serialize --all-repos --all-artifacts <env_variable1> <env_variable2> > foo.json
```Cette commande n'est pas un alias. Vous avez besoin de `pipelinectl` de manière explicite.
{: note}


### désérialiser {: #deserialize}

Désérialisez le fichier `pipelinectl` de JSON en fichiers, de sorte que `pipelinectl` puisse fonctionner dans le pipeline déclenché. Utilisez le JSON sérialisé par la commande `pipelinectl serialize` comme argument.

Exemple :

```bash {: codeblock}
pipelinectl deserialize ./foo.json
```Cette commande n'est pas un alias; il faut indiquer explicitement « `pipelinectl` ».
{: note}


## Méthodes de bas niveau {: #low-level-methods}

Ces méthodes ne sont exposées que par souci d'exhaustivité. Utilisez les méthodes uniquement en de rares occasions.

### put_data {: #put_data}

```bash {: codeblock}
# <key>: Name of the data
# <prop>: Type of property e.g. name, type, tags, signature
# <value>: Value of the property
put_data <key> <prop> <value>

Affecte à la propriété (prop) la valeur value pour l'entrée définie par la clé (key).

get_data

# <key>: Key of data
# <prop>: Type of property e.g. name, type, tags, signature
# <value>: Value of the property
get_data <key>
get_data <key> <prop>

Affiche prop l'entrée définie par key. Si n'est prop pas fourni, il renvoie tous prop les pour le key. Renvoie un code de sortie différent de zéro lorsque n'a key pas de prop.

actif_sauvegarde

# <prop>: Type of property; for example, uri, id, blob
# <value>: Value of the property
save_asset <prop1> <value1> blob <json_string or path to a json file>
save_asset <prop1> <value1> <prop2> <value2> blob <json_string  or path to a json file>

Enregistre les informations sur les actifs dans le stockage pipelinectl pour qu'elles soient accessibles dans tout le pipeline. Les nombres arbitraires de propriétés sont autorisés. Cependant,blob est une propriété réservée qui doit obligatoirement être transmise et sa valeur correspondante doit être un chemin d'accès à un fichier json valide ou une chaîne json valide. La propriété save_asset crée des entrées non modifiables. Il ne peut pas être appelé deux fois pour la même combinaison de paires <prop> <value>.

actif_chargement

# <prop>: Type of property; for example, uri, id
# <value>: Value of the property
load_asset # retrieves all assets stored by save_asset
load_asset <prop1> <value1> # retrieves one asset that matches prop1 = value1 saved during save_asset
load_asset <prop1> <value1> <prop2> <value2> # retrieves one asset that matches prop1 = value1 AND prop2 = value2 saved during save_asset

Extrait un actif qui correspond aux paires <prop> <value> fournies. S'il est appelé sans combinaison <prop> <value>, il extrait tous les actifs qui sont sauvegardés à l'aide de save_asset dans le pipeline à l'intérieur d'un tableau json. La propriété blob étant une propriété réservée, elle ne peut pas être utilisée comme propriété correspondante pour load_asset.

save_preuve

# <prop>: Type of property; for example, blob, sha
# <value>: Value of the property
save_evidence <prop1> <value1> blob <json_string  or path to a json file>
save_evidence <prop1> <value1> <prop2> <value2> blob <json_string  or path to a json file>

Enregistre les informations collectées dans le stockage pipelinectl pour qu'elles soient accessibles dans tout le pipeline. Les nombres arbitraires de propriétés sont autorisés. Cependant, le blob La propriété est une propriété réservée qui doit obligatoirement être transmise et sa valeur correspondante doit être un chemin de fichier vers un fichier json valide ou une chaîne json valide. La propriété save_evidence crée des entrées non modifiables. Il ne peut pas être appelé deux fois pour la même combinaison de paires <prop> <value>.

Charger les informations collectées

# <prop>: Type of property; for example, id, sha
# <value>: Value of the property
load_evidence # retrieves all evidences that are stored by save_evidence
load_evidence <prop1> <value1> # retrieves one evidence that matches prop1 = value1 saved during save_evidence
load_evidence <prop1> <value1> <prop2> <value2> # retrieves one evidence that matches prop1 = value1 AND prop2 = value2 saved during save_evidence

Extrait une preuve qui correspond aux paires <prop> <value> fournies. S'il est appelé sans combinaison <prop> <value>, il extrait toutes les informations collectées qui sont sauvegardées à l'aide de save_evidence dans le pipeline à l'intérieur d'un tableau json. La propriété blob étant une propriété réservée, elle ne peut pas être utilisée comme propriété correspondante pour load_evidence.

supprimer_les_preuves

delete_evidences # deletes all the evidences stored inside pipelinectl so far using save_evidence

Cette commande efface toutes les informations collectées stockées dans le pipelinectl, qui ont été sauvegardées à l'aide de save_evidence.

save_string (obsolète)

save_string est obsolète. Utilisez set_env à la place.

save_string <key> <value>

Sauvegarde une chaîne arbitraire qui peut être extraite ultérieurement avec load_string.

load_string (obsolète)

load_string est obsolète. Utilisez get_env à la place.

load_string <key>

Affiche la chaîne stockée dans key.