COS für Pipeline-Daten konfigurieren

Um COS mit den Dateioperationen von pipelinectl zu verwenden, führen Sie die folgenden Konfigurationsschritte durch:

1. Daten-Bucket erstellen

• Sie können eine vorhandene „ Cloud Object Storage “-Instanz verwenden oder eine neue erstellen. Befolgen Sie die Anweisungen unter „ Cloud Object Storage konfigurieren“, um:
• Erstellen Sie einen Daten-Bucket (dieser muss sich von Ihrem „Evidence Locker“-Bucket unterscheiden)
• Erstellen Sie eine Dienstanmeldung für den Bucket

2. IAM-Berechtigungen konfigurieren

Weisen Sie Ihren Dienstzugangsdaten für den Daten-Bucket die folgenden Rollen zu: „Writer“, „ Object Writer “, „ Reader “ und „ Content Reader “.

Ausführliche Anweisungen finden Sie unter „ Zugriffsberechtigungen für Buckets “.

3. Umgebungseigenschaften konfigurieren

Fügen Sie Ihrer „ DevSecOps “-Pipeline die folgenden Umgebungseigenschaften hinzu:

Um den COS-Endpunkt URL zu finden, rufen Sie die Konfigurationsseite Ihres Buckets auf und kopieren Sie den Endpunkt für die Region Ihres Buckets (zum Beispiel s3.us-south.cloud-object-storage.appdomain.cloud). Verwenden Sie nach Möglichkeit den direkten oder privaten Endpunkt, um eine bessere Leistung und Sicherheit zu erzielen.

Speichern Sie den API-Schlüssel als sichere Eigenschaft, um sensible Anmeldedaten zu schützen.

4. Lebenszyklus des Buckets konfigurieren (empfohlen)

Legen Sie eine Lebenszyklusrichtlinie fest, um alte Pipeline-Daten automatisch zu löschen. Für die meisten Pipeline-Daten wird eine 7-Tage-Verfallsregel empfohlen. Anweisungen finden Sie unter „ Lebenszyklusrichtlinien “.

Den Geltungsbereich von COS-Daten verstehen

Im Gegensatz zu den Befehlen „ save_result “ und „ set_env “, deren Geltungsbereich automatisch auf einzelne Pipeline-Durchläufe beschränkt ist, werden Dateioperationen, die das COS-Backend nutzen (--storage=cos), in einem gemeinsamen Bucket ausgeführt, der über alle Pipeline-Durchläufe hinweg bestehen bleibt.

Wichtige Verhaltensweisen:

Keine automatische Laufisolierung: Dateien, die mit demselben Schlüssel aus verschiedenen Pipeline-Läufen gespeichert werden, überschreiben sich gegenseitig.

Gemeinsamer Bucket-Namespace: Alle Pipeline-Läufe, die dieselbe COS-Konfiguration verwenden, nutzen denselben Bucket-Namespace.

Dauerhafter Speicher: Dateien verbleiben im COS, bis sie explizit gelöscht werden oder gemäß den Lebenszyklusregeln des Buckets verfallen.

Vergleich der Anwendungsbereiche:

Wenn Sie den Befehl „ list_files --storage=cos “ verwenden, gibt dieser ALLE Dateien im konfigurierten Bucket zurück, nicht nur die Dateien aus dem aktuellen Pipeline-Lauf. Verwenden Sie die Präfixsuche, um die Ergebnisse einzugrenzen.

Bewährte Verfahren für den Umgang mit COS-Dateien

Befolgen Sie diese bewährten Vorgehensweisen, um Dateien in „ Cloud Object Storage “ effektiv zu organisieren und zu verwalten und ein unbeabsichtigtes Überschreiben von Daten zu vermeiden.

# 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

# 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

# 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

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

# 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"

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

Sicherheitsaspekte

• Verwaltung von API-Schlüsseln: Speichern Sie den API-Schlüssel ( data-cos-api-key ) stets als sichere Eigenschaft. API-Schlüssel sollten niemals fest in Skripten oder Konfigurationsdateien hinterlegt werden.
• Prinzip der geringsten Berechtigungen: Erteilen Sie nur die oben aufgeführten, unbedingt erforderlichen IAM-Berechtigungen.
• Trennung der Buckets: Verwenden Sie für Pipeline-Daten einen eigenen Bucket, der von Ihrem „Evidence Locker“-Bucket getrennt ist.

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>

Speichert eine beliebige Zeichenfolge, die später mit get_env abgerufen werden kann.

Wenn das <value> Argument fehlt, set_env liest es aus der Standardeingabe. unterstützt set_env auch die Übergabe mehrerer Schlüssel-Wert-Paare, die gleichzeitig gesetzt werden sollen.

Beispiel:

# 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"

einstellen_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>

Speichert eine unveränderliche beliebige Zeichenfolge, die später mit abgerufen werden kann get_env. Einmal mit gespeichert set_envc, kann es durch weitere set_env / set_envc Aufrufe nicht mehr geändert werden.

Wenn das <value> Argument fehlt, set_envc liest es aus der Standardeingabe. unterstützt set_envc auch die Übergabe mehrerer Schlüssel-Wert-Paare, die gleichzeitig gesetzt werden sollen.

• Sobald die Taste mit eingestellt set_envc wurde, kann sie nicht mehr durch weitere Aufrufe von set_envc oder überschrieben set_env werden.
• Variablen, die bereits mit set_env gesetzt wurden, können nicht mit überschrieben set_envc werden.

Beispiel:

# 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]

Geben Sie den gespeicherten Konfigurationswert (in dieser Reihenfolge) aus:

• Wenn set_env zuvor mit key verwendet wurde, wird dieser Wert abgerufen.
• Es wird versucht, die Datei $CONFIG_DIR/$key zu lesen (CONFIG_DIR wird standardmäßig auf /config gesetzt).
• Es wird der angegebenen Standardwert (sofern vorhanden) ausgegeben.
• Es gibt eine Fehlermeldung aus und gibt einen Exit-Code ungleich Null zurück

Beispiel:

get_env app-name "default-app-name"

liste_Env

list_env

Zeigt die gespeicherten Schlüssel und Umgebungsvariablen aus dem Prozess set_env an.

Beispiel:

list_env

set_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>

Speichert ein Geheimnis, das zu einem späteren Zeitpunkt mit get_secret.

Fehlt das Argument <value>, liest set_secret das Programm es aus der Standardeingabe ein.

• Der von set_secret eingestellte Inhalt wird nicht serialisiert und ist daher nicht über Sub-Pipelines / asynchrone Pipelineruns verfügbar.
• Deaktivieren Sie die Debug-Protokollierung rund um die Ausführung dieses Befehls, um sicherzustellen, dass der gespeicherte geheime Inhalt nicht einmal in Debug-Protokollen erscheint.
• Stellen Sie sicher, dass Skripte und jegliche Logik nicht von der Ausgabe von set_secret abhängen (es wird eine Druckanweisung ausgeführt, um den geheimen Wert zu maskieren, wobei die ::add-mask:: Funktion verwendet wird)

Beispiel:

# 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"

get_secret

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

Rufen Sie den gespeicherten geheimen Wert ab (in dieser Reihenfolge):

• Wenn set_secret zuvor mit key verwendet wurde, wird dieser Wert abgerufen.
• Es wird versucht, die Datei $SECRET_CONFIG_DIR/$key zu lesen (SECRET_CONFIG_DIR wird standardmäßig auf /config/secure-properties gesetzt).
• Es wird der angegebenen Standardwert (sofern vorhanden) ausgegeben.
• Es gibt eine Fehlermeldung aus und gibt einen Exit-Code ungleich Null zurück

Beispiel:

get_secret cookie-token "default-token"

get_secret specific-account-ibmcloud-api-key "$(get_secret ibmcloud-api-key "")"

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

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

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

liste_Geheimnisse

list_secrets

Zeigt die gespeicherten Schlüssel aus dem Prozess set_secret und Umgebungsvariablen vom Typ Secure Value in der Pipeline-Benutzeroberfläche an.

Beispiel:

list_secrets

Geheimnis entfernen

remove_secret <key>

Dieser Befehl setzt das in der Pipelinectl gespeicherte Geheimnis zurück, das mit set_secret gespeichert wurde.

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>

Speichert eine beliebige Datei, die später mit load_file abgerufen werden kann.

Verzeichnisse werden nicht unterstützt.

Lokaler Speicher (Standard):

Dateien werden im Pipeline-Arbeitsbereich gespeichert und gelten nur für den aktuellen Pipeline-Lauf.

save_file some_config ./config.yaml

COS-Speicher:

Die Dateien werden unter Cloud Object Storage gespeichert und bleiben über mehrere Pipeline-Durchläufe hinweg erhalten. Wichtige Informationen zum Verhalten gemeinsam genutzter Buckets finden Sie unter „ Datenbereich und Persistenz “.

Voraussetzungen: Stellen Sie sicher, dass COS konfiguriert ist. Siehe Konfiguration unter 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>

Gibt die gespeicherte Datei in der Standardausgabe (stdout) aus.

Lokaler Speicher (Standard):

Ruft die Dateien ab, die im Pipeline-Arbeitsbereich für den aktuellen Durchlauf gespeichert sind.

load_file some_config > some_config.yaml

COS-Speicher:

Ruft Dateien von Cloud Object Storage ab.

Voraussetzungen: Stellen Sie sicher, dass COS konfiguriert ist. Siehe Konfiguration unter 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_dateien

Listet alle gespeicherten Dateien auf, die über save_file gespeichert wurden, optional gefiltert nach einem Schlüsselpräfix.

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

Gibt die Liste der Dateischlüssel in aus stdout.

Lokaler Speicher (Standard):

Listet die Dateien auf, die im Pipeline-Arbeitsbereich für den aktuellen Durchlauf gespeichert sind.

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

COS-Speicher:

Listet Dateien aus „ Cloud Object Storage “ auf. Gibt ALLE Dateien im konfigurierten Bucket zurück, nicht nur die Dateien aus dem aktuellen Pipeline-Lauf. Verwenden Sie den optionalen Präfix-Parameter, um die Ergebnisse zu filtern und auf bestimmte Dateien einzugrenzen.

Voraussetzungen: Stellen Sie sicher, dass COS konfiguriert ist. Siehe Konfiguration unter 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"

Datei löschen

Löscht eine gespeicherte Datei.

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

Lokaler Speicher (Standard):

Entfernt Dateien aus dem Pipeline-Arbeitsbereich für den aktuellen Durchlauf.

remove_file my-report

COS-Speicher:

Entfernt Dateien aus dem Verzeichnis „ Cloud Object Storage “.

Voraussetzungen: Stellen Sie sicher, dass COS konfiguriert ist. Siehe Konfiguration unter 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> ...]

Registriert ein neues Repository mit der Pipeline oder aktualisiert ein vorhandenes Repository.

Unterstützte Eigenschaften:

• url: Die URL, die zum Klonen des Repositorys verwendet werden kann.
• path: Position des geklonten Repositorys relativ zum Stammverzeichnis des Arbeitsbereichs.

Es können auch andere Eigenschaftsnamen verwendet werden, doch um Namenskonflikte zu vermeiden, muss ihnen ein dienstspezifischer Bezeichner vorangestellt werden; verwenden Sie beispielsweise anstelle von "" foo"" my-service.foo.

Beispiel:

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}"

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}"

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

list_repos

list_repos

Listet die <key> der gespeicherten Repos auf stdout.

Beispiel:

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>]

Druckt den Wert der angegebenen Eigenschaft des Repository. Listet alle verfügbaren Eigenschaften für das Repository auf, wenn nur das Repository angegeben ist. Gibt einen Fehler zurück, der besagt, dass keine übereinstimmenden Eigenschaften gefunden wurden, wenn das angegebene Repository oder die angegebene Eigenschaft ungültig ist.

Beschreibung:

• Gibt den Wert der angegebenen Eigenschaft des Repositorys aus, sofern und Werte angegeben sind.
• Listet alle verfügbaren Eigenschaften für das Repository auf, wenn nur das angegeben wird.
• Gibt einen Fehler zurück, der darauf hinweist, dass keine übereinstimmenden Eigenschaften gefunden wurden, wenn die angegebene ungültig ist .

Beispiel 1: Abrufen einer bestimmten Eigenschaft:

REPO_SHA=$(load_repo app_ui commit)

Beispiel 2: Auflisten aller Eigenschaften für ein bestimmtes Repository:

REPO_SHA=$(load_repo app_ui)

Wird mit list_repos zum Abrufen von Eigenschaftswerten verwendet

#
# 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)

Gibt die folgenden Zeilen an die Konsole aus:

Beim Abrufen einer bestimmten Eigenschaft:

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

Beim Auflisten aller Eigenschaften für ein bestimmtes Repository:

 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>

Speichert eine beliebige Test- oder Scan-Ergebnisdatei für eine Phase. Später kann diese Datei mit load_result. abgerufen werden. Standardmäßig werden Daten mit dem Arbeitsbereichs-relativen Pfad als Schlüssel gespeichert.

Mit dem Feature-Flag PIPELINECTL_USE_PATH_AS_KEY werden Daten mit dem angegebenen Pfad als Schlüssel gespeichert.

Beispiel:

#
# 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>

Listet die Namen der gespeicherten Dateien für eine Stufe auf.

Beispiel:

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>

Gibt die gespeicherte Dateischlüssel in der Standardausgabe (stdout) aus. Standardmäßig ist ein Schlüssel der arbeitsbereichsrelative Pfad des angegebenen Dateipfads in save_result. Mit dem Feature-Flag PIPELINECTL_USE_PATH_AS_KEY ist ein Schlüssel der Pfad des bereitgestellten Dateipfads in save_result. Um die genaue Liste der Schlüssel abzurufen, verwenden Sie list_results.

Beispiel:

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

Wird zusammen mit list_results verwendet.

#
# 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> ...]

Registriert ein neues Build-Artefakt mit der Pipeline oder aktualisiert ein vorhandenes Artefakt.

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}"

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}"

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

list_artifacts

list_artifacts

Listet die <key> der gespeicherten Artefakte auf stdout.

Beispiel:

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>]

Beschreibung:

• Gibt den Wert der angegebenen Eigenschaft des Repositorys aus, sofern und Werte angegeben sind.
• Listet alle verfügbaren Eigenschaften für das Repository auf, wenn nur das angegeben wird.

Beispiel 1: Abrufen einer bestimmten Eigenschaft:

SIGNATURE=$(load_artifact ui_service signature)

Example2: Auflisten aller Eigenschaften für ein bestimmtes Artefakt:

load_artifact ui_service

Wird mit list_repos zum Abrufen von Eigenschaftswerten verwendet

#
# 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)

Gibt die folgenden Zeilen an die Konsole aus:

Beim Abrufen einer bestimmten Eigenschaft:

 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'

Beim Auflisten aller Eigenschaften für ein bestimmtes Artefakt:

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

Serialisieren

Serialisieren Sie pipelinectl-Daten in eine übertragbare JSON-Datei, die als Nutzdaten für Pipeline-Webhook-Auslöser verwendet wird. Es kann Repositorys serialisieren, die von save_repo festgelegt werden, Artefakte, die von save_artifact festgelegt werden, und Umgebungsvariablen, die von set_env festgelegt werden.

(Optional) Flags

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

Beispiel:

Der folgende Code speichert alle Repositorys, alle Artefakte und <env_variable1>, <env_variable2> in der Datei foo.json:

pipelinectl serialize --all-repos --all-artifacts <env_variable1> <env_variable2> > foo.json
```Dieser Befehl ist kein Alias. Sie benötigen ausdrücklich `pipelinectl`.
{: note}


### deserialisieren {: #deserialize}

Entserialisieren Sie `pipelinectl` aus JSON in Dateien, damit `pipelinectl` in der ausgelösten Pipeline arbeiten kann. Verwenden Sie die vom Befehl `pipelinectl serialize` serialisierte JSON als Argument.

Beispiel:

```bash {: codeblock}
pipelinectl deserialize ./foo.json
```Dieser Befehl ist kein Alias; „ `pipelinectl` “ muss explizit angegeben werden.
{: note}


## Low-Level-Methoden {: #low-level-methods}

Diese Methoden sind nur der Vollständigkeit halber zugänglich. Verwenden Sie die Methoden nur in seltenen Fällen.

### 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>

Setzt prop auf den value für den Eintrag, der durch den keydefiniert wird.

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>

Ausgaben des prop Eintrags, der durch definiert ist key. Wenn nicht angegeben prop ist, werden alle für die prop zurückgegeben key. Gibt einen Exit-Code ungleich Null zurück, wenn keine key hat prop.

Save_Asset

# <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>

Speichert Assetinformationen im pipelinectl-Speicher, damit in der gesamten Pipeline auf sie zugegriffen werden kann. Es sind beliebig viele Eigenschaften zulässig. Jedoch,blob ist eine reservierte Eigenschaft, die zwingend übergeben werden muss, und der entsprechende Wert sollte ein Dateipfad zu einer gültigen JSON-Datei oder einer gültigen JSON-Zeichenfolge sein. Die Eigenschaft save_asset erstellt unveränderliche Einträge. Sie kann nicht zweimal für dieselbe Kombination von <prop> <value>-Paaren aufgerufen werden.

Asset laden

# <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

Ruft ein Asset ab, das den angegebenen <prop> <value>-Paaren entspricht. Wenn sie ohne <prop> <value>-Kombination aufgerufen wird, ruft sie alle Assets ab, die mit save_asset in der Pipeline in einem JSON-Array gespeichert werden. Die Eigenschaft blob ist eine reservierte Eigenschaft und kann deshalb nicht als übereinstimmende Eigenschaft für load_asset verwendet werden.

'save_evidence'

# <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>

Speichert Angabeninformationen im pipelinectl-Speicher, um in der gesamten Pipeline zugänglich zu sein. Es sind beliebig viele Eigenschaften zulässig. Allerdings blob Die Eigenschaft ist eine reservierte Eigenschaft, die zwingend übergeben werden muss, und der entsprechende Wert sollte ein Dateipfad zu einer gültigen JSON-Datei oder einer gültigen JSON-Zeichenfolge sein. Die Eigenschaft save_evidence erstellt unveränderliche Einträge. Sie kann nicht zweimal für dieselbe Kombination von <prop> <value>-Paaren aufgerufen werden.

'load_evidence'

# <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

Ruft eine Angabe ab, die den angegebenen <prop> <value>-Paaren entspricht. Bei einem Aufruf ohne <prop> <value>-Kombination werden alle Angaben abgerufen, die mit save_evidence in der Pipeline in einem JSON-Array gespeichert werden. Die Eigenschaft blob ist eine reservierte Eigenschaft und kann deshalb nicht als übereinstimmende Eigenschaft für load_evidence verwendet werden.

Löschen von Angaben

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

Dieser Befehl löscht alle Angaben, die in der Datei 'pipelinectl' gespeichert wurden, die mit save_evidence gespeichert wurden.

save_string (veraltet)

save_string ist veraltet. Verwenden Sie stattdessen set_env.

save_string <key> <value>

Speichert eine beliebige Zeichenfolge, die später mit load_string abgerufen werden kann.

load_string (veraltet)

load_string ist veraltet. Verwenden Sie stattdessen get_env.

load_string <key>

Gibt die Zeichenkette aus, die in gespeichert ist key.