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.

Arbeitsabläufe

Transformationen ausführen

In diesem Abschnitt werden die verschiedenen Methoden zur Ausführung von Transformationen und Optionen zur Steuerung des Ausführungsverhaltens beschrieben.

Ausführungsmodi

AWS Transform custom unterstützt drei Ausführungsmodi für unterschiedliche Workflows.

Interaktiver Konversationsmodus

Starten Sie die CLI mit atx und bitten Sie den Agenten, eine Transformation in natürlicher Sprache auszuführen. In diesem Modus können Sie eine vollständige Konversation mit dem Agenten führen, die Ausführung jederzeit unterbrechen und während des Transformationsprozesses Feedback geben.

Verwenden Sie diesen Modus, wenn Sie maximale Kontrolle und die Möglichkeit haben möchten, den Agenten durch komplexe Szenarien zu führen.

Direkte interaktive Ausführung

Wird verwendetatx custom def exec -n <transformation-name> -p <path>, um eine bestimmte Transformation interaktiv zu starten. In diesem Modus können Sie den Agenten zu Beginn, während oder am Ende der Ausführung überprüfen und mit ihm interagieren. Der Agent wird an wichtigen Entscheidungspunkten eine Pause einlegen und Sie um Ihr Feedback bitten.

Dies ist ideal, um Transformationen zu testen und zu verfeinern, bevor sie autonom ausgeführt werden.

Sie können Transformationen im nicht interaktiven Modus oder im Headless-Modus ausführen. Non-interactive Der Modus unterdrückt Eingabeaufforderungen während einer benannten Transformation. Im Headless-Modus können Sie den Agenten mit einer Klartext-Aufforderung ausführen, wodurch die interaktive Oberfläche vollständig umgangen wird.

Non-interactive Modus

atx custom def exec -n <transformation-name> -p <path> -x -tFür die vollständige Automatisierung verwenden. Fügen Sie -x diese Option hinzu, um sie im nicht interaktiven Modus auszuführen und -t alle Tools automatisch und ohne Aufforderung als vertrauenswürdig einzustufen.

Dieser Modus ist für die CI/CD Pipeline-Integration und die Massenausführung konzipiert, wenn kein menschliches Eingreifen möglich oder gewünscht ist.

Kopfloser Modus

Um Aufgaben zu erledigen, ohne mit dem Agenten zu interagieren, führen Sie die Anweisungen aus atx -x "<prompt>" -t und geben Sie sie im Klartext ein.

Ausführung der Transformation ohne Kopf

Verwenden Sie diesen Modus, um eine bestehende Transformationsdefinition auf Ihre Codebasis anzuwenden. Die Transformation führt jeden Schritt automatisch aus, ohne dass Ihre Zustimmung erforderlich ist.

atx -x "apply transformation definition <transformation_definition_name> to <codebase_path>" -t

Transformationsentwicklung ohne Kopf

Transformationsdefinitionen erstellen oder ändern.

Führen Sie den folgenden Befehl aus, um eine ältere Transformationsdefinition in das neue Skillformat (SKILL.md + References/) zu konvertieren:

atx -x "convert <legacy_transformation_definition_name> transformation definition to skill and save as draft" -t

Führen Sie den folgenden Befehl aus, um eine neue Transformationsdefinition zu erstellen:

atx -x "create a transformation definition to <description> with references docs <reference_docs_path>" -t

Allgemeine Befehls-Flags

Bei der Ausführung von Transformationen mit atx custom def exec werden häufig die folgenden Flags verwendet:

Verwendung von Konfigurationsdateien

AWS Transform custom unterstützt optionale Konfigurationsdateien im YAML- oder JSON-Format. Mit Konfigurationsdateien können Sie Ausführungsparameter angeben und dem Agenten zusätzlichen Kontext zur Verfügung stellen.

Um eine Konfigurationsdatei zu verwenden:

atx custom def exec --configuration file://config.yaml

Sie können die Konfiguration auch als Inline-Schlüssel-Wert-Paare bereitstellen:

atx custom def exec --configuration "key=value,key2=value2"

Beispiel für eine Konfigurationsdatei (config.yaml):

codeRepositoryPath: ./my-project
transformationName: my-transformation
buildCommand: mvn clean install
additionalPlanContext: |
  The target Java version to upgrade to is Java 17.
  Ensure compatibility with our internal logging framework version 2.3.
validationCommands: |
  mvn test
  mvn verify

Der additionalPlanContext Parameter bietet zusätzlichen Kontext für den Ausführungsplan des Agenten. Dies ist besonders nützlich bei AWS-verwalteten Transformationen, um ihr Verhalten an Ihre spezifischen Bedürfnisse anzupassen.

Befehle zum Erstellen und Überprüfen

Der Build- oder Validierungsbefehl ist ein optionaler Parameter, der angibt, wie Ihr Code während des Transformationsprozesses validiert werden soll. AWS Transform custom versucht, auf der Grundlage der Transformation den besten Build-Befehl abzuleiten, falls dieser nicht angegeben wurde. Es wird jedoch empfohlen, aus Qualitätsgründen spezifisch zu sein.

Beispiele für Build- und Validierungsbefehle:

Selbst für Sprachen oder Transformationen, die nicht erstellt werden müssen, ist es sehr wichtig, einen Befehl bereitzustellen, der die Ergebnisse validiert und Probleme zurückgibt, wenn die Überprüfung fehlschlägt, um die Transformationsqualität zu verbessern.

Wenn kein Build oder keine Validierung erforderlich ist, lassen Sie ihn in Ihrer Eingabe weg.

Steuerung des Lernverhaltens

Standardmäßig extrahiert AWS Transform custom Lektionen aus jeder Transformationsausführung. Sie können das Lernen für bestimmte Ausführungen verhindern.

Um zu verhindern, dass aus einer Ausführung gelernt wird:

atx custom def exec -n my-transformation -p ./my-project -d

Das --do-not-learn Kennzeichen -d oder verhindert das Extrahieren von Lektionen aus der aktuellen Ausführung.

Konversationen werden wieder aufgenommen

AWS Mit „Benutzerdefiniert transformieren“ können Sie frühere Konversationen innerhalb von 30 Tagen nach der Erstellung wieder aufnehmen.

So setzen Sie die letzte Konversation fort:

atx --resume

Um eine bestimmte Konversation wieder aufzunehmen:

atx --conversation-id <conversation-id>

Verfolgen von Agentenminuten

AWS Mit Transform Custom werden die während einer Transformationssitzung verbrauchten Agentenminuten nachverfolgt. Die Minuten der Agenten sammeln sich während des gesamten Konversationszyklus an und werden angezeigt, wenn die Konversation beendet ist:

Agent minutes used: 12.50

Die Minuten der Agenten bleiben auch nach Unterbrechungen bestehen. Wenn Sie eine Sitzung mit Strg+C unterbrechen und später wieder aufnehmen, werden die zuvor gesammelten Minuten übernommen und sammeln sich weiterhin in der wiederaufgenommenen Sitzung an.

Gehen Sie wie folgt vor, um die Agentenminuten während einer interaktiven Sitzung zu überprüfen:

Geben Sie /usage an der Eingabeaufforderung ein, um die aktuell gesammelten Agentenminuten anzuzeigen, ohne die Konversation zu beenden.

So legen Sie ein Budgetlimit für Agentenminuten fest:

atx custom def exec -n my-transformation -p ./my-project --limit 30

Die --limit Option legt ein maximales Budget für Agentenminuten für die Sitzung fest. Die Agentenminuten spiegeln die aktive Arbeitszeit der Agenten wider, nicht die Uhrzeit rund um die Uhr. Wenn das Limit erreicht ist, zeigt die CLI eine Meldung an und wird mit Anweisungen zum Fortfahren beendet:

⚠️ Budget limit reached: 30.00 / 30.00 Agent Minutes. Exiting.

Sie können die Konversation später mit einem erhöhten Limit fortsetzen:

atx --conversation-id <conversation_id> -t --limit <increased_limit>

Kontinuierliches Lernen

In diesem Abschnitt wird beschrieben, wie Sie die durch kontinuierliches Lernen entstandenen Lektionen überprüfen und verwalten können.

Lektionen verstehen

Das System für kontinuierliches Lernen extrahiert automatisch Lektionen aus früheren Durchläufen einer Transformation. Das System erstellt sie asynchron auf der Grundlage von:

Die Lektionen häufen sich im Laufe der Zeit an, wenn Sie die Transformation über verschiedene Codebasen hinweg ausführen. Das System wendet sie automatisch an, um future Läufe zu verbessern. Jede Lektion gehört zu einer Kategorie, die alle Lektionen eines ähnlichen Bereichs enthält, sodass Sie verwandte Lektionen gemeinsam überprüfen können. Lektionen, die Sie nicht verwenden möchten, können Sie archivieren oder vollständig löschen.

Lektionen anzeigen und verwalten

Verwenden Sie den learnings Befehl, um eine interaktive Sitzung zum Durchsuchen und Verwalten der Lektionen einer Transformationsdefinition zu öffnen.

Um den Lektionen-Viewer zu öffnen:

atx custom def learnings -n my-transformation

Der Viewer öffnet sich mit einer Liste von Lektionskategorien, von denen jede zeigt, wie viele aktive Lektionen sie enthält. Wählen Sie eine Kategorie aus, um die zugehörigen Lektionen zu sehen, und wählen Sie dann eine Lektion aus, um alle Einzelheiten zu sehen, einschließlich des Hauptteils der Lektion, ihrer Auswirkungen und der Anzahl früherer Lektionen, in denen sie konsultiert wurde.

Lektionen archivieren und wiederherstellen

Das System wendet die Lektionen automatisch an. Wenn Sie nicht möchten, dass das System eine Lektion anwendet, können Sie sie archivieren. Das System behält archivierte Lektionen bei, wendet sie jedoch nicht auf future Läufe an. Alle archivierten Lektionen sind gruppiert, sodass Sie sie überprüfen und alle wieder aktiv verwenden können.

Lektionen löschen

Eine Lektion, die nicht nützlich ist, dauerhaft entfernen. Das Löschen kann nicht rückgängig gemacht werden, und das System kann eine gelöschte Lektion aus zukünftigen Läufen erneut lernen.

Eine Lektion muss archiviert werden, bevor sie gelöscht werden kann.

Erweiterte Konfiguration

In diesem Abschnitt werden erweiterte Funktionen und Konfigurationsoptionen für AWS Transform custom beschrieben.

Umgebungsvariablen

Sie können das CLI-Verhalten mithilfe von Umgebungsvariablen anpassen.

ATX_SHELL_TIMEOUT

Überschreibt das Standard-Timeout für Shell-Befehle (900 Minuten). seconds/15

Linux and macOS

export ATX_SHELL_TIMEOUT=1800  # 30 minutes

Windows (PowerShell)

$env:ATX_SHELL_TIMEOUT=1800  # 30 minutes

Dies ist nützlich für große Codebasen oder lang andauernde Build-Prozesse.

ATX_DISABLE_UPDATE_CHECK

Deaktivieren Sie automatische Versionsprüfungen und Aktualisierungsbenachrichtigungen während der Befehlsausführung.

Linux and macOS

export ATX_DISABLE_UPDATE_CHECK=true

Windows (PowerShell)

$env:ATX_DISABLE_UPDATE_CHECK="true"

ATX_GIT_COMMITTER_NAME und ATX_GIT_COMMITTER_EMAIL

Konfigurieren Sie die Autorenidentität, die für die Checkpoint-Commits verwendet wird, die Transform custom in Ihrem Repository erstellt, wenn Änderungen während einer Transformation angewendet werden. AWS Wenn diese Variablen nicht gesetzt sind, werden Checkpoint-Commits einer Standardidentität () zugeordnet. ATX Bot <checkpoint@atx.bot> Legen Sie beide Variablen fest, um Checkpoints einem bestimmten Autor zuzuordnen.

Linux and macOS

export ATX_GIT_COMMITTER_NAME="Jane Developer"
export ATX_GIT_COMMITTER_EMAIL="jane@example.com"

Windows (PowerShell)

$env:ATX_GIT_COMMITTER_NAME="Jane Developer"
$env:ATX_GIT_COMMITTER_EMAIL="jane@example.com"

Vertraue den Einstellungen

Mit den Vertrauenseinstellungen können Sie bestimmte Tools und Befehle vorab genehmigen, sodass sie ohne Aufforderung ausgeführt werden können. Sie können unabhängig von der Vertrauensstufe auch explizite Berechtigungen für bestimmte Shell-Befehle verlangen. Diese Einstellungen sind in der ~/.aws/atx/trust-settings.yaml Datei konfiguriert.

Die Datei enthält drei Listen:

Vertrauenswürdige Standardtools:

Vertrauenseinstellungen bearbeiten:

Sie können die Datei trust-settings.yaml manuell bearbeiten, um vertrauenswürdige Tools und Befehle hinzuzufügen oder zu entfernen. Beide trustedShellCommands und unterstützen Glob-Platzhaltermuster unter Verwendung von. alwaysPromptCommands *

Im Folgenden werden die einzelnen Befehlslisten beschrieben und es werden Beispiele bereitgestellt:

Session-level vertraue:

Bei interaktiven Eingabeaufforderungen können Sie wählen:

Session-level Die Vertrauenseinstellungen sind temporär und werden beim Neustart der CLI zurückgesetzt. Sie bieten eine temporäre Genehmigung, ohne trust-settings.yaml dauerhaft zu ändern.

Modellieren Sie Context Protocol (MCP) -Server

Die AWS Transform CLI unterstützt Model Context Protocol (MCP) -Server, die ihre Funktionalität um zusätzliche Tools erweitern.

Konfiguration:

Konfigurieren Sie MCP-Server in der ~/.aws/atx/mcp.json Datei. Die AWS Transform CLI unterstützt zwei Arten von MCP-Servern: lokale befehlsbasierte Server und Remote-HTTP-Server.

Lokale befehlsbasierte Server:

Lokale Server werden als untergeordnete Prozesse auf Ihrem Computer ausgeführt. Konfigurieren Sie sie mit der folgenden command Eigenschaft:

{
  "mcpServers": {
    "my-local-server": {
      "command": "npx",
      "args": ["-y", "@example/mcp-server"]
    }
  }
}

Remote-HTTP-Server:

Remoteserver stellen eine Verbindung zu MCP-Servern her, die unter einer HTTP- oder HTTPS-URL gehostet werden. Konfigurieren Sie sie mit der folgenden url Eigenschaft:

{
  "mcpServers": {
    "my-remote-server": {
      "url": "https://api.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${MCP_API_TOKEN}"
      }
    }
  }
}

Die headers Eigenschaft ist optional und unterstützt die Erweiterung von Umgebungsvariablen mithilfe von ${VAR_NAME} Syntax. Auf diese Weise können Sie sensible Werte wie API-Token in Umgebungsvariablen und nicht in der Konfigurationsdatei speichern.

Eigenschaften der Konfiguration:

Lokale befehlsbasierte Server unterstützen die folgenden Eigenschaften:

Remote-HTTP-Server unterstützen die folgenden Eigenschaften:

Verwaltung von MCP-Servern:

Liste der konfigurierten MCP-Server anzeigen:

atx mcp tools

Liste der verfügbaren Tools, die von einem bestimmten MCP-Server angeboten werden:

atx mcp tools --server <server-name>

Nachverfolgung der Nutzung:

Die CLI verfolgt automatisch die Nutzung des MCP-Tools während der Transformationsausführungen. Die Nutzungsstatistiken werden wie mcp_usage.json im Konversationsverzeichnis nebenstehend gespeichert. metadata.json In der Datei werden Metriken pro Tool für jede Ausführung aufgezeichnet, darunter:

Client-Side Fähigkeiten

Client-side Fähigkeiten sind zusätzliche Fähigkeiten, die den Agenten bei Transformationsausführungen erweitern. Sie ermöglichen es Ihnen, benutzerdefinierte Tools, Skripts und Anweisungen bereitzustellen, die der Agent zusätzlich zu seinen integrierten Funktionen verwenden kann.

Verzeichnisse zur Erkennung von Fähigkeiten:

Fähigkeiten werden in vier Verzeichnissen in der Reihenfolge ihrer Priorität erkannt. Wenn ein Skill mit demselben Namen in mehreren Verzeichnissen existiert, hat das erste Verzeichnis in der Liste Priorität:

Die .aws/atx/skills/ Verzeichnisse sind spezifisch für die AWS Transform-CLI. Die .agents/skills/ Verzeichnisse sind mandantenübergreifend, was bedeutet, dass die dort platzierten Fähigkeiten für alle kompatiblen Agent-Tools außerhalb der AWS Transform-CLI verfügbar sind.

Struktur des Skill-Verzeichnisses:

Jeder Skill ist ein Verzeichnis, das eine SKILL.md Datei mit YAML-Frontmatter enthält:

~/.aws/atx/skills/
└── my-skill/
    ├── SKILL.md          # Required: frontmatter + instructions
    ├── references/       # Optional: reference docs the agent can read
    │   └── guide.md
    └── scripts/          # Optional: scripts the agent can execute
        └── validate.py

SKILL.md Format:

---
name: my-skill
description: When to use this skill
---
# Skill Title

Instructions for the agent...

Das name Feld muss mit dem Namen des übergeordneten Verzeichnisses übereinstimmen.

Einen Skill deaktivieren:

Um zu verhindern, dass ein Skill geladen wird, ohne die zugehörigen Dateien disable-model-invocation: true zu entfernen, fügen Sie der Titelseite Folgendes hinzu:

---
name: my-skill
description: When to use this skill
disable-model-invocation: true
---

Wenn diese Eigenschaft festgelegt ist, überspringt die CLI den Skill bei der Erkennung. Der Agent kann den Skill nur sehen oder verwenden, wenn er in einer Transformationsdefinition ausdrücklich angewiesen wird, die Skill-Datei zu lesen. Verwenden Sie diese Option, um einen Skill vorübergehend zu deaktivieren, ihn als in Bearbeitung zu markieren oder Referenzmaterial aufzubewahren, das nur für menschliche Leser bestimmt ist.

Verfügbarkeit von Fähigkeiten nach Ausführungsmodus:

Überprüfung der Erkennung von Fähigkeiten:

Überprüfe nach einem Lauf das Debug-Protokoll der CLI, um zu überprüfen, welche Skills entdeckt wurden:

Linux and macOS

grep -i "skill" ~/.aws/atx/logs/debug.log | tail -20

Windows (PowerShell)

Select-String -Pattern "skill" "$env:USERPROFILE\.aws\atx\logs\debug.log" | Select-Object -Last 20

Fähigkeiten, bei denen die Validierung fehlschlägt, werden mit einer Warnung in den Debug-Protokollen übersprungen.

Wahl zwischen Project-Level und User-Level Fähigkeiten

Wo du eine Fähigkeit platzierst, bestimmt, wem sie zugute kommt und wann sie aktiviert wird.

Project-level Fähigkeiten (<project>/.aws/atx/skills/):

Übergeben Sie diese der Versionskontrolle, sodass jedes Teammitglied, das Transformationen gegen das Repository durchführt, sie automatisch erkennt. Nutzen Sie Fähigkeiten auf Projektebene für:

User-level Fähigkeiten (~/.aws/atx/skills/):

Diese verbleiben auf Ihrem Computer und werden bei allen Transformationen aktiviert, unabhängig davon, auf welches Repository Sie abzielen. Nutzen Sie Fähigkeiten auf Benutzerebene für:

Tipps für effektive Fähigkeiten:

Client-Side Beispiele für Fähigkeiten

Diese Beispiele zeigen zwei gängige Muster: eine skriptbasierte Validierungsfähigkeit und eine Fähigkeit, die nur als Referenz dient.

Beispiel: Dockerfile Compliance Checker () Script-Based

Dieser Skill validiert Dockerfiles anhand von bewährten Sicherheits- und Betriebspraktiken. Es verwendet ein Überprüfungsskript, das der Agent vor und nach Änderungen ausführt.

Verzeichnisstruktur:

.aws/atx/skills/
└── dockerfile-compliance/
    ├── SKILL.md
    ├── scripts/
    │   └── lint_dockerfile.sh
    └── references/
        └── dockerfile-best-practices.md

SKILL.md:

---
name: dockerfile-compliance
description: Validates Dockerfiles against security and operational best practices
---
# Dockerfile Compliance Checker

When a transformation creates or modifies Dockerfiles, run the compliance checker.

## When to use

- After creating a new Dockerfile
- After modifying FROM, RUN, USER, or EXPOSE directives
- When containerizing an application as part of a transformation

## How to use

Run: `bash scripts/lint_dockerfile.sh <path-to-Dockerfile>`

If violations are found, consult `references/dockerfile-best-practices.md`
for compliant patterns.

Das Validierungsskript sucht nach unverankerten Basis-Image-Tags, die als Root-Benutzer ausgeführt werden, nach fest codierten Geheimnissen in ENV Direktiven und nach fehlenden Definitionen. HEALTHCHECK Der Agent führt das Skript aus, behebt Verstöße anhand von Mustern aus der Referenzdatei und führt das Skript erneut aus, um die Einhaltung der Vorschriften zu bestätigen.

Beispiel: API Deprecation Helper () Reference-Only

Dieser Skill führt den Agenten durch das Ersetzen veralteter API-Aufrufe bei Upgrade-Transformationen. Es werden nur Referenzdateien ohne Skripte verwendet.

Verzeichnisstruktur:

.aws/atx/skills/
└── api-deprecation-helper/
    ├── SKILL.md
    └── references/
        ├── aws-sdk-v2-to-v3.md
        └── react-class-to-hooks.md

SKILL.md:

---
name: api-deprecation-helper
description: Guides the agent through replacing deprecated API calls with modern equivalents
---
# API Deprecation Helper

When performing upgrade transformations, use this skill to identify and replace
deprecated API calls with their modern equivalents.

## When to use

- During any version upgrade transformation
- When build warnings mention deprecated APIs
- When transforming code that uses legacy patterns

## Process

1. Identify deprecated API calls in the codebase
2. For each deprecated call, find the replacement in `references/`
3. Apply the replacement, preserving the original behavior
4. Verify the replacement compiles and tests pass

Die Referenzdateien enthalten Vorher-Nachher-Codebeispiele. Ordnet beispielsweise aws-sdk-v2-to-v3.md Muster wie das modulare V3-Äquivalent mit und s3.putObject(params).promise() zu. S3Client PutObjectCommand

Schlagworte und Organisation

Sie können Transformationen mit Tags für die Zugriffskontrolle und Kategorisierung organisieren.

Um Tags für eine Transformation aufzulisten:

atx custom def list-tags --arn <transformation-arn>

Um Tags zu einer Transformation hinzuzufügen:

atx custom def tag --arn <transformation-arn> --tags '{"env":"prod","team":"backend"}'

Um Tags aus einer Transformation zu entfernen:

atx custom def untag --arn <transformation-arn> --tag-keys "env,team"

Tags können für die gruppierte Zugriffskontrolle in IAM-Richtlinien verwendet werden. Sie können Richtlinien erstellen, die allen Transformationen mit bestimmten Tags (z. B. allen Transformationen, die mit team:frontend oder gekennzeichnet sind) Berechtigungen gewähren. environment:production

Protokolle

AWS Transform CLI verwaltet drei Arten von Protokollen zur Fehlerbehebung und zum Debuggen.

Konversationsprotokolle:

Linux and macOS

~/.aws/atx/custom/<conversation_id>/logs/<timestamp>-conversation.log

Windows

%USERPROFILE%\.aws\atx\custom\<conversation_id>\logs\<timestamp>-conversation.log

Diese Protokolle enthalten den vollständigen Konversationsverlauf für eine bestimmte Sitzung.

Subagent-Protokolle:

Linux and macOS

~/.aws/atx/custom/<conversation_id>/logs/subagents/<name>.log

Windows

%USERPROFILE%\.aws\atx\custom\<conversation_id>\logs\subagents\<name>.log

Diese Protokolle enthalten Ausgaben von Subagenten, die der Haupt-Agent bei Transformationen erzeugt. Sie müssen Subagenten nicht direkt verwalten.

Debug-Protokolle für Entwickler:

Linux and macOS

~/.aws/atx/logs/debug*.log
~/.aws/atx/logs/error.log

Windows

%USERPROFILE%\.aws\atx\logs\debug*.log
%USERPROFILE%\.aws\atx\logs\error.log

Diese Protokolle enthalten erweiterte Informationen zur Fehlerbehebung für die CLI selbst.

CLI-Aktualisierungen

Halten Sie Ihre CLI auf dem neuesten Stand, um auf neue Funktionen und Verbesserungen zugreifen zu können.

Um nach Updates zu suchen:

atx update --check

Um auf die neueste Version zu aktualisieren:

atx update

Um auf eine bestimmte Version zu aktualisieren:

atx update --target-version <version>

Erstellen Sie benutzerdefinierte Transformationen

In diesem Abschnitt wird beschrieben, wie Sie benutzerdefinierte Transformationsdefinitionen erstellen, ändern und verwalten.

Eine neue Transformation erstellen

Verwenden Sie die interaktive CLI, um eine neue Transformationsdefinition zu erstellen.

Um eine Transformationsdefinition zu erstellen

Bewährte Methoden für die Erstellung von Transformationen:

Bereitstellung von Referenzmaterial

Sie können Referenzdateien für AWS Transform custom bereitstellen, indem Sie während der Konversation Dateipfade angeben. Diese Dateien werden im references/ Ordner der Transformationsdefinition gespeichert.

Empfohlene Typen von Referenzdateien:

Um eine Referenzdatei bereitzustellen:

Take a look at the documentation here: /path/to/migration-guide.md

Sie können auch ein Verzeichnis angeben, das mehrere Referenzdateien enthält:

Take a look at the docs we have here: /path/to/docs/

Ändern einer vorhandenen Transformation

Sie können benutzerdefinierte Transformationen sowohl vor als auch nach dem Speichern als Entwürfe oder nach dem Veröffentlichen ändern. Sie können AWS-verwaltete Transformationen nicht ändern. Wenn Sie sie anpassen müssen, können Sie mithilfe der Konfigurationsdatei zusätzlichen Kontext bereitstellen.

Um eine bestehende Transformation zu ändern

Transformationen veröffentlichen und verwalten

Sie können Ihre Transformationen mithilfe der interaktiven Benutzeroberfläche oder mit den folgenden Befehlen veröffentlichen und verwalten.

Um eine Transformation als Entwurf zu speichern:

atx custom def save-draft -n my-transformation --description "Description of the transformation" --sd ./transformation-directory

Um eine Transformation zu veröffentlichen:

atx custom def publish -n my-transformation --description "Description of the transformation" --sd ./transformation-directory

Um verfügbare Transformationen aufzulisten:

atx custom def list

Um eine Transformationsdefinition herunterzuladen:

atx custom def get -n my-transformation

Dadurch wird die Transformationsdefinition in Ihr aktuelles Arbeitsverzeichnis heruntergeladen. Sie können ein Zielverzeichnis mit dem --td Flag und eine Version mit dem --tv Flag angeben.

Um eine Transformationsdefinition zu löschen:

atx custom def delete -n my-transformation

Transformationsversionen verwalten

AWS Transform Custom verwaltet Versionen Ihrer Transformationsdefinitionen. Sie können eine Version angeben, wenn Sie eine Transformation ausführen oder herunterladen.

Um eine bestimmte Version auszuführen:

atx custom def exec -n my-transformation --tv v1 -p ./my-project

Um eine bestimmte Version herunterzuladen:

atx custom def get -n my-transformation --tv v1

Wenn keine Version angegeben ist, wird die neueste Version verwendet.