Amazon CodeCatalyst は新規のお客様には提供されなくなりました。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、「[CodeCatalyst から移行する方法](migration.md)」を参照してください。 翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ワークフローアクションの構成 *アクション*はワークフローの主要な構成要素であり、ワークフローの実行中に実行する作業またはタスクの論理単位を定義します。通常、ワークフローには、設定方法に応じて順次または並列に実行される複数のアクションが含まれます。 **Topics** + [アクションタイプ](#workflows-actions-types) + [ワークフローへのアクションの追加](workflows-add-action.md) + [ワークフローからのアクションの削除](workflows-delete-action.md) + [カスタムアクションの開発](workflows-custom-action.md) + [アクショングループへのアクションのグループ化](workflows-group-actions.md) + [アクションの順序付け](workflows-depends-on.md) + [アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md) + [使用するアクションバージョンの指定](workflows-action-versions.md) + [使用可能なアクションバージョンの一覧表示](workflows-action-versions-determine.md) + [アクションのソースコードの表示](workflows-view-source.md) + [GitHub Actions との統合](integrations-github-actions.md) ## アクションタイプ Amazon CodeCatalyst ワークフロー内では、次のタイプのアクションを使用できます。 **Topics** + [CodeCatalyst アクション](#workflows-actions-types-cc) + [CodeCatalyst Labs アクション](#workflows-actions-types-cc-labs) + [GitHub Actions](#workflows-actions-types-github) + [サードパーティーアクション](#workflows-actions-types-3p) ### CodeCatalyst アクション *CodeCatalyst アクション*は、CodeCatalyst 開発チームによって作成、維持管理、完全にサポートされるアクションです。 アプリケーションを構築、テスト、デプロイするための CodeCatalyst アクションに加え、 AWS Lambda 関数の呼び出しなどのさまざまなタスクを実行する CodeCatalyst アクションもあります。 次の CodeCatalyst アクションを使用できます。 + **Build** このアクションはアーティファクトを構築し、Docker コンテナでユニットテストを実行します。詳細については、「[ビルドアクションの追加](build-add-action.md)」を参照してください。 + **Test** このアクションは、アプリケーションまたはアーティファクトに対して統合テストとシステムテストを実行します。詳細については、「[テストアクションの追加](test-add-action.md)」を参照してください。 + **Amazon S3 公開** このアクションは、アプリケーションアーティファクトを Amazon S3 バケットにコピーします。詳細については、「[ワークフローを使用して Amazon S3 にファイルを発行する](s3-pub-action.md)」を参照してください。 + **AWS CDK bootstrap** このアクションは、 が CDK アプリケーションをデプロイ AWS CDK するために必要なリソースをプロビジョニングします。詳細については、「[ワークフローを使用して AWS CDK アプリをブートストラップする](cdk-boot-action.md)」を参照してください。 + **AWS CDK デプロイ** このアクションはアプリケーションを合成してデプロイします AWS Cloud Development Kit (AWS CDK) 。詳細については、「[ワークフローを使用した AWS CDK アプリケーションのデプロイ](cdk-dep-action.md)」を参照してください。 + **AWS Lambda 呼び出し** このアクションは AWS Lambda 関数を呼び出します。詳細については、「[ワークフローを使用して Lambda 関数を呼び出す](lam-invoke-action.md)」を参照してください。 + **GitHub Actions** このアクションは、CodeCatalyst ワークフロー内で GitHub Actions を実行できるようにする *CodeCatalyst* アクションです。詳細については、「[ワークフローを使用して Lambda 関数を呼び出す](lam-invoke-action.md)」を参照してください。 + **スタックをデプロイ CloudFormation する** このアクションは CloudFormation スタックをデプロイします。詳細については、「[CloudFormation スタックのデプロイ](deploy-action-cfn.md)」を参照してください。 + **Amazon ECS へのデプロイ** このアクションは、Amazon ECS タスク定義を登録し、Amazon ECS サービスにデプロイします。詳細については、「[ワークフローを使用した Amazon ECS へのデプロイ](deploy-action-ecs.md)」を参照してください。 + **Kubernetes クラスターへのデプロイ** このアクションは、アプリケーションを Kubernetes クラスターにデプロイします。詳細については、「[ワークフローを使用して Amazon EKS にデプロイする](deploy-action-eks.md)」を参照してください。 + **Amazon ECS タスク定義のレンダリング** このアクションは、コンテナイメージ URI を Amazon ECS タスク定義 JSON ファイルに挿入し、新しいタスク定義ファイルを作成します。詳細については、「[Amazon ECS タスク定義の変更](render-ecs-action.md)」を参照してください。 CodeCatalyst アクションのドキュメントは、このガイドおよび各アクションの readme で入手できます。 使用可能な CodeCatalyst アクションと、それをワークフローに追加する方法については、「[ワークフローへのアクションの追加](workflows-add-action.md)」を参照してください。 ### CodeCatalyst Labs アクション *CodeCatalyst Labs アクション*は、実験アプリケーションの実証基盤である Amazon CodeCatalyst Labs の一部であるアクションです。CodeCatalyst Labs アクションは、 AWS サービスとの統合を紹介するために開発されました。 次の CodeCatalyst Labs アクションを使用できます。 + ** AWS Amplify ホスティングにデプロイする** このアクションは、アプリケーションを Amplify Hosting にデプロイします。 + **にデプロイする AWS App Runner** このアクションは、ソースイメージリポジトリ内の最新イメージを App Runner にデプロイします。 + **Amazon CloudFront と Amazon S3 へのデプロイ** このアクションは、アプリケーションを CloudFront と Amazon S3 にデプロイします。 + **を使用してデプロイする AWS SAM** このアクションは、 AWS Serverless Application Model (AWS SAM) を使用してサーバーレスアプリケーションをデプロイします。 + **Amazon CloudFront キャッシュの無効化** このアクションは、特定のパスセットの CloudFront キャッシュを無効にします。 + **送信 Webhook** このアクションにより、ユーザーは HTTPS リクエストを使用してワークフロー内のメッセージを任意のウェブサーバーに送信できます。 + **への発行 AWS CodeArtifact** このアクションは CodeArtifact リポジトリにパッケージを公開します。 + **Amazon SNS への公開** このアクションにより、ユーザーはトピックの作成、トピックへの公開、またはトピックへのサブスクライブによって Amazon SNS と統合できます。 + **Amazon ECR へのプッシュ** このアクションは、Docker イメージを構築して Amazon Elastic Container Registry (Amazon ECR) リポジトリに公開します。 + **Amazon CodeGuru Security を使用したスキャン** このアクションは、構成されたコードパスの zip アーカイブを作成し、CodeGuru Security を使用してコードスキャンを実行します。 + **Terraform Community Edition** このアクションは Terraform Community Edition の `plan` オペレーションと `apply` オペレーションを実行します。 CodeCatalyst Labs アクションのドキュメントは、各アクションの readme で入手できます。 CodeCatalyst Labs アクションをワークフローに追加し、その readme を表示する方法については、「[ワークフローへのアクションの追加](workflows-add-action.md)」を参照してください。 ### GitHub Actions *GitHub アクション*は [CodeCatalyst アクション](#workflows-actions-types-cc) とよく似ていますが、GitHub ワークフローで使用するために開発された点が異なります。GitHub Actions の詳細については、[GitHub Actions](https://docs.github.com/en/actions) ドキュメントを参照してください。 GitHub Actions は、CodeCatalyst ワークフローのネイティブ CodeCatalyst アクションとともに使用できます。 利便性のために、CodeCatalyst コンソールでは、いくつかの人気の GitHub Actions にアクセスできるようになっています。[GitHub Marketplace](https://github.com/marketplace/actions) に掲載されている GitHub アクションを使用することもできます (いくつかの制限があります)。 GitHub Actions のドキュメントは、各アクションの readme で入手できます。 詳細については、「[GitHub Actions との統合](integrations-github-actions.md)」を参照してください。 ### サードパーティーアクション *サードパーティーアクション*は、サードパーティーベンダーによって作成され、CodeCatalyst コンソールで利用できるアクションです。サードパーティーアクションの例には、Mend によって作成された **Mend SCA** アクションや、Sonar によって作成された **SonarCloud Scan** アクションなどがあります。 サードパーティーアクションのドキュメントは、各アクションの readme で入手できます。サードパーティーベンダーから追加のドキュメントが提供されている場合もあります。 ワークフローへのサードパーティーアクションの追加と readme の表示については、「[ワークフローへのアクションの追加](workflows-add-action.md)」を参照してください。 # ワークフローへのアクションの追加 次の手順に従って、ワークフローにアクションを追加して構成します。 **アクションを追加および構成するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. 左上で **[\$1 アクション]** を選択すると、**[アクション]** カタログが表示されます。 1. ドロップダウンリストで、次のいずれかを実行します。 + **[Amazon CodeCatalyst]** を選択すると、[CodeCatalyst](workflows-actions.md#workflows-actions-types-cc)、[CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs)、または[サードパーティー](workflows-actions.md#workflows-actions-types-3p)のアクションが表示されます。 + CodeCatalyst アクションには **[ AWSによるアクション]** ラベルがあります。 + CodeCatalyst Labs アクションには **[CodeCatalyst Labs のよるアクション]** ラベルがあります。 + サードパーティーアクションには **[*ベンダー*によるアクション]** ラベルがあり、*ベンダー*はサードパーティーベンダーの名前です。 + **[GitHub]** を選択すると、[GitHub Actions の厳選されたリスト](integrations-github-action-add-curated.md)が表示されます。 1. アクションカタログでアクションを検索し、次のいずれかを実行します。 + プラス記号 (**\$1**) を選択して、ワークフローにアクションを追加します。 + アクションの名前を選択して、その readme を表示します。 1. アクションを構成します。**[ビジュアル]** を選択してビジュアルエディタを使用するか、**[YAML]** を選択して YAML エディタを使用します。詳細な手順については、以下のリンクを参照してください。 [CodeCatalyst アクション](workflows-actions.md#workflows-actions-types-cc)を追加する手順については、以下を参照してください。 + [ビルドアクションの追加](build-add-action.md) + [テストアクションの追加](test-add-action.md) + [「Amazon ECS にデプロイ」アクションの追加](deploy-action-ecs-adding.md) + [「Kubernetes クラスターにデプロイ」アクションの追加](deploy-action-eks-adding.md) + [CloudFormation 「スタックのデプロイ」アクションの追加](deploy-action-cfn-adding.md) + [AWS CDK 「デプロイ」アクションの追加](cdk-dep-action-add.md) + [AWS CDK 「ブートストラップ」アクションの追加](cdk-boot-action-add.md) + [「Amazon S3 発行」アクションの追加](s3-pub-action-add.md) + [AWS Lambda 「呼び出し」アクションの追加](lam-invoke-action-add.md) + [「Amazon ECS タスク定義のレンダリング」アクションの追加](render-ecs-action-add.md) [CodeCatalyst Labs アクション](workflows-actions.md#workflows-actions-types-cc-labs)を追加する手順については、以下を参照してください。 + アクションの readme。アクションカタログでアクションの名前を選択することで readme を確認できます。 [GitHub Actions](workflows-actions.md#workflows-actions-types-github) を追加する手順については、以下を参照してください。 + [GitHub Actions との統合](integrations-github-actions.md) [サードパーティーアクション](workflows-actions.md#workflows-actions-types-3p)を追加する手順については、以下を参照してください。 + アクションの readme。アクションカタログでアクションの名前を選択することで readme を確認できます。 1. (任意) **[検証]** を選択して、YAML コードが有効であることを確認します。 1. **[コミット]** を選択して変更をコミットします。 # ワークフローからのアクションの削除 ワークフローからアクションを削除するには、次の手順に従います。 ------ #### [ Visual ] **ビジュアルエディタを使用してアクションを削除するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図の削除するアクションで、縦三点アイコン (![\[Ellipsis.\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/elipsis.png))、**[削除]** の順に選択します。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用してアクションを削除するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 削除するアクションを含む YAML のセクションを見つけます。 セクションを選択し、キーボードの Delete キーを押します。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # カスタムアクションの開発 CodeCatalyst アクション開発キット (ADK) を使用して、ワークフローで使用するカスタムアクションを開発できます。その後、アクションを CodeCatalyst アクションカタログに公開して、他の CodeCatalyst ユーザーがワークフローでアクションを表示および使用できるようにします。 **アクションを開発、テスト、公開するには (概要レベルのタスク)** 1. アクションの開発に必要なツールとパッケージをインストールします。 1. アクションコードを保存する CodeCatalyst リポジトリを作成します。 1. アクションを初期化します。これにより、独自のコードで更新できるアクション定義ファイル (`action.yml`) など、アクションに必要なソースファイルが作成されます。 1. アクションコードをブートストラップして、アクションプロジェクトを構築、テスト、リリースするために必要なツールとライブラリを取得します。 1. ローカルコンピューターでアクションを構築し、CodeCatalyst リポジトリに変更をプッシュします。 1. ユニットテストでアクションをローカルでテストし、CodeCatalyst で ADK 生成ワークフローを実行します。 1. CodeCatalyst コンソールで **[公開]** ボタンを選択して、CodeCatalyst アクションカタログにアクションを公開します。 詳細な手順については、[Amazon CodeCatalyst アクション開発キットデベロッパーガイド](https://docs.aws.amazon.com/codecatalyst/latest/adk/what-is-action-development-kit.html)を参照してください。 # アクショングループへのアクションのグループ化 *アクショングループ*には 1 つ以上のアクションが含まれています。アクションをアクショングループにグループ化すると、ワークフローを整理するのに役立ち、異なるグループ間の依存関係を構成できるようになります。 **注記** 他のアクショングループまたはアクション内にアクショングループをネストすることはできません。 **Topics** + [アクショングループの定義](#workflows-define-action-group) + [例: 2 つのアクショングループの定義](workflows-group-actions-example.md) ## アクショングループの定義 CodeCatalyst アクショングループを定義するには、次の手順に従います。 ------ #### [ Visual ] *利用できません。[YAML] を選択して YAML の手順を表示してください。* ------ #### [ YAML ] **グループを定義にするには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. `Actions` で次のようなコードを追加します。 ``` Actions: action-group-name: Actions: action-1: Identifier: aws/build@v1 Configuration: ... action-2: Identifier: aws/build@v1 Configuration: ... ``` 別の例については、「[例: 2 つのアクショングループの定義](workflows-group-actions-example.md)」を参照してください。詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」の「[アクション](workflow-reference.md#actions-reference)」にある `action-group-name` プロパティの説明を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 例: 2 つのアクショングループの定義 次の例は、`BuildAndTest` と `Deploy` という 2 つの Amazon CodeCatalyst アクショングループを定義する方法を示したものです。`BuildAndTest` グループには 2 つのアクション (`Build` と `Test`) が含まれており、`Deploy` グループには 2 つのアクション (`DeployCloudFormationStack` と `DeployToECS`) も含まれています。 ``` Actions: BuildAndTest: # Action group 1 Actions: Build: Identifier: aws/build@v1 Configuration: ... Test: Identifier: aws/managed-test@v1 Configuration: Deploy: #Action group 2 Actions: DeployCloudFormationStack: Identifier: aws/cfn-deploy@v1 Configuration: ... DeployToECS: Identifier: aws/ecs-deploy@v1 Configuration: ... ``` # アクションの順序付け デフォルトでは、ワークフローにアクションを追加すると、[ビジュアルエディタ](workflow.md#workflow.editors)に横並びで追加されます。つまり、ワークフロー実行を開始すると、アクションが並行して実行されます。アクションを順番に実行する (ビジュアルエディタに縦方向に表示される) 場合は、アクション間に依存関係を設定する必要があります。例えば、ビルドアクションの後にテストアクションが実行されるように、`Build` アクションに依存する `Test` アクションを設定できます。 アクションとアクショングループ間の依存関係を設定できます。1 対多の依存関係を構成して、1 つのアクションの開始を他のいくつかのアクションに依存させることもできます。「[アクション間の依存関係の設定](workflows-depends-on-set-up.md)」のガイドラインを参照して、依存関係の設定がワークフローの YAML 構文に準拠していることを確認してください。 **Topics** + [アクション間の依存関係を構成する方法の例](workflows-depends-on-examples.md) + [アクション間の依存関係の設定](workflows-depends-on-set-up.md) # アクション間の依存関係を構成する方法の例 次の例は、ワークフロー定義ファイル内のアクションとグループ間の依存関係を構成する方法を示したものです。 **Topics** + [例: 単純な依存関係の構成](#workflows-depends-on-example-simple) + [例: アクションに依存するようにアクショングループを構成する](#workflows-depends-on-example-action-groups-actions) + [例: 別のアクショングループに依存するようにアクショングループを構成する](#workflows-depends-on-example-two-action-groups) + [例: 複数のアクションに依存するようにアクショングループを構成する](#workflows-depends-on-example-advanced) ## 例: 単純な依存関係の構成 次の例は、`DependsOn` プロパティを使用して `Build` アクションに依存するように `Test` アクションを構成する方法を示したものです。 ``` Actions: Build: Identifier: aws/build@v1 Configuration: ... Test: DependsOn: - Build Identifier: aws/managed-test@v1 Configuration: ... ``` ## 例: アクションに依存するようにアクショングループを構成する 次の例は、`FirstAction` アクションに依存するように `DeployGroup` アクショングループを構成する方法を示したものです。アクションとアクショングループが同じレベルにあることに注目してください。 ``` Actions: FirstAction: #An action outside an action group Identifier: aws/github-actions-runner@v1 Configuration: ... DeployGroup: #An action group containing two actions DependsOn: - FirstAction Actions: DeployAction1: ... DeployAction2: ... ``` ## 例: 別のアクショングループに依存するようにアクショングループを構成する 次の例は、`BuildAndTestGroup` アクショングループに依存するように `DeployGroup` アクショングループを構成する方法を示したものです。アクショングループが同じレベルにあることに注目してください。 ``` Actions: BuildAndTestGroup: # Action group 1 Actions: BuildAction: ... TestAction: ... DeployGroup: #Action group 2 DependsOn: - BuildAndTestGroup Actions: DeployAction1: ... DeployAction2: ... ``` ## 例: 複数のアクションに依存するようにアクショングループを構成する 次の例は、`FirstAction` アクションと `SecondAction` アクションに加え、`BuildAndTestGroup` アクショングループに依存するように `DeployGroup` アクショングループを構成する方法を示したものです。`DeployGroup` が `FirstAction`、`SecondAction`、`BuildAndTestGroup` と同じレベルにあることに注目してください。 ``` Actions: FirstAction: #An action outside an action group ... SecondAction: #Another action ... BuildAndTestGroup: #Action group 1 Actions: Build: ... Test: ... DeployGroup: #Action group 2 DependsOn: - FirstAction - SecondAction - BuildAndTestGroup Actions: DeployAction1: ... DeployAction2: ... ``` # アクション間の依存関係の設定 次の手順に従って、ワークフロー内のアクション間の依存関係を設定します。 依存関係を構成するときは、次のガイドラインに従ってください。 + アクションがグループ内にある場合、そのアクションは同じグループ内の他のアクションにのみ依存できます。 + アクションとアクショングループは、YAML 階層内で*同じレベル*の他のアクションとアクショングループに依存できますが、別のレベルでは依存*できません*。 ------ #### [ Visual ] **ビジュアルエディタを使用して依存関係を設定するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、別のアクションに依存するアクションを選択します。 1. **[入力]** タブを選択します。 1. **[依存 - オプション]** で以下を実行します。 このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。 「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用して依存関係を設定するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 別のアクションに依存するアクションで、次のようなコードを追加します。 ``` action-name: DependsOn: - action-1 ``` その他の例については、「[アクション間の依存関係を構成する方法の例](workflows-depends-on-examples.md)」を参照してください。一般的なガイドラインについては、「[アクション間の依存関係の設定](#workflows-depends-on-set-up)」を参照してください。詳細については、アクションの「[ワークフロー YAML 定義](workflow-reference.md)」の `DependsOn` プロパティの説明を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # アクション間でのアーティファクトとファイルの共有 *アーティファクト*はワークフローアクションの出力であり、通常はフォルダまたはファイルのアーカイブで構成されます。アーティファクトは、アクション間でのファイルや情報の共有を可能にするため重要です。 `sam-template.yml` ファイルを*生成*するビルドアクションがあっても、デプロイアクションでそれを*使用*するようにしたい場合を考えてみましょう。このシナリオでは、アーティファクトを使用して、ビルドアクションが `sam-template.yml` ファイルをデプロイアクションと共有できるようにします。コードは次のようになります。 ``` Actions: BuildAction: Identifier: aws/build@v1 Steps: - Run: sam package --output-template-file sam-template.yml Outputs: Artifacts: - Name: MYARTIFACT Files: - sam-template.yml DeployAction: Identifier: aws/cfn-deploy@v1 Inputs: Artifacts: - MYARTIFACT Configuration: template: sam-template.yml ``` 前のコードでは、ビルドアクション (`BuildAction`) が `sam-template.yml` ファイルを生成し、それを `MYARTIFACT` という出力アーティファクトに追加します。後続のデプロイアクション (`DeployAction`) では、`MYARTIFACT` を入力として指定し、`sam-template.yml` ファイルへのアクセスを許可します。 **Topics** + [アーティファクトを出力や入力として指定せずに共有できますか?](#workflows-working-artifacts-share) + [ワークフロー間でアーティファクトを共有できますか?](#workflows-working-artifacts-share-wf) + [アーティファクトの例](workflows-working-artifacts-ex.md) + [出力アーティファクトの定義](workflows-working-artifacts-output.md) + [入力アーティファクトの定義](workflows-working-artifacts-refer.md) + [アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md) + [アーティファクトのダウンロード](workflows-download-workflow-outputs.md) ## アーティファクトを出力や入力として指定せずに共有できますか? はい。アクションの YAML コードの `Outputs` および `Inputs` セクションでアーティファクトを指定せずに、アクション間でアーティファクトを共有できます。これを行うには、コンピューティング共有を有効にする必要があります。コンピューティング共有と、コンピューティング共有が有効になっているときにアーティファクトを指定する方法の詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。 **注記** コンピューティング共有機能では、`Outputs` および `Inputs` セクションが不要になることで、ワークフローの YAML コードを簡素化できますが、この機能には有効にする前に注意すべき制限があります。制限の詳細については、「[コンピューティング共有に関する考慮事項](compute-sharing.md#compare-compute-sharing)」を参照してください。 ## ワークフロー間でアーティファクトを共有できますか? いいえ。異なるワークフロー間でアーティファクトを共有することはできませんが、同じワークフロー内のアクション間でアーティファクトを共有することはできます。 # アーティファクトの例 次の例は、Amazon CodeCatalyst ワークフロー定義ファイルでアーティファクトを出力、入力、参照する方法を示しています。 **Topics** + [例: アーティファクトの出力](#workflows-working-artifacts-ex-basic) + [例: 別のアクションによって生成されたアーティファクトの入力](#workflows-working-artifacts-ex-ref) + [例: 複数のアーティファクトでのファイルの参照](#workflows-working-artifacts-ex-ref-file) + [例: 1 つのアーティファクトでのファイルの参照](#workflows-working-artifacts-ex-ref-file-one) + [例: WorkflowSource が存在するときのアーティファクト内のファイルの参照](#workflows-working-artifacts-ex-ref-file-wf-source) + [例: アクショングループが存在するときのアーティファクト内のファイルの参照](#workflows-working-artifacts-ex-groups) ## 例: アーティファクトの出力 次の例は、2 つの .jar ファイルを含むアーティファクトを出力する方法を示しています。 ``` Actions: Build: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ARTIFACT1 Files: - build-output/file1.jar - build-output/file2.jar ``` ## 例: 別のアクションによって生成されたアーティファクトの入力 次の例は、`BuildActionA` で `ARTIFACT4` というアーティファクトを出力し、`BuildActionB` に入力する方法を示しています。 ``` Actions: BuildActionA: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ARTIFACT4 Files: - build-output/file1.jar - build-output/file2.jar BuildActionB: Identifier: aws/build@v1 Inputs: Artifacts: - ARTIFACT4 Configuration: ``` ## 例: 複数のアーティファクトでのファイルの参照 次の例は、`BuildActionC` で `ART5` と `ART6` という名前の 2 つのアーティファクトを出力し、`BuildActionD` (`Steps` の下) で `file5.txt` (アーティファクト `ART5` 内) と `file6.txt` (アーティファクト `ART6` 内) という名前の 2 つのファイルを参照する方法を示しています。 **注記** ファイルの参照の詳細については、「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。 **注記** この例では `$CATALYST_SOURCE_DIR_ART5` プレフィックスが使用されていますが、こちらは省略しても構いません。これは、 `ART5` が*プライマリ入力*であるためです。プライマリ入力の詳細については、「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。 ``` Actions: BuildActionC: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART5 Files: - build-output/file5.txt - Name: ART6 Files: - build-output/file6.txt BuildActionD: Identifier: aws/build@v1 Inputs: Artifacts: - ART5 - ART6 Configuration: Steps: - run: cd $CATALYST_SOURCE_DIR_ART5/build-output && cat file5.txt - run: cd $CATALYST_SOURCE_DIR_ART6/build-output && cat file6.txt ``` ## 例: 1 つのアーティファクトでのファイルの参照 次の例は、`BuildActionE` で `ART7` という名前の 1 つのアーティファクトを出力し、`BuildActionF` (`Steps` の下) で `file7.txt` (アーティファクト `ART7` 内) を参照する方法を示しています。 参照では、「[例: 複数のアーティファクトでのファイルの参照](#workflows-working-artifacts-ex-ref-file)」で行ったように `build-output` ディレクトリの前に `$CATALYST_SOURCE_DIR_`*アーティファクト名*プレフィックスが必要でないことに注意してください。これは、`Inputs` で指定された項目が 1 つだけであるためです。 **注記** ファイルの参照の詳細については、「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。 ``` Actions: BuildActionE: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART7 Files: - build-output/file7.txt BuildActionF: Identifier: aws/build@v1 Inputs: Artifacts: - ART7 Configuration: Steps: - run: cd build-output && cat file7.txt ``` ## 例: WorkflowSource が存在するときのアーティファクト内のファイルの参照 次の例は、`BuildActionG` で `ART8` という名前の 1 つのアーティファクトを出力し、`BuildActionH` (`Steps` の下) で `file8.txt` (アーティファクト `ART8` 内) を参照する方法を示しています。 参照では、「[例: 複数のアーティファクトでのファイルの参照](#workflows-working-artifacts-ex-ref-file)」で行ったように `$CATALYST_SOURCE_DIR_`*アーティファクト名*プレフィックスが必要であることに注意してください。これは、`Inputs` (ソースとアーティファクト) で複数の項目が指定されているため、ファイルを検索する場所を示すプレフィックスが必要となるためです。 **注記** ファイルの参照の詳細については、「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。 ``` Actions: BuildActionG: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART8 Files: - build-output/file8.txt BuildActionH: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Artifacts: - ART8 Configuration: Steps: - run: cd $CATALYST_SOURCE_DIR_ART8/build-output && cat file8.txt ``` ## 例: アクショングループが存在するときのアーティファクト内のファイルの参照 次の例は、`ActionGroup1`、`ActionI` で `ART9` という名前のアーティファクトを出力し、`ActionJ` で `file9.txt` (アーティファクト `ART9` 内) を参照する方法を示しています。 ファイルの参照の詳細については、「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。 ``` Actions: ActionGroup1: Actions: ActionI: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART9 Files: - build-output/file9.yml ActionJ: Identifier: aws/cfn-deploy@v1 Inputs: Sources: - WorkflowSource Artifacts: - ART9 Configuration: template: /artifacts/ActionGroup1@ActionJ/ART9/build-output/file9.yml ``` # 出力アーティファクトの定義 次の手順に従って、Amazon CodeCatalyst アクションで出力するアーティファクトを定義します。その後、このアーティファクトは他のアクションで使用できるようになります。 **注記** すべてのアクションが出力アーティファクトをサポートしているわけではありません。アクションが出力アーティファクトをサポートしているかどうかを確認するには、以下のビジュアルエディタの手順を実行して、アクションの **[出力]** タブに **[出力アーティファクト]** ボタンが含まれているかどうかを確認します。含まれている場合は出力アーティファクトがサポートされています。 ------ #### [ Visual ] **ビジュアルエディタを使用して出力アーティファクトを定義するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、アーティファクトを生成するアクションを選択します。 1. **[出力]** タブを選択します。 1. **[アーティファクト]** で **[アーティファクトの追加]** を選択します。 1. **[アーティファクトの追加]** を選択し、次のようにフィールドに情報を入力します。 **アーティファクト名を構築** アクションによって生成されるアーティファクトの名前を指定します。アーティファクト名はワークフロー内で一意でなければならず、英数字 (a～z、A～Z、0～9) とアンダースコア (\$1) しか使用できません。スペース、ハイフン (-)、その他の特殊文字は使用できません。引用符を使用して、出力アーティファクト名でスペース、ハイフン、その他の特殊文字を有効にすることはできません。 アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 **構築で生成されるファイル** CodeCatalyst がアクションによって出力されるアーティファクトに含めるファイルを指定します。これらのファイルは、実行時にワークフローアクションによって生成され、ソースリポジトリでも使用できます。ファイルパスは、ソースリポジトリまたは前のアクションからのアーティファクトに設定でき、ソースリポジトリまたはアーティファクトルートを基準とすることができます。glob パターンを使用してパスを指定できます。例: + ビルドまたはソースリポジトリの場所のルートにある 1 つのファイルを指定するには、`my-file.jar` を使用します。 + サブディレクトリ内の 1 つのファイルを指定するには、`directory/my-file.jar` または `directory/subdirectory/my-file.jar` を使用します。 + すべてのファイルを指定するには、`"**/*"` を使用します。glob パターン `**` は、任意の数のサブディレクトリにマッチすることを示します。 + `directory` という名前のディレクトリ内のすべてのファイルとディレクトリを指定するには、`"directory/**/*"` を使用します。glob パターン `**` は、任意の数のサブディレクトリにマッチすることを示します。 + `directory` という名前のディレクトリ内のすべてのファイルを指定するが、そのサブディレクトリを含めないようにするには、`"directory/*"` を使用します。 **注記** ファイルパスに 1 つ以上のアスタリスク (`*`) またはその他の特殊文字が含まれている場合は、パスを二重引用符 (`""`) で囲みます。特殊文字の詳細については、「[構文ガイドラインと規則](workflow-reference.md#workflow.terms.syntax.conv)」を参照してください。 アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 **注記** 場合によっては、ファイルパスにプレフィックスを追加して、どのアーティファクトまたはソースにあるのかを示す必要があります。詳細については、「[ソースリポジトリファイルの参照](workflows-sources-reference-files.md)」および「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用して出力アーティファクトを定義するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. ワークフローアクションで、次のようなコードを追加します。 ``` action-name: Outputs: Artifacts: - Name: artifact-name Files: - file-path-1 - file-path-2 ``` その他の例については、「[アーティファクトの例](workflows-working-artifacts-ex.md)」を参照してください。詳細については、アクションの「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 入力アーティファクトの定義 別の Amazon CodeCatalyst アクションによって生成されたアーティファクトを使用する場合は、現在のアクションへの入力としてアーティファクトを指定する必要があります。複数のアーティファクトを入力として指定できる場合があります。これはアクションによって異なります。詳細については、アクションの「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 **注記** 他のワークフローのアーティファクトを参照することはできません。 次の手順に従って、別のアクションからのアーティファクトを現在のアクションへの入力として指定します。 **前提条件** 開始する前に、他のアクションからアーティファクトを出力済みであることを確認してください。詳細については、「[出力アーティファクトの定義](workflows-working-artifacts-output.md)」を参照してください。アーティファクトを出力すると、他のアクションで使用できるようになります。 ------ #### [ Visual ] **アクションへの入力としてアーティファクトを指定するには (ビジュアルエディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、アーティファクトを入力として指定するアクションを選択します。 1. **[入力]** を選択します。 1. **[アーティファクト - 省略可**] で以下を実行します。 このアクションへの入力として提供する以前のアクションのアーティファクトを指定します。これらのアーティファクトは、前のアクションで出力アーティファクトとして既に定義されている必要があります。 入力アーティファクトを指定しない場合は、`action-name/Inputs/Sources` で少なくとも 1 つのソースリポジトリを指定する必要があります。 アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 **注記** **[アーティファクト - オプション]** のドロップダウンリストが使用できない場合 (ビジュアルエディタ)、または YAML の検証時にエラーが発生する場合 (YAML エディタ)、アクションが 1 つの入力のみをサポートしていることが原因である可能性があります。この場合はソース入力を削除してみてください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **アクションへの入力としてアーティファクトを指定するには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. アーティファクトを入力として指定するアクションで、次のようなコードを追加します。 ``` action-name: Inputs: Artifacts: - artifact-name ``` その他の例については、「[アーティファクトの例](workflows-working-artifacts-ex.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # アーティファクト内のファイルの参照 アーティファクト内に存在するファイルがあり、Amazon CodeCatalyst ワークフローアクションのいずれかでこのファイルを参照する必要がある場合は、次の手順を実行します。 **注記** [ソースリポジトリファイルの参照](workflows-sources-reference-files.md) も参照してください。 ------ #### [ Visual ] *利用できません。YAML を選択して YAML の手順を表示してください。* ------ #### [ YAML ] **アーティファクト内のファイルを参照するには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. ファイルを参照するアクションで、次のようなコードを追加します。 ``` Actions: My-action: Inputs: Sources: - WorkflowSource Artifacts: - artifact-name Configuration: template: artifact-path/path/to/file.yml ``` 前のコードで以下を置き換えます。 + *artifact-name* をアーティファクトの名前に置き換えます。 + *artifact-path* を以下の表の値に置き換えます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/workflows-working-artifacts-refer-files.html) 例については「[アーティファクトの例](workflows-working-artifacts-ex.md)」を参照してください。 **注記** 次の場合は、*artifact-path* を省略し、アーティファクトルートディレクトリを基準にしたファイルパスを指定するだけで構いません。 参照を含めるアクションには、`Inputs` の下に 1 つの項目のみが含まれます (例えば、1 つの入力アーティファクトが含まれ、ソースは含まれません)。 参照するファイルはプライマリ入力にあります。*プライマリ入力*は `WorkflowSource` であるか、`WorkflowSource` がない場合はリストされた最初の入力アーティファクトです。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # アーティファクトのダウンロード トラブルシューティングの目的で、Amazon CodeCatalyst ワークフローアクションによって生成されたアーティファクトをダウンロードして検査できます。ダウンロードできるアーティファクトは次の 2 種類です。 + **ソースアーティファクト** – 実行開始時に存在していたソースリポジトリコンテンツのスナップショットを含むアーティファクト。 + **ワークフローアーティファクト** – ワークフローの構成ファイルの `Outputs` プロパティで定義されているアーティファクト。 **ワークフローによって出力されたアーティファクトをダウンロードするには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. ワークフローの名前の下で **[実行]** を選択します。 1. **[実行履歴]** の **[実行 ID]** 列で実行を選択します。例えば、`Run-95a4d`。 1. 実行の名前の下で **[アーティファクト]** を選択します。 1. アーティファクトの横にある **[ダウンロード]** を選択します。アーカイブファイルがダウンロードされます。ファイル名はランダムな 7 文字で構成されます。 1. 任意のアーカイブ抽出ユーティリティを使用してアーカイブを抽出します。 # 使用するアクションバージョンの指定 デフォルトでは、ワークフローにアクションを追加すると、Amazon CodeCatalyst は次の形式を使用してワークフロー定義ファイルにフルバージョンを追加します。 `vmajor.minor.patch` 例えば、次のようになります。 ``` My-Build-Action: Identifier: aws/build@v1.0.0 ``` `Identifier` プロパティのフルバージョンを短縮して、ワークフローが常にアクションの最新のマイナーバージョンまたはパッチバージョンを使用するようにすることができます。 例えば、次のように指定したとします。 ``` My-CloudFormation-Action: Identifier: aws/cfn-deploy@v1.0 ``` この場合、最新パッチバージョンは `1.0.4` で、その後、アクションでは `1.0.4` を使用します。例えば `1.0.5` という後続のバージョンがリリースされると、アクションでは `1.0.5` を使用します。例えば `1.1.0` というマイナーバージョンがリリースされると、アクションでは引き続き `1.0.5` を使用します。 バージョンを指定する詳細な手順については、以下のトピックのいずれかを参照してください。 次の手順に従って、ワークフローで使用するアクションのバージョンを指定します。最新のメジャー/マイナーバージョン、または特定のパッチバージョンを指定できます。 アクションの最新のマイナーバージョンまたはパッチバージョンを使用することをお勧めします。 ------ #### [ Visual ] *利用できません。YAML を選択して YAML の手順を表示してください。* ------ #### [ YAML ] **アクションの最新バージョンまたは特定のパッチバージョンを使用するようにワークフローを構成するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. バージョンを編集するアクションを見つけます。 1. アクションの `Identifier` プロパティを見つけ、バージョンを次のいずれかに設定します。 + action-identifier@v*major* – ワークフローで特定のメジャーバージョンを使用するようにし、最新のマイナーバージョンとパッチバージョンを自動的に選択できるようにするにはこの構文を使用します。 + action-identifier@v*major*.*minor* – ワークフローで特定のマイナーバージョンを使用するようにし、最新のパッチバージョンを自動的に選択できるようにするにはこの構文を使用します。 + action-identifier@v*major*.*minor*.*patch* – ワークフローで特定のパッチバージョンを使用するようにするにはこの構文を使用します。 **注記** 利用可能なバージョンが不明な場合は、「[使用可能なアクションバージョンの一覧表示](workflows-action-versions-determine.md)」を参照してください。 **注記** メジャーバージョンを省略することはできません。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 使用可能なアクションバージョンの一覧表示 次の手順に従って、ワークフローで使用できるアクションのバージョンを確認します。 ------ #### [ Visual ] **使用可能なアクションバージョンを確認するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. バージョンを表示するアクションを見つけます。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択するか、ワークフローを作成します。ワークフローの作成については、「[ワークフローの作成](workflows-create-workflow.md)」を参照してください。 1. **[編集]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから **[Amazon CodeCatalyst]** を選択し、CodeCatalyst、CodeCatalyst Labs、サードパーティーのアクションを表示するか、**[GitHub]** を選択して厳選された GitHub アクションを表示します。 1. アクションを検索し、その名前を選択します。プラス記号 (**\$1**) は選択しないでください。 アクションの詳細が表示されます。 1. アクションの詳細ダイアログボックスの右上付近で、**[バージョン]** ドロップダウンリストを選択して、使用可能なアクションのバージョンのリストを表示します。 ------ #### [ YAML ] *利用できません。「ビジュアル」を選択してビジュアルエディタの手順を表示してください。* ------ # アクションのソースコードの表示 アクションのソースコードを表示して、リスクの高いコード、セキュリティの脆弱性、またはその他の欠陥が含まれていないことを確認できます。 次の手順に従って、[CodeCatalyst](workflows-actions.md#workflows-actions-types-cc)、[CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs)、または[サードパーティー](workflows-actions.md#workflows-actions-types-3p)アクションのソースコードを表示します。 **注記** [GitHub Action](workflows-actions.md#workflows-actions-types-github) のソースコードを表示するには、[GitHub Marketplace](https://github.com/marketplace/actions) のアクションのページに移動します。このページには、アクションのソースコードを見つけることができるアクションのリポジトリへのリンクがあります。 **注記** CodeCatalyst アクションである[ビルド](build-workflow-actions.md)、[テスト](test-workflow-actions.md)、[GitHub Actions](integrations-github-action-add.md) のソースコードを表示することはできません。 **注記** AWS は、GitHub Actions またはサードパーティーのアクションのアクションコードをサポートまたは保証しません。 **アクションのソースコードを表示するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. コードを表示するアクションを見つけます。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択するか、ワークフローを作成します。ワークフローの作成については、「[ワークフローの作成](workflows-create-workflow.md)」を参照してください。 1. **[編集]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから **[Amazon CodeCatalyst]** を選択し、CodeCatalyst、CodeCatalyst Labs、およびサードパーティーのアクションを表示します。 1. アクションを検索し、その名前を選択します。プラス記号 (**\$1**) は選択しないでください。 アクションの詳細が表示されます。 1. アクションの詳細ダイアログボックスの下部近くで **[ダウンロード]** を選択します。 アクションのソースコードが存在する Amazon S3 バケットを示すページが表示されます。Amazon S3 の詳細については、*Amazon Simple Storage Service ユーザーガイド*の「[Amazon S3 とは](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)」を参照してください。 1. コードを調べて、品質とセキュリティに対する要件を満たしていることを確認します。 # GitHub Actions との統合 *GitHub Action* は [CodeCatalyst アクション](workflows-actions.md#workflows-actions-types-cc) とよく似ていますが、GitHub ワークフローで使用できるように開発されているという点が異なります。GitHub Actions の詳細については、[GitHub Actions](https://docs.github.com/en/actions) ドキュメントを参照してください。 GitHub Actions は、CodeCatalyst ワークフローのネイティブ CodeCatalyst アクションと併せて使用できます。 GitHub Action を CodeCatalyst ワークフローに追加するには、次の 2 つの方法があります。 + CodeCatalyst コンソールで、キュレートされたリストから GitHub Action を選択できます。いくつかのよく使用されている GitHub Actions が利用可能です。詳細については、「[キュレートされた GitHub Action を追加する](integrations-github-action-add-curated.md)」を参照してください。 + 使用したい GitHub Action が CodeCatalyst コンソールで利用できない場合は、**GitHub Actions** アクションを使用して追加できます。 ***GitHub Actions*** アクションとは、*CodeCatalyst* ワークフローと互換性を持たせるために GitHub Action をラップする CodeCatalyst アクションです。 次の例は、[Super-Linter](https://github.com/marketplace/actions/super-linter) GitHub Action をラップする **GitHub Actions** を示しています。 ``` Actions: GitHubAction: Identifier: aws/github-actions-runner@v1 Configuration: Steps: - name: Lint Code Base uses: github/super-linter@v4 env: VALIDATE_ALL_CODEBASE: "true" DEFAULT_BRANCH: main ``` 前のコードでは、CodeCatalyst **GitHub Actions** アクション (`aws/github-actions-runner@v1` で識別される) は Super-Linter アクション (`github/super-linter@v4` で識別される) をラップし、CodeCatalyst ワークフローで機能するようにしています。 詳細については、「[GitHub Actions アクションを追加する](integrations-github-action-add.md)」を参照してください。 上記の例に示したように、すべての GitHub Actions は、キュレートされているものもされていないものも、**GitHub Actions** アクション (`aws/github-actions-runner@v1`) 内にラップされていなければなりません。アクションが正しく機能するには、ラッパーが必要です。 **Topics** + [GitHub Actions と CodeCatalyst アクションの違い](#integrations-github-actions-how-different) + [GitHub Actions はワークフロー内の他の CodeCatalyst アクションとやりとりできますか?](#integrations-github-actions-interactions.title) + [どの GitHub Actions を使用できますか?](#integrations-github-actions-supported) + [CodeCatalyst における GitHub Action の制限事項](#integrations-github-actions-limitations) + [GitHub Action を追加する大まかな手順](#integrations-github-actions-how-to) + [GitHub Action は GitHub で実行されますか?](#integrations-github-actions-where-it-runs) + [GitHub ワークフローを使用することもできますか?](#integrations-github-actions-workflows-support.title) + [GitHub Actions アクションで使用されるランタイムイメージ](#integrations-github-actions-runtime) + [チュートリアル: GitHub Action を使用した lint コード](integrations-github-action-tutorial.md) + [GitHub Actions アクションを追加する](integrations-github-action-add.md) + [キュレートされた GitHub Action を追加する](integrations-github-action-add-curated.md) + [GitHub 出力パラメータをエクスポートする](integrations-github-action-export.md) + [GitHub 出力パラメータを参照する](integrations-github-action-referencing.md) + [GitHub Actions アクション YAML](github-action-ref.md) ## GitHub Actions と CodeCatalyst アクションの違い CodeCatalyst ワークフロー内で使用される GitHub Actions には、CodeCatalyst アクションと同じレベルのアクセス AWS と CodeCatalyst 機能 ([環境](deploy-environments.md)や[問題](issues.md)など) との統合はありません。 CodeCatalyst ## GitHub Actions はワークフロー内の他の CodeCatalyst アクションとやりとりできますか? はい。例えば、GitHub Actions は、他の CodeCatalyst アクションによって生成された変数を入力として使用でき、出力パラメータとアーティファクトを CodeCatalyst アクションと共有することもできます。詳細については、「[GitHub 出力パラメータをエクスポートする](integrations-github-action-export.md)」および「[GitHub 出力パラメータを参照する](integrations-github-action-referencing.md)」を参照してください。 ## どの GitHub Actions を使用できますか? CodeCatalyst コンソールから利用可能な任意の GitHub Action、および [GitHub Marketplace](https://github.com/marketplace/actions) で利用可能な任意の GitHub Action を使用できます。Marketplace の GitHub Action を使用する場合は、以下の[制限](#integrations-github-actions-limitations)に注意してください。 ## CodeCatalyst における GitHub Action の制限事項 + GitHub Actions は CodeCatalyst [Lambda コンピューティングタイプ](workflows-working-compute.md#compute.types)で使用できません。 + GitHub Actions は [2022 年 11 月](build-images.md#build.previous-image)のランタイム環境 Docker イメージで実行されており、このイメージには古いツールが含まれています。イメージやツールの詳細については、「[ランタイム環境イメージの指定](build-images.md)」を参照してください。 + [`github` コンテキスト](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context)に内部的に依存する GitHub Actions や、GitHub 固有のリソースを参照する GitHub Actions は、CodeCatalyst ではサポートされていません。例えば、次のアクションは CodeCatalyst では機能しません。 + GitHub リソースを追加、変更、または更新しようとするアクション。例としては、プルリクエストを更新するアクション、GitHub で問題を作成するアクションなどがあります。 + [https://github.com/actions](https://github.com/actions) にリストされているほぼすべてのアクション。 + [Docker コンテナアクション](https://docs.github.com/en/actions/creating-actions/about-custom-actions#docker-container-actions)である GitHub Actions は機能しますが、デフォルトの Docker ユーザー (root) で実行する必要があります。ユーザー 1001 としてアクションを実行しないでください (本文執筆時点では、ユーザー 1001 は GitHub で機能しますが、CodeCatalyst では機能しません)。詳細については、「[GitHub Actions のための Dockerfile サポート](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions)」で「[User](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions#user)」トピックを参照してください。 CodeCatalyst コンソールで利用可能な GitHub Actions の一覧については、「[キュレートされた GitHub Action を追加する](integrations-github-action-add-curated.md)」を参照してください。 ## GitHub Action を追加する大まかな手順 GitHub Action を CodeCatalyst ワークフローに追加する大まかな手順は次のとおりです。 1. CodeCatalyst プロジェクトで、**ワークフローを作成します**。ワークフローでは、アプリケーションをビルド、テスト、デプロイする方法を定義します。詳細については、「[初めてのワークフロー](workflows-getting-started.md)」を参照してください。 1. ワークフローで、**キュレートされた GitHub Action を追加する**か、**GitHub Actions** アクションを追加します。 1. 次のいずれかを行います。 + キュレートされたアクションを追加する場合は、そのアクションを設定します。詳細については、「[キュレートされた GitHub Action を追加する](integrations-github-action-add-curated.md)」を参照してください。 + キュレートされたアクション以外を追加する場合は、**GitHub Actions** アクション内に、**GitHub Action の YAML コード を貼り付けます**。このコードは、[GitHub Marketplace](https://github.com/marketplace/actions) の該当する GitHub Action の詳細ページにあります。CodeCatalyst で動作させるには、おそらくコードを少し変更する必要があります。詳細については、「[GitHub Actions アクションを追加する](integrations-github-action-add.md)」を参照してください。 1. (オプション) ワークフロー内で、ビルドアクションやテストアクションなどの**他のアクションを追加します**。詳細については、「[ワークフローを使用して構築、テスト、デプロイするワークフローを使用して構築、テスト、デプロイする](workflow.md)」を参照してください。 1. **ワークフローの開始**は、手動で行うか、トリガーを介して自動で行います。ワークフローは、GitHub Action とワークフロー内の他のアクションを実行します。詳細については、「[手動でのワークフロー実行の開始](workflows-manually-start.md)」を参照してください。 詳細なステップについては、次を参照してください。 + [キュレートされた GitHub Action を追加する](integrations-github-action-add-curated.md). + [GitHub Actions アクションを追加する](integrations-github-action-add.md). ## GitHub Action は GitHub で実行されますか? いいえ。GitHub Action は CodeCatalyst の[ランタイム環境イメージ](workflows-working-compute.md)を使用して CodeCatalyst で実行されます。 ## GitHub ワークフローを使用することもできますか? いいえ。 ## GitHub Actions アクションで使用されるランタイムイメージ CodeCatalyst **GitHub Actions** アクションは、[2022 年 11 月のイメージ](build-images.md#build.previous-image)で実行されます。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。 # チュートリアル: GitHub Action を使用した lint コード このチュートリアルでは、Amazon CodeCatalyst ワークフローに [Super-Linter GitHub Action](https://github.com/marketplace/actions/super-linter) を追加します。Super-Linter アクションは、コードを検査し、コードにエラー、フォーマットの問題、疑わしいコンストラクトがある領域を見つけて、その結果を CodeCatalyst コンソールに出力します。ワークフローに linter を追加したら、ワークフローを実行してサンプル Node.js アプリケーション (`app.js`) を lint します。次に、報告された問題を修正し、ワークフローを再度実行して、修正がうまくいったかどうかを確認します。 **ヒント** Super-Linter を使用して、[CloudFormation テンプレート](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)などの YAML ファイルを lint することを検討してください。 **Topics** + [前提条件](#integrations-github-action-tutorial-prereqs) + [ステップ 1: ソースレポジトリを作成する](#integrations-github-action-tutorial-create-source-repo) + [ステップ 2: app.js ファイルを追加する](#integrations-github-action-tutorial-add-appjs) + [ステップ 3: Super-Linter アクションを実行するワークフローを作成する](#integrations-github-action-tutorial-create-workflow) + [ステップ 4: Super-Linter が検出した問題を修正する](#integrations-github-action-tutorial-fix-probs) + [クリーンアップ](#integrations-github-action-tutorial-cleanup) ## 前提条件 開始するには、以下のものが必要です。 + が接続された CodeCatalyst **スペース** AWS アカウント。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。 + CodeCatalyst スペース内の `codecatalyst-linter-project` という空のプロジェクト。このプロジェクトを作成するには、**[ゼロから開始]** オプションを選択します。 ``` ``` 詳細については、「[Amazon CodeCatalyst での空のプロジェクトの作成](projects-create.md#projects-create-empty)」を参照してください。 ## ステップ 1: ソースレポジトリを作成する このステップでは、CodeCatalyst に空のソースリポジトリを作成します。このリポジトリを使用して、このチュートリアルのサンプルアプリケーションソースファイル `app.js` を保存します。 ソースリポジトリの詳細については、「[ソースリポジトリを作成する](source-repositories-create.md)」を参照してください。 **ソースリポジトリを作成するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクト「`codecatalyst-linter-project`」に移動します。 1. ナビゲーションペインで **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。 1. **[リポジトリの追加]** を選択し、**[リポジトリの作成]** を選択します。 1. **[リポジトリ名]** に次のように入力します。 ``` codecatalyst-linter-source-repository ``` 1. **[作成]** を選択します。 ## ステップ 2: app.js ファイルを追加する このステップでは、`app.js` ファイルをソースリポジトリに追加します。`app.js` にはいくつかの誤りがある関数コードが含まれており、これが linter によって検出されます。 **app.js ファイルを追加するには** 1. CodeCatalyst コンソールで、プロジェクト `codecatalyst-linter-project` を選択します。 1. ナビゲーションペインで **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。 1. ソースリポジトリのリストから、リポジトリ `codecatalyst-linter-source-repository` を選択します。 1. **[ファイル]** で、**[ファイルを作成]** を選択します。 1. テキストボックスに次のコードを入力します。 ``` // const axios = require('axios') // const url = 'http://checkip.amazonaws.com/'; let response; /** * * Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format * @param {Object} event - API Gateway Lambda Proxy Input Format * * Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html * @param {Object} context * * Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html * @returns {Object} object - API Gateway Lambda Proxy Output Format * */ exports.lambdaHandler = async (event, context) => { try { // const ret = await axios(url); response = { statusCode: 200, 'body': JSON.stringify({ message: 'hello world' // location: ret.data.trim() }) } } catch (err) { console.log(err) return err } return response } ``` 1. **[ファイル名]** に `app.js` と入力します。その他のオプションはデフォルトのままにします。 1. **[コミット]** を選択します。 これで、`app.js` と呼ばれる新しいファイルが作成されました。 ## ステップ 3: Super-Linter アクションを実行するワークフローを作成する このステップでは、ソースリポジトリにコードをプッシュするときに Super-Linter アクションを実行するワークフローを作成します。ワークフローは、YAML ファイルで定義する以下の要素で構成されます。 + **トリガー** – このトリガーは、ソースリポジトリに変更をプッシュすると、ワークフローの実行を自動的に開始します。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 + **GitHub Actions アクション** - トリガー時に、**GitHub Actions** アクションは Super-Linter アクションを実行し、ソースリポジトリ内のすべてのファイルを検査します。linter で問題が検出されると、ワークフローアクションは失敗します。 **Super-Linter アクションを実行するワークフローを作成するには** 1. CodeCatalyst コンソールで、プロジェクト `codecatalyst-linter-project` を選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ワークフローを作成]** を選択します。 1. **[ソースリポジトリ]** で、`codecatalyst-linter-source-repository` を選択します。 1. **[ブランチ]** で、`main` を選択します。 1. **[作成]** を選択します。 1. YAML サンプルコードを削除します。 1. 次の YAML を追加します。 ``` Name: codecatalyst-linter-workflow SchemaVersion: "1.0" Triggers: - Type: PUSH Branches: - main Actions: SuperLinterAction: Identifier: aws/github-actions-runner@v1 Configuration: Steps: github-action-code ``` 上記のコードで、この手順の次のステップで指示されているように、*github-action-code* を Super-Linter アクションコードに置き換えます。 1. GitHub Marketplace の [Super-Linter のページ](https://github.com/marketplace/actions/super-linter)に移動します。 1. `steps:` (小文字) の下にあるコードを見つけ、CodeCatalyst ワークフローの `Steps:` (大文字) に貼り付けます。 次のコードに示すように、GitHub Action コードを CodeCatalyst の規格に準拠するように調整します。 CodeCatalyst ワークフローは次のようになります。 ``` Name: codecatalyst-linter-workflow SchemaVersion: "1.0" Triggers: - Type: PUSH Branches: - main Actions: SuperLinterAction: Identifier: aws/github-actions-runner@v1 Configuration: Steps: - name: Lint Code Base uses: github/super-linter@v4 env: VALIDATE_ALL_CODEBASE: "true" DEFAULT_BRANCH: main ``` 1. (任意) **[検証]** を選択して、コミットする前に YAML コードが有効であることを確認します。 1. **[コミット]** を選択して **[コミットメッセージ]** を入力し、`codecatalyst-linter-source-repository` **[リポジトリ]** を選択して再度 **[コミット]** を選択します。 これでワークフローが作成されました。ワークフローの先頭で定義されているトリガーにより、ワークフローの実行が自動的に開始されます。 **ワークフロー実行の進行状況を確認するには** 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. 先ほど作成したワークフロー `codecatalyst-linter-workflow` を選択します。 1. ワークフロー図で、**SuperLinterAction** を選択します。 1. アクションが失敗するのを待ちます。この失敗は想定されるもので、linter でコードに問題が検出されたためです。 1. CodeCatalyst コンソールを開いたままにして、「[ステップ 4: Super-Linter が検出した問題を修正する](#integrations-github-action-tutorial-fix-probs)」に進みます。 ## ステップ 4: Super-Linter が検出した問題を修正する Super-Linter で、ソースリポジトリに含まれる `README.md` ファイルだけでなく、`app.js`コードにも問題が検出されているはずです。 **linter が見つけた問題を修正するには** 1. CodeCatalyst コンソールで、**[ログ]** タブにある **[lint コードベース]** を選択します。 Super-Linter アクションで生成されたログが表示されます。 1. Super-Linter ログで、問題が始まる 90 行目付近までスクロールダウンします。次のような内容です。 ``` /github/workspace/hello-world/app.js:3:13: Extra semicolon. /github/workspace/hello-world/app.js:9:92: Trailing spaces not allowed. /github/workspace/hello-world/app.js:21:7: Unnecessarily quoted property 'body' found. /github/workspace/hello-world/app.js:31:1: Expected indentation of 2 spaces but found 4. /github/workspace/hello-world/app.js:32:2: Newline required at end of file but not found. ``` 1. ソースリポジトリの `app.js` と `README.md` を修正し、変更をコミットします。 **ヒント** `README.md` を修正するには、次のように `markdown` をコードブロックに追加します。 ``` ```markdown Setup examples: ... ``` ``` 変更により、別のワークフローが自動的に実行されます。ワークフローが終了するのを待ちます。すべての問題を修正すると、ワークフローが成功します。 ## クリーンアップ CodeCatalyst でクリーンアップを行い、このチュートリアルの作業内容を環境から削除します。 **CodeCatalyst でクリーンアップを行うには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. `codecatalyst-linter-source-repository` を削除します。 1. `codecatalyst-linter-workflow` を削除します。 このチュートリアルでは、一部のコードを lint するために Super-Linter GitHub Action を CodeCatalyst ワークフローに追加する方法を学習しました。 # GitHub Actions アクションを追加する ***GitHub Actions*** アクションとは、*CodeCatalyst* ワークフローと互換性を持たせるために GitHub Action をラップする CodeCatalyst アクションです。 詳細については、「[GitHub Actions との統合](integrations-github-actions.md)」を参照してください。 **GitHub Actions** アクションをワークフローに追加する手順は次のとおりです。 **ヒント** **GitHub Actions** アクションの使用方法を示すチュートリアルについては、「[チュートリアル: GitHub Action を使用した lint コード](integrations-github-action-tutorial.md)」を参照してください。 ------ #### [ Visual ] **ビジュアルエディタを使用して GitHub Actions アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから **[GitHub]** を選択します。 1. **GitHub Actions** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。 または + **[GitHub Actions]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. **[入力]** タブと **[設定]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[GitHub Actions アクション YAML](github-action-ref.md)」を参照してください。このリファレンスでは、各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用して GitHub Actions アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから **[GitHub]** を選択します。 1. **GitHub Actions** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。 または + **[GitHub Actions]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[GitHub Actions アクション YAML](github-action-ref.md)」に記載されています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ ## GitHub Actions アクションの定義 **GitHub Actions** アクションは、ワークフロー定義ファイル内の一連の YAML プロパティとして定義されます。これらのプロパティの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」の「[GitHub Actions アクション YAML](github-action-ref.md)」を参照してください。 # キュレートされた GitHub Action を追加する *キュレートされた GitHub Action* とは、CodeCatalyst コンソールで利用できる GitHub Action であり、CodeCatalyst ワークフロー内で GitHub Action を使用する方法の例として機能します。 キュレートされた GitHub Actions は、`aws/github-actions-runner@v1` 識別子で識別される、CodeCatalyst によって作成された [**GitHub Actions** アクション](integrations-github-action-add.md)でラップされます。例えば、キュレートされた GitHub Action である [TruffleHog OSS](https://github.com/marketplace/actions/trufflehog-oss) は次のようになります。 ``` Actions: TruffleHogOSS_e8: Identifier: aws/github-actions-runner@v1 Inputs: Sources: - WorkflowSource # This specifies that the action requires this Workflow as a source Configuration: Steps: - uses: trufflesecurity/trufflehog@v3.16.0 with: path: ' ' # Required; description: Repository path base: ' ' # Required; description: Start scanning from here (usually main branch). head: ' ' # Optional; description: Scan commits until here (usually dev branch). extra_args: ' ' # Optional; description: Extra args to be passed to the trufflehog cli. ``` 前のコードでは、CodeCatalyst **GitHub Actions** アクション (`aws/github-actions-runner@v1` で識別される) は TruffleHog OSS アクション (`trufflesecurity/trufflehog@v3.16.0` で識別される) をラップし、CodeCatalyst ワークフローで機能するようにしています。 このアクションを設定するには、`with:` の下にある空の文字列を実際の値に置き換えます。例えば、次のようになります。 ``` Actions: TruffleHogOSS_e8: Identifier: aws/github-actions-runner@v1 Inputs: Sources: - WorkflowSource # This specifies that the action requires this Workflow as a source Configuration: Steps: - uses: trufflesecurity/trufflehog@v3.16.0 with: path: ./ base: main # Required; description: Start scanning from here (usually main branch). head: HEAD # Optional; description: Scan commits until here (usually dev branch). extra_args: '‐‐debug ‐‐only-verified' # Optional; description: Extra args to be passed to the trufflehog cli. ``` キュレートされた GitHub Action をワークフローに追加する手順は次のとおりです。CodeCatalyst ワークフローでの GitHub Action の使用に関する一般的な情報については、「[GitHub Actions との統合](integrations-github-actions.md)」を参照してください。 **注記** キュレートされたアクションのリストに GitHub Action が表示されない場合は、**GitHub Actions** アクションを使用してワークフローに追加できます。詳細については、「[GitHub Actions アクションを追加する](integrations-github-action-add.md)」を参照してください。 ------ #### [ Visual ] **ビジュアルエディタを使用してキュレートされた GitHub Action を追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから **[GitHub]** を選択します。 1. GitHub Action を参照または検索し、次のいずれかを実行します。 + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。 または + GitHub Action の名前を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. **[入力]**、**[設定]**、**[出力]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[GitHub Actions アクション YAML](github-action-ref.md)」を参照してください。このリファレンスでは、**GitHub Actions** アクションで利用可能な各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。 キュレートされた GitHub Action で使用できる設定オプションについては、該当するドキュメントを参照してください。 1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用してキュレートされた GitHub アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから **[GitHub]** を選択します。 1. GitHub Action を参照または検索し、次のいずれかを実行します。 + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。 または + GitHub Action の名前を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. 必要に応じて、YAML コードのプロパティを変更します。**GitHub Actions** アクションで使用可能な各プロパティの説明は、「[GitHub Actions アクション YAML](github-action-ref.md)」に記載されています。 キュレートされた GitHub Action で使用できる設定オプションについては、該当するドキュメントを参照してください。 1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # GitHub 出力パラメータをエクスポートする CodeCatalyst ワークフローで [GitHub 出力パラメータ](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter)を使用できます。 **注記** *出力パラメータ*の別の呼び方は*変数*です。GitHub はドキュメントで*出力パラメータ*という用語を使用しているため、ここでもこの用語を使用します。 以下の手順に従って GitHub 出力パラメータを GitHub Action からエクスポートし、他の CodeCatalyst ワークフローアクションで使用できるようにします。 **GitHub 出力パラメータをエクスポートするには** 1. ワークフローを開き、**[編集]** を選択します。詳細については、「[ワークフローの作成](workflows-create-workflow.md)」を参照してください。 1. エクスポートする出力パラメータを生成する **GitHub Actions** アクションで、次のような `Variables` プロパティを下位に持つ `Outputs` セクションを追加します。 ``` Actions: MyGitHubAction: Identifier: aws/github-actions-runner@v1 Outputs: Variables: - 'step-id_output-name' ``` 置換: + *step-id* を GitHub Action の `steps` セクションの `id:` プロパティの値で置き換えます。 + *output-name* を GitHub 出力パラメータの名前で置き換えます。 **例** 次の例は、`SELECTEDCOLOR` という GitHub 出力パラメータをエクスポートする方法を示しています。 ``` Actions: MyGitHubAction: Identifier: aws/github-actions-runner@v1 Outputs: Variables: - 'random-color-generator_SELECTEDCOLOR' Configuration: Steps: - name: Set selected color run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT id: random-color-generator ``` # GitHub 出力パラメータを参照する GitHub 出力パラメータを参照する手順は次のとおりです。 **GitHub 出力パラメータを参照するには** 1. 「[GitHub 出力パラメータをエクスポートする](integrations-github-action-export.md)」のステップを完了します。 GitHub 出力パラメータが他のアクションで使用できるようになりました。 1. 出力パラメータの `Variables` の値に注意してください。アンダースコア (\$1) が含まれています。 1. 次の構文を使用して出力パラメータを参照します。 ``` ${action-name.output-name} ``` 置き換え前: + *action-name* は、出力パラメータを生成する CodeCatalyst **GitHub Action** の名前で置き換えます (GitHub アクションの `name` または `id` は使用しないでください)。 + *output-name* は、前にメモした出力パラメータの `Variables` の値で置き換えます。 **例** ``` BuildActionB: Identifier: aws/build@v1 Configuration: Steps: - Run: echo ${MyGitHubAction.random-color-generator_SELECTEDCOLOR} ``` **コンテキストを含む例** 次の例は、`GitHubActionA` で `SELECTEDCOLOR` 変数を設定して出力し、`BuildActionB` で参照する方法を示しています。 ``` Actions: GitHubActionA: Identifier: aws/github-actions-runner@v1 Configuration: Steps: - name: Set selected color run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT id: random-color-generator Outputs: Variables: - 'random-color-generator_SELECTEDCOLOR' BuildActionB: Identifier: aws/build@v1 Configuration: Steps: - Run: echo ${GitHubActionA.random-color-generator_SELECTEDCOLOR} ``` # GitHub Actions アクション YAML 以下は、**GitHub Actions** アクションの YAML 定義です。 このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 次のコード内で YAML プロパティを選択すると、説明が表示されます。 **注記** 後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティと共に一覧表示されます。 ``` # The workflow definition starts here. # See 最上位プロパティ for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. action-name: Identifier: aws/github-actions-runner@v1 DependsOn: - dependent-action-name-1 Compute: Fleet: fleet-name Timeout: timeout-minutes Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Inputs: Sources: - source-name-1 - source-name-2 Artifacts: - artifact-name Variables: - Name: variable-name-1 Value: variable-value-1 - Name: variable-name-2 Value: variable-value-2 Outputs: Artifacts: - Name: output-artifact-1 Files: - github-output/artifact-1.jar - "github-output/build*" - Name: output-artifact-2 Files: - github-output/artifact-2.1.jar - github-output/artifact-2.2.jar Variables: - variable-name-1 - variable-name-2 AutoDiscoverReports: Enabled: true | false ReportNamePrefix: AutoDiscovered IncludePaths: - "**/*" ExcludePaths: - node_modules/cdk/junit.xml SuccessCriteria: PassRate: percent LineCoverage: percent BranchCoverage: percent Vulnerabilities: Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL Number: whole-number Reports: report-name-1: Format: format IncludePaths: - "*.xml" ExcludePaths: - report2.xml - report3.xml SuccessCriteria: PassRate: percent LineCoverage: percent BranchCoverage: percent Vulnerabilities: Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL Number: whole-number Configuration Steps: - github-actions-code ``` ## action-name (必須) アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名で特殊文字やスペースを有効にすることはできません。 対応する UI: [設定] タブ/*[action-name]* ## Identifier (*action-name*/**Identifier**) アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。 **GitHub Actions** アクションには `aws/github-actions-runner@v1` を使用します。 対応する UI: ワークフロー図/*action-name*/**aws/github-actions-runner@v1** ラベル ## DependsOn (*action-name*/**DependsOn**) (オプション) このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。 「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。 対応する UI: [入力] タブ/**[依存 - オプション]** ## Compute (*action-name*/**Compute**) (オプション) ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。 対応する UI: *なし* ## Fleet (*action-name*/Compute/**Fleet**) (オプション) ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。 プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 `Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。 対応する UI: [設定] タブ/**[コンピューティングフリート - オプション]** ## Timeout (*action-name*/**Timeout**) (オプション) CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。 対応する UI: [設定] タブ/**[タイムアウト - オプション]** ## Environment (*action-name*/**Environment**) (オプション) アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウント およびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用して に接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。 **注記** デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。 環境タグ付けの詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 対応する UI: [設定] タブ/**[環境]** ## Name (*action-name*/Environment/**Name**) ([Environment](#github.environment) が含まれている場合は必須) アクションに関連付ける既存の環境の名前を指定します。 対応する UI: [設定] タブ/**[環境]** ## Connections (*action-name*/Environment/**Connections**) (オプション) アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。 アカウント接続を指定しない場合: + アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント 接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 + デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。 アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 対応する UI: [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** ## Name (*action-name*/Environment/Connections/**Name**) ([Connections](#github.environment.connections) が含まれている場合は必須) アカウント接続の名前を指定します。 対応する UI: [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** ## Role (*action-name*/Environment/Connections/**Role**) ([Connections](#github.environment.connections) が含まれている場合は必須) Amazon S3 や Amazon ECR などの AWS のサービスにアクセスして操作するために、このアクションが使用する IAM ロールの名前を指定します。このロールがスペースの AWS アカウント 接続に追加されていることを確認します。アカウント接続に IAM ロールを追加するには、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。 IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、次のポリシーが設定されていることを確認してください。 **注記** このアクションでは、`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。 **警告** アクセス許可は、**GitHub Action** アクションに必要なアクセス許可に制限します。範囲の広いアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。 対応する UI: [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** ## Inputs (*action-name*/**Inputs**) (オプション) `Inputs` セクションは、ワークフローの実行中にアクションに必要なデータを定義します。 **注記** **GitHub Actions** アクションごとに最大 4 つの入力 (1 つのソースと 3 つのアーティファクト) が許可されます。変数はこの合計にはカウントされません。 異なる入力 (ソースとアーティファクトなど) にあるファイルを参照する必要がある場合、ソース入力はプライマリ入力で、アーティファクトはセカンダリ入力になります。セカンダリ入力内のファイルへの参照には、プライマリからファイルを区別するための特別なプレフィックスが付きます。詳細については、「[例: 複数のアーティファクトでのファイルの参照](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file)」を参照してください。 対応する UI: **[入力] タブ** ## Sources (*action-name*/Inputs/**Sources**) (オプション) アクションに必要なソースリポジトリを表すラベルを指定します。現在、サポートされているラベルは `WorkflowSource` のみです。これは、ワークフロー定義ファイルが保存されているソースリポジトリを表します。 ソースを省略する場合は、`action-name/Inputs/Artifacts` で少なくとも 1 つの入力アーティファクトを指定する必要があります。 sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。 対応する UI: [入力] タブ/**[ソース - オプション]** ## Artifacts - input (*action-name*/Inputs/**Artifacts**) (オプション) このアクションへの入力として提供する以前のアクションのアーティファクトを指定します。これらのアーティファクトは、前のアクションで出力アーティファクトとして既に定義されている必要があります。 入力アーティファクトを指定しない場合は、`action-name/Inputs/Sources` で少なくとも 1 つのソースリポジトリを指定する必要があります。 アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 **注記** **[アーティファクト - オプション]** のドロップダウンリストが使用できない場合 (ビジュアルエディタ)、または YAML の検証時にエラーが発生する場合 (YAML エディタ)、アクションが 1 つの入力のみをサポートしていることが原因である可能性があります。この場合はソース入力を削除してみてください。 対応する UI: [入力] タブ/**[アーティファクト - オプション]** ## Variables - input (*action-name*/Inputs/**Variables**) (オプション) アクションで使用できるようにしたい入力変数を定義する名前と値のペアのシーケンスを指定します。変数名に使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、変数名で特殊文字とスペースを有効にすることはできません。 変数の詳細 (例を含む) については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 対応する UI: [入力] タブ/**[変数 - オプション]** ## Outputs (*action-name*/**Outputs**) (オプション) ワークフローの実行中にアクションによって出力されるデータを定義します。 対応する UI: **[出力]** タブ ## Artifacts - output (*action-name*/Outputs/**Artifacts**) (オプション) アクションによって生成されるアーティファクトの名前を指定します。アーティファクト名はワークフロー内で一意でなければならず、英数字 (a～z、A～Z、0～9) とアンダースコア (\$1) しか使用できません。スペース、ハイフン (-)、その他の特殊文字は使用できません。引用符を使用して、出力アーティファクト名でスペース、ハイフン、その他の特殊文字を有効にすることはできません。 アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 対応する UI: [出力] タブ/**[アーティファクト]** ## Name (*action-name*/Outputs/Artifacts/**Name**) ([Artifacts - output](#github.outputs.artifacts) が含まれている場合は必須) アクションによって生成されるアーティファクトの名前を指定します。アーティファクト名はワークフロー内で一意でなければならず、英数字 (a～z、A～Z、0～9) とアンダースコア (\$1) しか使用できません。スペース、ハイフン (-)、その他の特殊文字は使用できません。引用符を使用して、出力アーティファクト名でスペース、ハイフン、その他の特殊文字を有効にすることはできません。 アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 対応する UI: [出力] タブ/[アーティファクト]/[アーティファクトを追加]/**[ビルドアーティファクト名]** ## Files (*action-name*/Outputs/Artifacts/**Files**) ([Artifacts - output](#github.outputs.artifacts) が含まれている場合は必須) CodeCatalyst がアクションによって出力されるアーティファクトに含めるファイルを指定します。これらのファイルは、実行時にワークフローアクションによって生成され、ソースリポジトリでも使用できます。ファイルパスは、ソースリポジトリまたは前のアクションからのアーティファクトに設定でき、ソースリポジトリまたはアーティファクトルートを基準とすることができます。glob パターンを使用してパスを指定できます。例: + ビルドまたはソースリポジトリの場所のルートにある 1 つのファイルを指定するには、`my-file.jar` を使用します。 + サブディレクトリ内の 1 つのファイルを指定するには、`directory/my-file.jar` または `directory/subdirectory/my-file.jar` を使用します。 + すべてのファイルを指定するには、`"**/*"` を使用します。glob パターン `**` は、任意の数のサブディレクトリにマッチすることを示します。 + `directory` という名前のディレクトリ内のすべてのファイルとディレクトリを指定するには、`"directory/**/*"` を使用します。glob パターン `**` は、任意の数のサブディレクトリにマッチすることを示します。 + `directory` という名前のディレクトリ内のすべてのファイルを指定するが、そのサブディレクトリを含めないようにするには、`"directory/*"` を使用します。 **注記** ファイルパスに 1 つ以上のアスタリスク (`*`) またはその他の特殊文字が含まれている場合は、パスを二重引用符 (`""`) で囲みます。特殊文字の詳細については、「[構文ガイドラインと規則](workflow-reference.md#workflow.terms.syntax.conv)」を参照してください。 アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 **注記** 場合によっては、ファイルパスにプレフィックスを追加して、どのアーティファクトまたはソースにあるのかを示す必要があります。詳細については、「[ソースリポジトリファイルの参照](workflows-sources-reference-files.md)」および「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。 対応する UI: [出力] タブ/[アーティファクト]/[アーティファクトを追加]/**[ビルドで生成されるファイル]** ## Variables - output (*action-name*/Outputs/**Variables**) (オプション) 後続のアクションで使用できるように、アクションがエクスポートする変数を指定します。 変数の詳細 (例を含む) については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 対応する UI: [出力] タブ/[変数]/**[変数を追加]** ## variable-name-1 (*action-name*/Outputs/Variables**variable-name-1**) (オプション) アクションでエクスポートする変数の名前を指定します。この変数は、同じアクションの `Inputs` セクションか `Steps` セクションであらかじめ定義されている必要があります。 変数の詳細 (例を含む) については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 対応する UI: [出力] タブ/[変数]/[変数を追加]/**[名前]** ## AutoDiscoverReports (*action-name*/Outputs/**AutoDiscoverReports**) (オプション) 自動検出機能の設定を定義します。 自動検出を有効にすると、CodeCatalyst はアクションに渡されたすべての `Inputs` と、アクション自体によって生成されたすべてのファイルを検索し、テストレポート、コードカバレッジレポート、ソフトウェアコンポジション分析 (SCA) レポートを探します。検出された各レポートは、CodeCatalyst レポートに変換されます。*CodeCatalyst レポート*は、CodeCatalyst サービスに完全に統合されており、CodeCatalyst コンソールを介して表示および操作できます。 **注記** デフォルトでは、自動検出機能はすべてのファイルを検査します。[IncludePaths](#github.reports.includepaths) または [ExcludePaths](#github.reports.excludepaths) プロパティを使用して、検査するファイルを制限できます。 対応する UI: *なし* ## Enabled (*action-name*/Outputs/AutoDiscoverReports/**Enabled**) (オプション) 自動検出機能を有効または無効にします。 有効な値は `true` または `false` です。 `Enabled` を省略した場合、デフォルトは `true` です。 対応する UI: [出力] タブ/[レポート]/**[レポートを自動的に検出]** ## ReportNamePrefix (*action-name*/Outputs/AutoDiscoverReports/**ReportNamePrefix**) ([AutoDiscoverReports](#github.outputs.autodiscover) が含まれ、有効になっている場合は必須) 関連する CodeCatalyst レポートに名前を付けるために、CodeCatalyst が検出したすべてのレポートに付加するプレフィックスを指定します。例えば、プレフィックスを `AutoDiscovered` に指定し、CodeCatalyst が 2 つのテストレポート、`TestSuiteOne.xml`、`TestSuiteTwo.xml` を自動的に検出する場合、関連する CodeCatalyst レポートには `AutoDiscoveredTestSuiteOne` と `AutoDiscoveredTestSuiteTwo` という名前が付けられます。 対応する UI: [出力] タブ/[レポート]/[レポートを自動的に検出]/**[レポートのプレフィックス]** ## IncludePaths (*action-name*/Outputs/AutoDiscoverReports/**IncludePaths**) または (*action-name*/Outputs/Reports/*report-name-1*/**IncludePaths**) ([AutoDiscoverReports](#github.outputs.autodiscover) が含まれ、有効になっている場合、または [Reports](#github.configuration.reports) が含まれている場合は必須) CodeCatalyst が未加工レポートを検索するときに含めるファイルとファイルパスを指定します。例えば、`"/test/report/*"` を指定すると、CodeCatalyst は `/test/report/*` ディレクトリを検索するアクションで使用される[ビルドイメージ](build-images.md)全体を検索します。そのディレクトリが見つかると、CodeCatalyst はそのディレクトリ内のレポートを検索します。 **注記** ファイルパスに 1 つ以上のアスタリスク (`*`) またはその他の特殊文字が含まれている場合は、パスを二重引用符 (`""`) で囲みます。特殊文字の詳細については、「[構文ガイドラインと規則](workflow-reference.md#workflow.terms.syntax.conv)」を参照してください。 このプロパティを省略した場合、デフォルトは `"**/*"` です。つまり、検索にはすべてのパスのすべてのファイルが含まれます。 **注記** 手動で設定するレポートの場合、`IncludePaths` は単一のファイルに一致する glob パターンである必要があります。 対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/[パスを含める/除外する]/**[パスを含める]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/[パスを含める/除外する]/**[パスを含める]** ## ExcludePaths (*action-name*/Outputs/AutoDiscoverReports/**ExcludePaths**) または (*action-name*/Outputs/Reports/*report-name-1*/**ExcludePaths**) (オプション) 未加工レポートを検索するときに CodeCatalyst が除外するファイルとファイルパスを指定します。例えば、`"/test/my-reports/**/*"` を指定した場合、CodeCatalyst は `/test/my-reports/` ディレクトリ内のファイルを検索しません。ディレクトリ内のすべてのファイルを無視するには、`**/*` glob パターンを使用します。 **注記** ファイルパスに 1 つ以上のアスタリスク (`*`) またはその他の特殊文字が含まれている場合は、パスを二重引用符 (`""`) で囲みます。特殊文字の詳細については、「[構文ガイドラインと規則](workflow-reference.md#workflow.terms.syntax.conv)」を参照してください。 対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/[パスを含める/除外する]/**[パスを除外する]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/[パスを含める/除外する]/**[パスを除外する]** ## SuccessCriteria (*action-name*/Outputs/AutoDiscoverReports/**SuccessCriteria**) または (*action-name*/Outputs/Reports/*report-name-1*/**SuccessCriteria**) (オプション) テストレポート、コードカバレッジレポート、ソフトウェアコンポジション分析 (SCA) レポート、静的分析 (SA) レポートの成功基準を指定します。 詳細については、「[レポートの成功基準の設定](test-config-action.md#test.success-criteria)」を参照してください。 対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/**[成功基準]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/**[成功基準]** ## PassRate (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**PassRate**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**PassRate**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるために、テストレポート内のテストに求められる合格の割合を指定します。有効な値には 10 進数が含まれます。例: `50`、`60.5`。パスレートの基準は、テストレポートにのみ適用されます。テストレポートの詳細については、「[テストレポート](test-workflow-actions.md#test-reports)」を参照してください。 対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/[成功基準]/**[パスレート]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/[成功基準]/**[パスレート]** ## LineCoverage (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**LineCoverage**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**LineCoverage**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるために、コードカバレッジレポート内でカバーする必要がある行の割合を指定します。有効な値には 10 進数が含まれます。例: `50`、`60.5`。ラインカバレッジ基準は、コードカバレッジレポートにのみ適用されます。コードカバレッジレポートの詳細については、「[コードカバレッジレポート](test-workflow-actions.md#test-code-coverage-reports)」を参照してください。 対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/[成功基準]/**[ラインカバレッジ]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/[成功基準]/**[ラインカバレッジ]** ## BranchCoverage (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**BranchCoverage**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**BranchCoverage**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるために、コードカバレッジレポート内でカバーする必要があるブランチの割合を指定します。有効な値には 10 進数が含まれます。例: `50`、`60.5`。ブランチカバレッジ基準は、コードカバレッジレポートにのみ適用されます。コードカバレッジレポートの詳細については、「[コードカバレッジレポート](test-workflow-actions.md#test-code-coverage-reports)」を参照してください。 対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/[成功基準]/**[ブランチカバレッジ]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/[成功基準]/**[ブランチカバレッジ]** ## Vulnerabilities (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**Vulnerabilities**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**Vulnerabilities**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるために、SCA レポートで許容される脆弱性の数と重要度の上限を指定します。脆弱性を指定するには、以下を指定する必要があります。 + カウントに含める脆弱性の最小重要度。有効な値は、重要度が高い順に `CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL` です。 例えば、`HIGH` を選択すると、`HIGH` と `CRITICAL` の脆弱性が集計されます。 + 指定された重要度の脆弱性の最大許容数。この数を超えると、CodeCatalyst レポートは不合格としてマークされます。有効な値は整数です。 脆弱性の基準は SCA レポートにのみ適用されます。SCA レポートの詳細については、「[ソフトウェア構成分析レポート](test-workflow-actions.md#test-sca-reports)」を参照してください。 最小重要度を指定するには、`Severity` プロパティを使用します。脆弱性の最大数を指定するには、`Number` プロパティを使用します。 SCA レポートの詳細については、「[品質レポートのタイプ](test-workflow-actions.md#test-reporting)」を参照してください。 対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/[成功基準]/**[脆弱性]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/[成功基準]/**[脆弱性]** ## Reports (*action-name*/Outputs/**Reports** ) (オプション) テストレポートの設定を指定するセクション。 対応する UI: [出力] タブ/**[レポート]** ## report-name-1 (*action-name*/Outputs/Reports/**report-name-1**) ([Reports](#github.configuration.reports) が含まれている場合は必須) 未加工レポートから生成される CodeCatalyst レポートに付ける名前。 対応する UI: [出力] タブ/[レポート]/[レポートを手動で設定]/**[レポート名]** ## Format (*action-name*/Outputs/Reports/*report-name-1*/**Format**) ([Reports](#github.configuration.reports) が含まれている場合は必須) レポートに使用するファイル形式を指定します。指定できる値は以下のとおりです。 + テストレポートの場合: + Cucumber JSON には、**[Cucumber ]** (ビジュアルエディタ) または [`CUCUMBERJSON`] (YAML エディタ) を指定します。 + JUnit XML の場合は、**[JUnit]** (ビジュアルエディタ) または [`JUNITXML`] (YAML エディタ) を指定します。 + NUnit XML の場合は、**[NUnit]** (ビジュアルエディタ) または [`NUNITXML`] (YAML エディタ) を指定します。 + NUnit 3 XML の場合は、**[NUnit3]** (ビジュアルエディタ) または [`NUNIT3XML`] (YAML エディタ) を指定します。 + Visual Studio TRX の場合は、**[Visual Studio TRX]** (ビジュアルエディタ) または [`VISUALSTUDIOTRX`] (YAML エディタ) を指定します。 + TestNG XML の場合は、**[TestNG]** (ビジュアルエディタ) または [`TESTNGXML`] (YAML エディタ) を指定します。 + コードカバレッジレポートの場合: + Clover XML の場合は、**[Clover]** (ビジュアルエディタ) または [`CLOVERXML`] (YAML エディタ) を指定します。 + Cobertura XML の場合は、**[Cobertura]** (ビジュアルエディタ) または [`COBERTURAXML`] (YAML エディタ) を指定します。 + JaCoCo XML の場合は、**[JaCoCo]** (ビジュアルエディタ) または [`JACOCOXML`] (YAML エディタ) を指定します。 + [[simplecov-json]](https://github.com/simplecov-ruby/simplecov) ではなく [[simplecov]](https://github.com/vicentllongo/simplecov-json) によって生成された SimpleCov JSON の場合は、**[Simplecov]** (ビジュアルエディタ) または [`SIMPLECOV`] (YAML エディタ) を指定します。 + ソフトウェアコンポジション分析 (SCA) レポートの場合: + SARIF の場合は、**[SARIF]** (ビジュアルエディタ) または [`SARIFSCA`] (YAML エディタ) を指定します。 対応する UI: [出力] タブ/[レポート]/[レポートを手動で設定]/[レポートを追加]/*report-name-1*/**[レポートタイプ]** および **[レポート形式]** ## Configuration (*action-name*/**Configuration**) (必須) アクションの設定プロパティを定義できるセクション。 対応する UI: **[設定]** タブ ## Steps (*action-name*/Configuration/**Steps**) (必須) GitHub Action コードを、[GitHub Marketplace](https://github.com/marketplace) のアクションの詳細ページに表示されるとおりに指定します。次のガイドラインに従ってコードを追加します。 1. GitHub Action の `steps:` セクションのコードを CodeCatalyst ワークフローの `Steps:` セクションに貼り付けます。コードはダッシュ (-) で始まり、次のような形式になります。 貼り付ける GitHub コード: ``` - name: Lint Code Base uses: github/super-linter@v4 env: VALIDATE_ALL_CODEBASE: false DEFAULT_BRANCH: master GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` 1. 貼り付けたコードをレビューし、CodeCatalyst の規格に準拠するように必要に応じて変更します。例えば、前述のコードブロックでは、*赤い斜体*のコードを削除し、**太字**のコードを追加することができます。 CodeCatalyst ワークフロー yaml: ``` Steps: - name: Lint Code Base uses: github/super-linter@v4 env: VALIDATE_ALL_CODEBASE: false DEFAULT_BRANCH: mastermain GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` 1. GitHub Action に含まれているが、`steps:` セクション内に存在しない追加のコードについては、CodeCatalyst の対応するコードを使用して CodeCatalyst ワークフローに追加します。GitHub コードを CodeCatalyst に移植する方法については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。詳細な移行手順は、このガイドの範囲外です。 **GitHub Actions** アクションでファイルパスを指定する方法の例を次に示します。 ``` Steps: - name: Lint Code Base uses: github/super-linter@v4 ... - run: cd /sources/WorkflowSource/MyFolder/ && cat file.txt - run: cd /artifacts/MyGitHubAction/MyArtifact/MyFolder/ && cat file2.txt ``` 出力ファイル名とパスの詳細については、「[ソースリポジトリファイルの参照](workflows-sources-reference-files.md)」と「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。 対応する UI: [設定] タブ/**[GitHub Actions YAML]**