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.
Konfiguration des Warteschlangenverhaltens von Läufen
Wenn in Amazon CodeCatalyst mehrere Workflow-Ausführungen gleichzeitig ausgeführt werden, werden sie standardmäßig in eine CodeCatalyst Warteschlange gestellt und nacheinander in der Reihenfolge verarbeitet, in der sie gestartet wurden. Sie können dieses Standardverhalten ändern, indem Sie einen Ausführungsmodus angeben. Es gibt einige Ausführungsmodi:
-
(Standard) Ausführungsmodus in Warteschlange — CodeCatalyst Prozesse werden nacheinander ausgeführt
-
Ersetzter Ausführungsmodus — CodeCatalyst Prozesse werden nacheinander ausgeführt, wobei neuere Läufe ältere überholen
-
Parallellauffunktion — CodeCatalyst Prozesse laufen parallel
Weitere Hinweise zu Workflow-Ausführungen finden Sie unterEinen Workflow ausführen.
Themen
Informationen zum Ausführungsmodus in der Warteschlange
Im Modus „Ausführung in der Warteschlange“ werden Läufe nacheinander ausgeführt, wobei Warteläufe eine Warteschlange bilden.
Warteschlangen bilden sich an den Eintrittspunkten zu Aktionen und Aktionsgruppen, sodass Sie mehrere Warteschlangen innerhalb desselben Workflows haben können (siehe). Figure 1 Wenn ein Lauf in der Warteschlange in eine Aktion aufgenommen wird, ist die Aktion gesperrt und es können keine weiteren Läufe mehr hinzugefügt werden. Wenn der Lauf abgeschlossen ist und die Aktion beendet wird, wird die Aktion entsperrt und ist bereit für den nächsten Lauf.
Figure 1veranschaulicht einen Workflow, der im Ausführungsmodus in der Warteschlange konfiguriert ist. Sie zeigt folgende Informationen an:
-
Sieben Läufe arbeiten sich ihren Weg durch den Workflow.
-
Zwei Warteschlangen: eine außerhalb des Eingangs zur Eingabequelle (repo:Main) und eine außerhalb des Eingangs zur Aktion. BuildTestActionGroup
-
Zwei gesperrte Blöcke: die Eingangsquelle (repo:Main) und der. BuildTestActionGroup
So werden sich die Dinge entwickeln, wenn der Workflow läuft und die Verarbeitung abgeschlossen ist:
-
Wenn Run-4D444 das Klonen des Quell-Repositorys abgeschlossen hat, verlässt es die Eingabequelle und tritt der Warteschlange hinter Run-3c333 bei. Dann wird Run-5e555 die Eingabequelle aufrufen.
-
Wenn Run-1a111 mit dem Erstellen und Testen fertig ist, wird die Aktion beendet und die Aktion gestartet. BuildTestActionGroupDeployAction Dann wird Run-2b222 die Aktion starten. BuildTestActionGroup
Abbildung 1: Ein Workflow, der im Modus „Ausführung in der Warteschlange“ konfiguriert ist
Verwenden Sie den Ausführungsmodus in der Warteschlange, wenn:
-
Sie möchten eine one-to-one Beziehung zwischen Features und Läufen beibehalten — diese Features können gruppiert werden, wenn der Modus „Ersetzt“ verwendet wird. Wenn Sie beispielsweise Feature 1 in Commit 1 zusammenführen, wird Lauf 1 gestartet, und wenn Sie Feature 2 in Commit 2 zusammenführen, startet Lauf 2 usw. Wenn Sie den abgelösten Modus anstelle des Warteschlangenmodus verwenden würden, werden Ihre Features (und Commits) in der Ausführung gruppiert, die die anderen ersetzt.
-
Sie möchten Rennbedingungen und unerwartete Probleme vermeiden, die bei der Verwendung des Parallelmodus auftreten können. Wenn beispielsweise zwei Softwareentwickler, Wang und Saanvi, die Workflow-Ausführung ungefähr zur gleichen Zeit starten, um sie in einem ECS Amazon-Cluster bereitzustellen, kann Wangs Lauf Integrationstests auf dem Cluster beginnen, während der Lauf von Saanvi neuen Anwendungscode für den Cluster bereitstellt, was dazu führt, dass Wangs Tests entweder fehlschlagen oder den falschen Code testen. Ein weiteres Beispiel könnte sein, dass Sie ein Ziel haben, das keinen Sperrmechanismus hat. In diesem Fall könnten die beiden Läufe die Änderungen des jeweils anderen auf unerwartete Weise überschreiben.
-
Sie möchten die Belastung der Rechenressourcen begrenzen, die für die Verarbeitung Ihrer Läufe CodeCatalyst verwendet werden. Wenn Sie beispielsweise drei Aktionen in Ihrem Workflow haben, können Sie maximal drei Läufe gleichzeitig ausführen lassen. Wenn die Anzahl der Durchläufe, die gleichzeitig ausgeführt werden können, begrenzt wird, lässt sich der Durchsatz der Durchläufe besser vorhersagen.
-
Sie möchten die Anzahl der Anfragen einschränken, die der Workflow an Dienste von Drittanbietern stellt. Ihr Workflow könnte beispielsweise eine Build-Aktion enthalten, die Anweisungen zum Abrufen eines Images aus Docker Hub enthält. Docker Hub begrenzt die Anzahl der Pull-Anfragen
, die Sie stellen können, auf eine bestimmte Anzahl pro Stunde und Konto. Wenn Sie das Limit überschreiten, werden Sie gesperrt. Wenn Sie den Ausführungsmodus in der Warteschlange verwenden, um Ihren Durchsatz zu verlangsamen, werden weniger Anfragen an Docker Hub pro Stunde generiert, wodurch das Potenzial für Sperrungen und daraus resultierende Build- und Run-Fehler begrenzt wird.
Maximale Warteschlangengröße: 50
Hinweise zur maximalen Warteschlangengröße:
-
Die maximale Warteschlangengröße bezieht sich auf die maximale Anzahl von Durchläufen, die in allen Warteschlangen im Workflow zulässig sind.
-
Wenn eine Warteschlange länger als 50 Läufe wird CodeCatalyst , werden die 51. und die nachfolgenden Läufe gelöscht.
Verhalten bei Fehlern:
Wenn ein Lauf nicht mehr reagiert, während er durch eine Aktion verarbeitet wird, werden die dahinter stehenden Läufe in der Warteschlange zurückgehalten, bis die Aktion das Timeout erreicht. Bei Aktionen läuft das Timeout nach einer Stunde ab.
Wenn ein Lauf innerhalb einer Aktion fehlschlägt, darf der erste Lauf, der sich dahinter in der Warteschlange befindet, fortgesetzt werden.
Über den abgelösten Ausführungsmodus
Der abgelöste Ausführungsmodus entspricht dem Ausführungsmodus in der Warteschlange, mit der Ausnahme, dass:
-
Wenn ein Lauf in der Warteschlange einen anderen Lauf in der Warteschlange einholt, ersetzt (übernimmt) der spätere Lauf den früheren Lauf, und der frühere Lauf wird abgebrochen und als „ersetzt“ markiert.
-
Aufgrund des im ersten Punkt beschriebenen Verhaltens kann eine Warteschlange nur einen Lauf enthalten, wenn der Modus „Ersetzte Ausführung“ verwendet wird.
Wenn Sie den Arbeitsablauf Figure 1 als Leitfaden verwenden, würde die Anwendung des ersetzten Ausführungsmodus auf diesen Workflow zu folgenden Ergebnissen führen:
-
Run-7g777 würde die anderen beiden Läufe in der Warteschlange ersetzen und wäre der einzige in Warteschlange #1 verbleibende Lauf. Run-6F666 und Run-5E555 würden abgebrochen.
-
Run-3c333 würde Run-2b222 ersetzen und wäre der einzige verbleibende Lauf in Warteschlange #2. Run-2b222 würde abgebrochen werden.
Verwenden Sie den abgelösten Ausführungsmodus, wenn Sie:
-
besserer Durchsatz als im Warteschlangenmodus
-
noch weniger Anfragen an Dienste von Drittanbietern als im Warteschlangenmodus; dies ist vorteilhaft, wenn für den Drittanbieter-Service Ratenbegrenzungen gelten, wie z. B. Docker Hub
Über den Parallellaufmodus
Im Parallellaufmodus sind Läufe unabhängig voneinander und warten nicht, bis andere Läufe abgeschlossen sind, bevor sie gestartet werden. Es gibt keine Warteschlangen, und der Durchsatz der Ausführung wird nur dadurch begrenzt, wie schnell die Aktionen innerhalb des Workflows abgeschlossen werden.
Verwenden Sie den parallel Ausführungsmodus in Entwicklungsumgebungen, in denen jeder Benutzer seinen eigenen Feature-Branch hat und auf Zielen bereitgestellt wird, die nicht von anderen Benutzern gemeinsam genutzt werden.
Wichtig
Wenn Sie ein gemeinsames Ziel haben, für das mehrere Benutzer bereitstellen können, z. B. eine Lambda-Funktion in einer Produktionsumgebung, verwenden Sie den Parallelmodus nicht, da dies zu Rennbedingungen führen kann. Eine Race-Condition tritt auf, wenn parallel Workflow-Läufe versuchen, eine gemeinsam genutzte Ressource gleichzeitig zu ändern, was zu unvorhersehbaren Ergebnissen führt.
Maximale Anzahl parallel Läufe: 1000 pro CodeCatalyst Feld
Konfiguration des Ausführungsmodus
Sie können den Ausführungsmodus auf „In Warteschlange“, „Ersetzt“ oder „Parallel“ setzen. Die Standardeinstellung ist in der Warteschlange.
Wenn Sie den Ausführungsmodus von „In Warteschlange“ oder „ersetzt“ in „Parallel“ ändern, werden die Läufe in der Warteschlange CodeCatalyst abgebrochen und die Läufe, die derzeit von einer Aktion verarbeitet werden, beendet, bevor sie abgebrochen werden.
Wenn Sie den Ausführungsmodus von „Parallel“ in „In Warteschlange gestellt“ oder „ersetzt“ ändern, werden alle derzeit laufenden parallel CodeCatalyst Läufe abgeschlossen. Alle Läufe, die Sie starten, nachdem Sie den Ausführungsmodus in Warteschlange oder ersetzt geändert haben, verwenden den neuen Modus.
