Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Jobs in Deadline Cloud planen

Nachdem Sie einen Job erstellt haben, plant AWS Deadline Cloud, dass er in einer oder mehreren der Flotten bearbeitet wird, die einer Warteschlange zugeordnet sind. Die Flotte, die eine bestimmte Aufgabe verarbeitet, wird auf der Grundlage der Planungskonfiguration, der für die Flotte konfigurierten Funktionen und der Hostanforderungen eines bestimmten Schritts ausgewählt.

Die folgenden Abschnitte enthalten Einzelheiten zum Prozess der Auftragsplanung.

Konfigurationen planen

Sie können konfigurieren, wie Deadline Cloud Jobs in einer Warteschlange plant, indem Sie eine Planungskonfiguration für die Warteschlange einrichten. Die Planungskonfiguration steuert, wie die Mitarbeiter auf die Jobs verteilt werden.

Sie können die Planungskonfiguration mithilfe der Deadline Cloud-Konsole oder durch Aufrufen der UpdateQueue APIs CreateQueue oder festlegen.

Es gibt drei verfügbare Planungskonfigurationen:

In allen Planungskonfigurationen werden in Bearbeitung befindliche Aufgaben bis zum Abschluss ausgeführt, bevor eine neue Planungsentscheidung getroffen wird. Wenn Sie die Planungskonfiguration ändern, während Aufgaben ausgeführt werden, gilt die Änderung nur, wenn das nächste Mal Arbeitskräfte zugewiesen werden. Laufende Aufgaben werden nicht unterbrochen oder neu zugewiesen.

Priorität, zuerst rein, zuerst raus

Priority, first-in-first-out (priorityFifo) ist die Standard-Planungskonfiguration für neue Warteschlangen. Deadline Cloud weist die Mitarbeiter zuerst dem Job mit der höchsten Priorität zu. Wenn mehrere Jobs dieselbe Priorität haben, erhält der älteste (am frühesten eingereichte) Job alle verfügbaren Mitarbeiter zuerst.

Verwenden Sie die Prioritäts-FIFO, wenn Sie eine strikte Reihenfolge der Jobs wünschen. Diese Konfiguration ist geeignet, wenn Jobs nacheinander in der Reihenfolge abgeschlossen werden sollen, in der sie eingereicht wurden, z. B. sequentielle Pipeline-Phasen oder Stapelverarbeitung, bei der jeder Job abgeschlossen sein muss, bevor der nächste gestartet wird.

Diese Konfiguration hat keine zusätzlichen Parameter.

Priorität, ausgewogen

Priorität, ausgewogen (priorityBalanced) verteilt die Arbeitnehmer gleichmäßig auf alle Stellen auf der höchsten Prioritätsebene. Wenn nur ein Job mit der höchsten Priorität existiert, weist Deadline Cloud alle Mitarbeiter diesem Job zu. Wenn mehrere Jobs die höchste Priorität haben, werden die Mitarbeiter gleichmäßig auf sie aufgeteilt. Wenn die Arbeitnehmer nicht gleichmäßig aufgeteilt werden können, werden die zusätzlichen Arbeitskräfte auf die Stellen mit der höchsten Priorität aufgeteilt.

Verwenden Sie eine ausgewogene Prioritätsverteilung, wenn mehrere Künstler oder Benutzer Jobs mit derselben Priorität einreichen und jeder Benutzer sofortiges Feedback benötigt. Diese Konfiguration stellt sicher, dass kein einziger Job alle verfügbaren Mitarbeiter monopolisiert, sodass allen Benutzern kurz nach der Einreichung Mitarbeiter zugewiesen werden.

Wenn für einen Job weniger Aufgaben übrig sind als sein Anteil an Mitarbeitern, werden die überzähligen Arbeitskräfte auf andere Jobs mit derselben Prioritätsstufe umverteilt. Wenn alle Stellen mit der höchsten Priorität vollständig verteilt sind, werden überzählige Arbeitskräfte automatisch auf Stellen mit der nächsthöheren Prioritätsstufe verteilt.

Diese Konfiguration hat den folgenden Parameter:

Gewichtet, ausgewogen

Gewichtet, ausgewogen (weightedBalanced) verwendet eine Formel, um das Gewicht für jeden Job zu berechnen. Deadline Cloud weist die Mitarbeiter zuerst der Stelle mit dem höchsten Gewicht zu. Wenn mehrere Jobs das gleiche Gewicht haben, werden die Mitarbeiter auf sie verteilt.

Verwenden Sie „Gewichtet ausgewogen“, wenn Sie eine detaillierte Kontrolle darüber benötigen, wie Mitarbeiter auf Jobs mit unterschiedlichen Prioritäten, Fehlerquoten und Abgabezeiten verteilt werden. Diese Konfiguration eignet sich für komplexe Renderfarmumgebungen, in denen Sie das Gleichgewicht zwischen Auftragspriorität, Auftragsalter, Fehlerbehandlung und Mitarbeiterbindung anpassen möchten.

Das Gewicht für jeden Auftrag wird wie folgt berechnet:

weight = (job.Priority * priorityWeight) +
         (job.Errors * errorWeight) +
         ((currentTimeInSeconds - job.SubmissionTime) * submissionTimeWeight) +
         ((job.RenderingTasks - renderingTaskBuffer) * renderingTaskWeight)

Die renderingTaskBuffer Komponente wird nur angewendet, wenn die Arbeitskraft gerade an dem Job arbeitet. Der renderingTaskWeight wird in der Regel auf einen negativen Wert gesetzt, sodass Jobs mit zugewiesenen Arbeitskräften ein geringeres Gewicht erhalten und andere Jobs in der Warteschlange an erster Stelle stehen. Der errorWeight ist in der Regel ebenfalls negativ, sodass Jobs mit Fehlern nicht mehr priorisiert werden. Sie können Zeitplanüberschreibungen für Jobs mit minimaler und maximaler Priorität verwenden.

Diese Konfiguration hat die folgenden Parameter:

Ermitteln Sie die Kompatibilität Ihrer Flotte

Warteschlangen und Flotten teilen die Arbeit bei Routing-Aufträgen auf. Eine Warteschlange organisiert Jobs und kontrolliert, wer sie einreichen und einsehen kann. Die Flotten- und Hostanforderungen bestimmen, welche Mitarbeiter die einzelnen Schritte ausführen.

Um bestimmte Mitarbeiter bestimmten Aufgaben zuzuweisen, erstellen Sie eine separate Flotte für diese Mitarbeiter anstelle einer separaten Warteschlange. Verwenden Sie beispielsweise eine separate Flotte für Maschinen mit bestimmter Hardware oder für Maschinen, die für vertrauliche Inhalte reserviert sind. Eine Warteschlange kann mehreren Flotten zugeordnet werden, und die Hostanforderungen jedes Schritts wählen eine kompatible Flotte aus. Wenn der 10. Stichtag abgelaufen ist, ersetzen Flotten- und Hostanforderungen die Arbeitergruppen. Die vollständige Konzeptübersicht finden Sie unterMigrieren Sie von Deadline 10 zu AWS Deadline Cloud.

Nachdem Sie einen Job erstellt haben, vergleicht Deadline Cloud die Hostanforderungen für jeden Schritt im Job mit den Fähigkeiten der Flotten, die der Warteschlange zugeordnet sind, an die der Job weitergeleitet wurde. Wenn eine Flotte die Host-Anforderungen erfüllt, wird der Job in den READY Status versetzt.

Wenn für einen Schritt des Jobs Anforderungen gelten, die von einer Flotte, die der Warteschlange zugeordnet ist, nicht erfüllt werden können, wird der Status des Schritts auf gesetztNOT_COMPATIBLE. Darüber hinaus werden die übrigen Schritte des Jobs storniert. Wenn Sie der Warteschlange später eine kompatible Flotte zuordnen, werden vorhandene NOT_COMPATIBLE Jobs nicht automatisch neu gestartet. Um sie auszuführen, stellen Sie sie in die Warteschlange ein. Weitere Informationen finden Sie unter Einen Job in Deadline Cloud ändern.

Die Funktionen für eine Flotte werden auf Flottenebene festgelegt. Selbst wenn ein Mitarbeiter in einer Flotte die Anforderungen des Jobs erfüllt, werden ihm keine Aufgaben aus dem Auftrag zugewiesen, wenn sein Fuhrpark die Anforderungen des Jobs nicht erfüllt.

Die folgende Jobvorlage enthält einen Schritt, der die Hostanforderungen für den Schritt spezifiziert:

name: Sample Job With Host Requirements
specificationVersion: jobtemplate-2023-09
steps:
- name: Step 1
  script:
    actions:
      onRun:
        args:
        - '1'
        command: /usr/bin/sleep
  hostRequirements:
    amounts:
    # Capabilities starting with "amount." are amount capabilities. If they start with "amount.worker.",
    # they are defined by the OpenJD specification. Other names are free for custom usage.
    - name: amount.worker.vcpu
      min: 4
      max: 8
    attributes:
    - name: attr.worker.os.family
      anyOf:
      - linux

Die Einreicher legen dieselben Anforderungen auf der Registerkarte „Anforderungen für den Gastgeber“ fest. Wählen Sie Auf Worker-Hosts ausführen, die die folgenden Anforderungen erfüllen, um ein Betriebssystem, eine CPU-Architektur und Hardwarebereiche festzulegen, ohne die Vorlage zu bearbeiten.

Dieser Job kann für eine Flotte mit den folgenden Funktionen geplant werden:

{
    "vCpuCount": {"min": 4, "max": 8},
    "memoryMiB": {"min": 1024},
    "osFamily": "linux",
    "cpuArchitectureType": "x86_64"
}

Dieser Job kann nicht für eine Flotte mit einer der folgenden Funktionen geplant werden:

{
    "vCpuCount": {"min": 4},
    "memoryMiB": {"min": 1024},
    "osFamily": "linux",
    "cpuArchitectureType": "x86_64"
}
    The vCpuCount has no maximum, so it exceeds the maximum vCPU host requirement.
    
{
    "vCpuCount": {"max": 8},
    "memoryMiB": {"min": 1024},
    "osFamily": "linux",
    "cpuArchitectureType": "x86_64"
}
    The vCpuCount has no minimum, so it doesn't satisfy the minimum vCPU host requirement.

{
    "vCpuCount": {"min": 4, "max": 8},
    "memoryMiB": {"min": 1024},
    "osFamily": "windows",
    "cpuArchitectureType": "x86_64"
}    
    The osFamily doesn't match.

Bewährte Methoden beim Flottendesign

Da der Planer die Kompatibilität auf Flottenebene bewertet, sollten Sie Ihre vom Kunden verwalteten Flotten so gestalten, dass die angegebenen Mindestanforderungen an die Ausstattung aller Mitarbeiter der Flotte workerCapabilities entsprechen:

Wenn Sie beispielsweise Worker mit 1 GPU (24 GiB VRAM) und Worker mit 4 GPUs (96 GiB VRAM) haben, erstellen Sie zwei separate Flotten: eine, die mindestens 1 GPU und 24 GiB GPU-Speicher deklariert, und eine andere, die mindestens 4 GPUs und 96 GiB GPU-Speicher deklariert. Ordnen Sie dann beide Flotten derselben Warteschlange zu. Schritte, für die 4 GPUs erforderlich sind, werden automatisch an die Flotte mit vielen GPUs weitergeleitet.

Weitere Informationen zum Erstellen einer vom Kunden verwalteten Flotte finden Sie unter. Erstellen Sie eine vom Kunden verwaltete Flotte

Benutzerdefinierte Funktionen

Zusätzlich zu den integrierten Worker-Funktionen (vCPU, Arbeitsspeicher, GPU, Betriebssystem und CPU-Architektur) können Sie benutzerdefinierte Mengen und benutzerdefinierte Attribute für eine Flotte definieren, um zusätzlichen Planungseinschränkungen Rechnung zu tragen:

Deklarieren Sie Software- oder Hardwarekombinationen auf Flottenebene nur dann als benutzerdefinierte Funktionen, wenn gewährleistet ist, dass sie bei allen Mitarbeitern in dieser Flotte vorhanden sind.

Fleet-level Für benutzerdefinierte Funktionen gelten die folgenden Einschränkungen:

Namen im Formular amount.worker.* und attr.worker.* sind vom Service für integrierte Funktionen reserviert. Verwenden Sie andere Präfixe für Ihre benutzerdefinierten Funktionen.

Das folgende Beispiel leitet Schritte, die einen bestimmten Solver benötigen, an die Flotte weiter, die ihn bereitstellt. Die Flotte deklariert die Solver, die auf allen ihren Workern installiert sind, in einem benutzerdefinierten Attribut. Diese Flottenkonfiguration ist Teil der CreateFleet Anfrage:

"workerCapabilities": {
    "vCpuCount": {"min": 4},
    "memoryMiB": {"min": 16384},
    "osFamily": "linux",
    "cpuArchitectureType": "x86_64",
    "customAttributes": [
        {
            "name": "attr.sw.solvers",
            "values": ["vray-6", "arnold-7"]
        }
    ]
}

Ein Schritt, der einen der deklarierten Werte erfordert, gibt die Anforderung hostRequirements in der Jobvorlage an:

steps:
- name: RenderWithVray
  hostRequirements:
    attributes:
    - name: attr.sw.solvers
      anyOf:
      - vray-6
  script:
    actions:
      onRun:
        command: '{{Task.File.Render}}'

Durch die Anforderung wird der RenderWithVray Schritt von Flotten ferngehalten, die keine Angaben machen. vray-6 Umgekehrt gilt dies nicht: Ein Schritt, für den keine attr.sw.solvers Anforderung gilt, ist immer noch mit dieser Flotte kompatibel und kann für sie geplant werden.

Weitere Informationen zur Konfiguration benutzerdefinierter Funktionen beim Erstellen einer Flotte finden Sie unterErstellen Sie eine vom Kunden verwaltete Flotte.

GPU-Speicherberichterstattung

Wenn Sie Flotten für GPU-intensive Workloads konfigurieren, die einen bestimmten VRAM-Schwellenwert pro GPU erfordern, sollten Sie wissen, wie der Worker Agent den GPU-Speicher meldet.

Der Deadline Cloud-Worker-Agent meldet den minimalen GPU-Speicher aller GPUs auf dem Worker anamount.worker.gpu.memory, nicht die Gesamtsumme. Dieses Verhalten stellt sicher, dass Jobs, die eine bestimmte VRAM-Menge pro GPU erfordern, an Worker weitergeleitet werden, bei denen jede GPU diese Anforderung erfüllt.

Wenn ein Worker beispielsweise zwei GPUs mit 24 GiB bzw. 48 GiB VRAM hat, meldet der Worker Agent 24 GiB als GPU-Speicherwert.

Stellen Sie auf Flottenebene das acceleratorTotalMemoryMiB Minimum auf den niedrigsten VRAM pro GPU ein, den jeder Mitarbeiter in der Flotte garantiert hat.

Per-worker Fähigkeiten

Wenn Sie den Betriebsstatus einzelner Mitarbeiter verfolgen müssen, ohne dass dies Auswirkungen auf Planungsentscheidungen hat, nutzen Sie die Funktionen pro Mitarbeiter. Sie können beispielsweise Mitarbeiter für Wartungsarbeiten kennzeichnen, den Status der Softwareeinführung verfolgen oder Indikatoren für Gesundheitschecks aufzeichnen.

Mithilfe des UpdateWorker API-Vorgangs können Sie Funktionen für einzelne Mitarbeiter einrichten. Per-worker Funktionen werden nicht als Planungsvertrag verwendet. Der Scheduler bewertet die Kompatibilität ausschließlich anhand der Deklaration auf workerCapabilities Flottenebene.

Die ListWorkers Operationen GetWorker und geben keine Worker-Fähigkeiten zurück, die durchgesetzt wurden. UpdateWorker

Weitere Informationen finden Sie UpdateWorker in der Deadline Cloud API-Referenz.

Zugriffskontrolle und Mitarbeiterauswahl

Deadline Cloud unterscheidet, wer eine Ressource verwenden kann, vom Ort, an dem Jobs ausgeführt werden. IAM-Richtlinien sowie AWS IAM Identity Center Benutzer- und Gruppenmitgliedschaften steuern, wer eine Farm, Warteschlange oder Flotte einsehen, an sie senden und verwalten kann. Warteschlange — Flottenzuordnungen und Host-Anforderungen steuern, welche Mitarbeiter die einzelnen Jobs ausführen.

Die Gruppenzugehörigkeit zu einer Flotte ermöglicht es den Mitarbeitern, diese Flotte im Monitor einzusehen und zu verwalten. Durch die Mitgliedschaft werden Aufträge nicht an die Flotte weitergeleitet oder Aufträge von ihr ferngehalten. Verwenden Sie Verbindungen zwischen Warteschlangen und Flotten, um die Arbeit an einen Fuhrpark weiterzuleiten oder von diesem wegzuleiten.

Die Anforderungen des Gastgebers sind Teil der Stellenvorlage, sodass jeder, der die Stelle einreicht, sie auswählt. Sie leiten die Arbeit an fähige Flotten weiter und stellen keine Zugangskontrolle dar. Die Zuordnung zwischen Warteschlange und Flotte ist der Durchsetzungspunkt: Der Dienst plant einen Schritt nur für die Flotten ein, die in der Warteschlange des Auftrags stehen, unabhängig von den Anforderungen des Hosts. Um zu verhindern, dass eine Flotte mit eingeschränktem Zugriff bearbeitet wird, ordnen Sie die Flotte nur begrenzten Warteschlangen zu und kontrollieren Sie, wer sich diesen Warteschlangen unterwerfen kann. Weitere Informationen zu den Sicherheitsgrenzen zwischen Warteschlangen und Flotten, die sich Mitarbeiter teilen, finden Sie unter. Isolieren Sie Workloads anhand von Farmen, Flotten und Warteschlangen

Skalierung der Flotte

Wenn ein Auftrag einer kompatiblen, vom Service verwalteten Flotte zugewiesen wird, wird die Flotte automatisch skaliert. Die Anzahl der Mitarbeiter in der Flotte ändert sich je nach der Anzahl der Aufgaben, die der Flotte zur Verfügung stehen.

Wenn ein Auftrag einer vom Kunden verwalteten Flotte zugewiesen wird, sind möglicherweise bereits Mitarbeiter vorhanden oder können mithilfe der ereignisbasierten automatischen Skalierung neu erstellt werden. Weitere Informationen finden Sie unter EventBridge Zur Behandlung von Auto Scaling-Ereignissen verwenden im Amazon EC2 Auto Scaling-Benutzerhandbuch.

Sitzungen

Die Aufgaben in einem Job sind in eine oder mehrere Sitzungen aufgeteilt. Die Mitarbeiter führen die Sitzungen aus, um die Umgebung einzurichten, die Aufgaben auszuführen und dann die Umgebung abzubauen. Jede Sitzung besteht aus einer oder mehreren Aktionen, die ein Mitarbeiter ausführen muss.

Wenn ein Worker die Aktionen eines Abschnitts abschließt, können weitere Sitzungsaktionen an den Worker gesendet werden. Der Mitarbeiter verwendet in der Sitzung vorhandene Umgebungen und Auftragsanhänge erneut, um Aufgaben effizienter zu erledigen.

Bei Flottenarbeitern mit Serviceverwaltung werden Sitzungsverzeichnisse nach Ende der Sitzung gelöscht, andere Verzeichnisse bleiben jedoch zwischen den Sitzungen erhalten. Dieses Verhalten ermöglicht es Ihnen, Caching-Strategien für Daten zu implementieren, die in mehreren Sitzungen wiederverwendet werden können. Um Daten zwischen Sitzungen zwischenzuspeichern, speichern Sie sie im Home-Verzeichnis des Benutzers, der den Job ausführt. Conda-Pakete werden beispielsweise im Home-Verzeichnis des Jobbenutzers unter C:\Users\job-user\.conda-pkgs on Windows workers und /home/job-user/.conda-pkgs on Linux workers zwischengespeichert. Diese Daten bleiben verfügbar, bis der Worker herunterfährt.

Jobanhänge werden vom Absender erstellt, den Sie als Teil Ihres Deadline Cloud CLI-Jobpakets verwenden. Sie können Jobanhänge auch mithilfe der --attachments Option für den create-job AWS CLI Befehl erstellen. Umgebungen werden an zwei Stellen definiert: Warteschlangenumgebungen, die an eine bestimmte Warteschlange angehängt sind, und Job- und Schrittumgebungen, die in der Jobvorlage definiert sind.

Es gibt vier Arten von Sitzungsaktionen:

Die folgende Jobvorlage enthält eine Step-Umgebung. Sie enthält eine onEnter Definition zum Einrichten der Schrittumgebung, eine onRun Definition, die die auszuführende Aufgabe definiert, und eine onExit Definition zum Abbau der Schrittumgebung. Die für diesen Job erstellten Sitzungen enthalten eine envEnter Aktion, eine oder mehrere taskRun Aktionen und dann eine envExit Aktion.

name: Sample Job with Maya Environment
specificationVersion: jobtemplate-2023-09
steps:
- name: Maya Step
  stepEnvironments:
  - name: Maya
    description: Runs Maya in the background.
    script:
      embeddedFiles:
      - name: initData
        filename: init-data.yaml
        type: TEXT
        data: |
          scene_file: MyAwesomeSceneFile
          renderer: arnold
          camera: persp
      actions:
        onEnter:
          command: MayaAdaptor
          args:
          - daemon
          - start
          - --init-data
          - file://{{Env.File.initData}}
        onExit:
          command: MayaAdaptor
          args:
          - daemon
          - stop
  parameterSpace:
    taskParameterDefinitions:
    - name: Frame
      range: 1-5
      type: INT
  script:
    embeddedFiles:
    - name: runData
      filename: run-data.yaml
      type: TEXT
      data: |
        frame: {{Task.Param.Frame}}
    actions:
      onRun:
        command: MayaAdaptor
        args:
        - daemon
        - run
        - --run-data
        - file://{{ Task.File.runData }}

Pipelining von Sitzungsaktionen

Durch das Pipelining von Sitzungsaktionen kann ein Planer einem Worker mehrere Sitzungsaktionen vorab zuweisen. Der Worker kann diese Aktionen dann nacheinander ausführen, wodurch die Leerlaufzeiten zwischen den Aufgaben reduziert oder vermieden werden.

Um eine erste Aufgabe zu erstellen, erstellt der Scheduler eine Sitzung mit einer Aufgabe, der Mitarbeiter schließt die Aufgabe ab, und dann analysiert der Scheduler die Aufgabendauer, um zukünftige Zuweisungen zu ermitteln.

Damit der Scheduler effektiv ist, gibt es Regeln für die Dauer der Aufgaben. Für Aufgaben unter einer Minute verwendet der Scheduler ein Power-of-2-Wachstumsmuster. Bei einer Aufgabe von 1 Sekunde weist der Scheduler beispielsweise 2 neue Aufgaben zu, dann 4, dann 8. Bei Aufgaben, die länger als eine Minute dauern, weist der Scheduler nur eine neue Aufgabe zu und das Pipelining bleibt deaktiviert.

Um die Pipeline-Größe zu berechnen, geht der Scheduler wie folgt vor:

Durch das Pipelining von Sitzungsaktionen beginnen Mitarbeiter sofort mit neuen Aufgaben, und es gibt keine Wartezeiten zwischen Anfragen des Zeitplaners. Es sorgt auch für eine höhere Effizienz der Mitarbeiter und eine bessere Aufgabenverteilung bei lang andauernden Prozessen.

Wenn eine neue Aufgabe mit höherer Priorität verfügbar ist, beendet die Arbeitskraft außerdem alle ihr zuvor zugewiesenen Arbeiten, bevor die aktuelle Sitzung endet und eine neue Sitzung aus einer Aufgabe mit höherer Priorität zugewiesen wird.

Abhängigkeiten zwischen den einzelnen Schritten

Deadline Cloud unterstützt die Definition von Abhängigkeiten zwischen Schritten, sodass ein Schritt wartet, bis ein anderer Schritt abgeschlossen ist, bevor er beginnt. Sie können mehr als eine Abhängigkeit für einen Schritt definieren. Ein Schritt mit einer Abhängigkeit wird erst geplant, wenn alle Abhängigkeiten abgeschlossen sind.

Wenn die Jobvorlage eine zirkuläre Abhängigkeit definiert, wird der Job abgelehnt und der Jobstatus auf gesetztCREATE_FAILED.

Die folgende Jobvorlage erstellt einen Job in zwei Schritten. StepBhängt davon abStepA. StepBläuft erst nach erfolgreichem StepA Abschluss.

Nachdem der Job erstellt wurde, StepA befindet er sich im READY Status und StepB befindet sich im PENDING Bundesstaat. StepAZieht nach StepB Abschluss in den READY Staat. StepASchlägt dies fehl oder StepA wird der Vorgang abgebrochen, StepB wechselt er in den CANCELED Bundesstaat.

Sie können eine Abhängigkeit von mehreren Schritten festlegen. StepCHängt beispielsweise von beiden Schritten ab StepA und beginnt StepC erstStepB, wenn die anderen beiden Schritte abgeschlossen sind.

Für Abhängigkeiten von Schritten gelten die folgenden Einschränkungen:

name: Step-Step Dependency Test
specificationVersion: 'jobtemplate-2023-09'
steps:
- name: A
  script:
    actions:
      onRun:
        command: bash
        args: ['{{ Task.File.run }}']
    embeddedFiles:
      - name: run
        type: TEXT
        data: |
          #!/bin/env bash

          set -euo pipefail

          sleep 1
          echo Task A Done!
- name: B
  dependencies:
  - dependsOn: A # This means Step B depends on Step A
  script:
    actions:
      onRun:
        command: bash
        args: ['{{ Task.File.run }}']
    embeddedFiles:
      - name: run
        type: TEXT
        data: |
          #!/bin/env bash

          set -euo pipefail

          sleep 1
          echo Task B Done!