ワークフローに関する問題のトラブルシューティング - Amazon CodeCatalyst
「ワークフローが非アクティブ」メッセージを修正するにはどうすればよいですか？「ワークフロー定義には」の修正方法 n errors" エラー「認証情報が見つかりません」と「」のExpiredTokenエラーを修正するにはどうすればよいですか？「サーバーに接続できません」というエラーを修正するにはどうすればよいですか？ビジュアルエディタに CodeDeploy フィールドがないのはなぜですか？IAM 機能エラーを修正するにはどうすればよいですか？「npm install」エラーを修正するにはどうすればよいですか？複数のワークフローが同じ名前を持つのはなぜですか？ワークフロー定義ファイルを別のフォルダに保存できますか？ワークフローにアクションを順番に追加するにはどうすればよいですか？ワークフローが正常に検証されても実行時に失敗するのはなぜですか？自動検出では、 アクションのレポートは検出されません成功基準を設定した後、自動検出されたレポートでアクションが失敗する自動検出では不要なレポートが生成されます自動検出は、1 つのテストフレームワークに対して多数の小さなレポートを生成します。CI/CD にリストされているワークフローがソースリポジトリのワークフローと一致しませんワークフローを作成または更新できない

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ワークフローに関する問題のトラブルシューティング

Amazon のワークフローに関連する問題のトラブルシューティングについては、以下のセクションを参照してください CodeCatalyst。ワークフローの詳細については、「ワークフローを使用して構築、テスト、デプロイする」を参照してください。

トピック

「ワークフローが非アクティブ」メッセージを修正するにはどうすればよいですか？

問題： CodeCatalyst コンソールの CI/CD のワークフロー で、ワークフローに次のメッセージが表示されます。

Workflow is inactive.

このメッセージは、ワークフロー定義ファイルに、現在使用しているブランチに適用されないトリガーが含まれていることを示します。例えば、ワークフロー定義ファイルには、mainブランチを参照するPUSHトリガーが含まれている場合がありますが、機能ブランチを使用しているとします。機能ブランチで行った変更は には適用されずmain、 でワークフロー実行が開始されないためmain、 はブランチのワークフローを CodeCatalyst 廃止し、 としてマークしますInactive。

解決方法:

機能ブランチでワークフローを開始する場合は、次の操作を実行できます。

  • 機能ブランチのワークフロー定義ファイルで、 Triggers セクションから Branchesプロパティを削除して、次のようになります。

    Triggers:
  - Type: PUSH

    この設定により、特徴量ブランチを含む任意のブランチへのプッシュ時にトリガーがアクティブになります。トリガーがアクティブ化 CodeCatalyst されている場合、プッシュ先のブランチのワークフロー定義ファイルとソースファイルを使用してワークフロー実行を開始します。

  • 機能ブランチのワークフロー定義ファイルで、 Triggersセクションを削除し、ワークフローを手動で実行します。

  • 機能ブランチのワークフロー定義ファイルで、 PUSHセクションを変更してmain、別のブランチ ( など) ではなく機能ブランチを参照するようにします。

重要

これらの変更をmainブランチにマージする予定がない場合は、コミットしないように注意してください。

ワークフロー定義ファイルの編集の詳細については、「」を参照してくださいワークフローの作成。

トリガーについての詳細は、「トリガーを使用してワークフローを自動的に開始する」を参照してください。

「ワークフロー定義には」の修正方法 n errors" エラー

問題： 次のいずれかのエラーメッセージが表示されます。

エラー 1:

CI/CD の「ワークフロー」ページには、ワークフローの名前の下に以下が表示されます。

Workflow definition has n errors

エラー 2:

ワークフローの編集中に検証ボタンを選択すると、 CodeCatalyst コンソールの上部に次のメッセージが表示されます。

The workflow definition has errors. Fix the errors and choose Validate to verify your changes.

エラー 3:

ワークフローの詳細ページに移動すると、ワークフロー定義フィールドに次のエラーが表示されます。

n errors

解決方法:

  • CI/CD を選択し、ワークフロー を選択し、エラーのあるワークフローの名前を選択します。上部にあるワークフロー定義フィールドで、エラーへのリンクを選択します。エラーに関する詳細は、ページの下部に表示されます。エラーのトラブルシューティングのヒントに従って問題を解決します。

  • ワークフロー定義ファイルが YAML ファイルであることを確認します。

  • ワークフロー定義ファイルのYAMLプロパティが適切なレベルでネストされていることを確認します。ワークフロー定義ファイルにプロパティをネストする方法を確認するには、「」を参照ワークフローYAML定義するか、「」からリンクされているアクションのドキュメントを参照してくださいワークフローへのアクションの追加。

  • アスタリスク (*) やその他の特殊文字が正しくエスケープされていることを確認してください。エスケープするには、一重引用符または二重引用符を追加します。例:

    Outputs:      
  Artifacts:
    - Name: myartifact
      Files:
        - "**/*"

    ワークフロー定義ファイルの特殊文字の詳細については、「」を参照してください構文のガイドラインと規則。

  • ワークフロー定義ファイルのYAMLプロパティが正しい大文字と小文字を使用していることを確認してください。大文字と小文字のルールの詳細については、「」を参照してください構文のガイドラインと規則。各プロパティの正しい大文字と小文字を確認するには、ワークフローYAML定義「」を参照するか、「」からリンクされているアクションのドキュメントを参照してくださいワークフローへのアクションの追加。

  • SchemaVersion プロパティが存在し、ワークフロー定義ファイルで正しいバージョンに設定されていることを確認します。詳細については、「SchemaVersion」を参照してください。

  • ワークフロー定義ファイルの Triggersセクションに、必要なプロパティがすべて含まれていることを確認してください。必要なプロパティを確認するには、ビジュアルエディタでトリガーを選択し、情報が不足しているフィールドを検索するか、「」のトリガーリファレンスドキュメントを参照してくださいTriggers。

  • ワークフロー定義ファイルの DependsOnプロパティが正しく設定されており、循環依存関係が導入されていないことを確認してください。詳細については、「シーケンスアクション」を参照してください。

  • ワークフロー定義ファイルの Actionsセクションに少なくとも 1 つのアクションが含まれていることを確認します。詳細については、「アクション」を参照してください。

  • 各アクションに必要なプロパティがすべて含まれていることを確認してください。必要なプロパティを確認するには、ビジュアルエディタでアクションを選択し、情報が不足しているフィールドを検索するか、 からリンクされているアクションのドキュメントを参照してくださいワークフローへのアクションの追加。

  • すべての入力アーティファクトに対応する出力アーティファクトがあることを確認します。詳細については、「出力アーティファクトの定義」を参照してください。

  • あるアクションで定義された変数がエクスポートされ、他のアクションで使用できるようにしてください。詳細については、「他のアクションで使用できるように変数をエクスポートする」を参照してください。

「認証情報が見つかりません」と「」のExpiredTokenエラーを修正するにはどうすればよいですか？

問題: の作業中にチュートリアル: Amazon にアプリケーションをデプロイする EKS、開発マシンのターミナルウィンドウに次のエラーメッセージのいずれかまたは両方が表示されます。

Unable to locate credentials. You can configure credentials by running "aws configure".

ExpiredToken: The security token included in the request is expired

解決方法:

これらのエラーは、 AWS サービスへのアクセスに使用している認証情報の有効期限が切れていることを示しています。この場合、 aws configure コマンドを実行しないでください。代わりに、次の手順を使用して AWS アクセスキーとセッショントークンを更新します。

AWS アクセスキーとセッショントークンを更新するには

  1. Amazon EKSチュートリアル全体 () を使用しているユーザーの AWS アクセスポータル 、URLユーザー名、パスワードがあることを確認しますcodecatalyst-eks-user。ステップ 1: 開発マシンをセットアップする チュートリアルの完了時に、これらの項目を設定しておく必要があります。

    注記

    この情報がない場合は、IAMIdentity Center codecatalyst-eks-userの詳細ページに移動し、パスワードのリセット 、ワンタイムパスワードの生成 [...]、パスワードのリセットをもう一度選択して、画面に情報を表示します。

  2. 次のいずれかを行います。

    • AWS アクセスポータルをブラウザのアドレスバーURLに貼り付けます。

      または

    • アクセス AWS ポータルページが既にロードされている場合は更新します。

  3. まだサインインしていない場合は、 codecatalyst-eks-userのユーザー名とパスワードでサインインします。

  4. を選択しAWS アカウント、codecatalyst-eks-userユーザーとアクセス許可セット AWS アカウント を割り当てた の名前を選択します。

  5. アクセス許可セット名 (codecatalyst-eks-permission-set) の横にある コマンドラインまたはプログラムによるアクセス を選択します。

  6. ページの中央にあるコマンドをコピーします。これらは次のようになります。

    export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE" 
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" 
export AWS_SESSION_TOKEN="session-token"

    ... 場所 session-token は長いランダム文字列です。

  7. コマンドを開発マシンのターミナルプロンプトに貼り付け、Enter キーを押します。

    新しいキーとセッショントークンがロードされます。

    これで、認証情報が更新されました。これで、 AWS CLI、eksctl、および kubectl コマンドが機能します。

「サーバーに接続できません」というエラーを修正するにはどうすればよいですか？

問題 : で説明されているチュートリアルを実行しているときにチュートリアル: Amazon にアプリケーションをデプロイする EKS、開発マシンのターミナルウィンドウに次のようなエラーメッセージが表示されます。

Unable to connect to the server: dial tcp: lookup long-string.gr7.us-west-2.eks.amazonaws.com on 1.2.3.4:5: no such host

解決方法:

このエラーは通常、kubectlユーティリティが Amazon EKSクラスターへの接続に使用している認証情報の有効期限が切れていることを示します。この問題を解決するには、ターミナルプロンプトで次のコマンドを入力して認証情報を更新します。

aws eks update-kubeconfig --name codecatalyst-eks-cluster --region us-west-2

コードの説明は以下のとおりです。

  • codecatalyst-eks-cluster は Amazon EKSクラスターの名前に置き換えられます。

  • us-west-2 は、クラスターがデプロイされている AWS リージョンに置き換えられます。

ビジュアルエディタに CodeDeploy フィールドがないのはなぜですか？

問題: Amazon へのデプロイECSアクションを使用していて、ワークフローのビジュアルエディタCodeDeploy AppSpecに などの CodeDeploy フィールドが表示されません。この問題は、ECSサービスフィールドで指定した Amazon サービスがブルー/グリーンデプロイを実行するように設定されていないために発生する可能性があります。

解決方法:

IAM 機能エラーを修正するにはどうすればよいですか？

問題: AWS CloudFormation スタックのデプロイアクションを使用していて、スタックのデプロイ AWS CloudFormation アクションのログ##[error] requires capabilities: [capability-name]に が表示されます。

解決方法： ワークフロー定義ファイルに 機能を追加するには、以下の手順を実行します。IAM 機能の詳細については、「 ユーザーガイド」の AWS CloudFormation 「 テンプレートでのIAMリソースの承認」を参照してください。 IAM

Visual
ビジュアルエディタを使用してIAM機能を追加するには

  1. https://codecatalyst.aws/ で CodeCatalyst コンソールを開きます。

  2. プロジェクトを選択します。

  3. ナビゲーションペインで CI/CD を選択し、ワークフロー を選択します。

  4. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

  5. [編集] を選択します。

  6. ビジュアル を選択します。

  7. ワークフロー図で、スタックのデプロイ AWS CloudFormation アクションを選択します。

  8. [設定] タブを選択します。

  9. 下部で、詳細 - オプション を選択します。

  10. 機能 ドロップダウンリストで、エラーメッセージに記載されている機能の横にあるチェックボックスをオンにします。機能がリストにない場合は、YAMLエディタを使用して追加します。

  11. （オプション) 検証 を選択して、コミットする前にワークフローのYAMLコードを検証します。

  12. コミット を選択し、コミットメッセージを入力し、もう一度コミット を選択します。

  13. 新しいワークフロー実行が自動的に開始しない場合は、ワークフローを手動で実行して、変更によってエラーが修正されたかどうかを確認します。ワークフローの手動実行の詳細については、「」を参照してくださいワークフローの手動実行の開始。

YAML
YAML エディタを使用して IAM機能を追加するには

  1. https://codecatalyst.aws/ で CodeCatalyst コンソールを開きます。

  2. プロジェクトを選択します。

  3. ナビゲーションペインで CI/CD を選択し、ワークフロー を選択します。

  4. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

  5. [編集] を選択します。

  6. を選択しますYAML。

  7. AWS CloudFormation スタックのデプロイアクションで、次のようなcapabilitiesプロパティを追加します。

    DeployCloudFormationStack:
  Configuration:
    capabilities: capability-name

    置換 capability-name エラーメッセージに表示されるIAM機能の名前。複数の機能を一覧表示するには、カンマを使用し、スペースは使用しないでください。詳細については、「」の「 capabilitiesプロパティの説明」を参照してくださいAWS CloudFormation 「スタックのデプロイ」アクション YAML。

  8. （オプション) 検証 を選択して、コミットする前にワークフローのYAMLコードを検証します。

  9. コミット を選択し、コミットメッセージを入力し、もう一度コミット を選択します。

  10. 新しいワークフロー実行が自動的に開始しない場合は、ワークフローを手動で実行して、変更によってエラーが修正されたかどうかを確認します。ワークフローの手動実行の詳細については、「」を参照してくださいワークフローの手動実行の開始。

「npm install」エラーを修正するにはどうすればよいですか？

問題： AWS CDK デプロイアクションまたはAWS CDK ブートストラップアクションがnpm installエラーで失敗します。このエラーは、 アクションではアクセスできないプライベートノードパッケージマネージャー (npm) レジストリに AWS CDK アプリケーションの依存関係を保存しているため発生する可能性があります。

解決方法: 以下の手順に従って、追加のレジストリと認証情報で AWS CDK アプリケーションの cdk.json ファイルを更新します。

開始する前に

  1. 認証情報のシークレットを作成します。これらのシークレットは、クリアテキストの同等のものを提供するのではなく、 cdk.json ファイルで参照します。シークレットを作成するには：

    1. https://codecatalyst.aws/ で CodeCatalyst コンソールを開きます。

    2. プロジェクトを選択します。

    3. ナビゲーションペインで CI/CD を選択し、シークレット を選択します。

    4. 次のプロパティを使用して 2 つのシークレットを作成します。

      最初のシークレット 2 番目のシークレット

      名前: npmUsername

      値: npm-username次のとおりです。npm-username は、プライベート npm レジストリへの認証に使用されるユーザー名です。

      （オプション) 説明: The username used to authenticate to the private npm registry.

      名前: npmAuthToken

      値: npm-auth-token次のとおりです。npm-auth-token は、プライベート npm レジストリへの認証に使用されるアクセストークンです。npm アクセストークンの詳細については、npm ドキュメントの「アクセストークンについて」を参照してください。

      （オプション) 説明: The access token used to authenticate to the private npm registry.

      シークレットの詳細については、「」を参照してくださいシークレットを使用したデータのマスキング。

  2. シークレットを環境変数として AWS CDK アクションに追加します。アクションは、実行時に変数を実際の値に置き換えます。シークレットを追加するには：

    1. ナビゲーションペインで CI/CD を選択し、ワークフロー を選択します。

    2. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

    3. [編集] を選択します。

    4. ビジュアル を選択します。

    5. ワークフロー図で、 AWS CDK アクションを選択します。

    6. [入力] タブを選択します。

    7. 次のプロパティを持つ 2 つの変数を追加します。

      最初の変数 2 番目の変数

      名前: NPMUSER

      値: ${Secrets.npmUsername}

      名前: NPMTOKEN

      値: ${Secrets.npmAuthToken}

      これで、シークレットへの参照を含む 2 つの変数ができました。

    ワークフロー定義ファイルYAMLコードは次のようになります。

    注記

    次のコードサンプルはAWS CDK ブートストラップアクションからのものです。AWS CDK デプロイアクションは似ています。

    Name: CDK_Bootstrap_Action
SchemaVersion: 1.0
Actions:
  CDKBootstrapAction:
    Identifier: aws/cdk-bootstrap@v2
    Inputs:
      Variables:
        - Name: NPMUSER
          Value: ${Secrets.npmUsername}
        - Name: NPMTOKEN
          Value: ${Secrets.npmAuthToken}
      Sources:
        - WorkflowSource
    Environment:
      Name: Dev2
      Connections:
        - Name: account-connection
          Role: codecatalystAdmin
    Configuration:
      Parameters:
        Region: "us-east-2"

    これで、 cdk.json ファイル内の 変数NPMUSERと NPMTOKEN変数を使用する準備が整いました。次の手順に進みます。

cdk.json ファイルを更新するには

  1. AWS CDK プロジェクトのルートディレクトリに移動し、 cdk.json ファイルを開きます。

  2. "app": プロパティを検索し、 に示されているコードを含めるように変更します。red italics:

    注記

    次のサンプルコードは TypeScript プロジェクトのものです。 JavaScript プロジェクトを使用している場合、コードは同じではありませんが、似ています。

    {
  "app": "npm set registry=https://your-registry/folder/CDK-package/ --userconfig .npmrc && npm set //your-registry/folder/CDK-package/:always-auth=true --userconfig .npmrc && npm set //your-registry/folder/CDK-package/:_authToken=\"${NPMUSER}\":\"${NPMTOKEN}\" && npm install  && npx ts-node --prefer-ts-exts bin/hello-cdk.ts|js",
  "watch": {
    "include": [
      "**"
    ],
    "exclude": [
      "README.md",
      "cdk*.json",
      "**/*.d.ts",
      "**/*.js",
      "tsconfig.json",
      "package*.json",
...

  3. で強調表示されているコード red italics、以下を置き換えます。

    • your-registry/folder/CDK-package/ プライベートレジストリ内の AWS CDK プロジェクトの依存関係へのパス。

    • hello-cdk.ts|.js エントリポイントファイルの名前を入力します。これは、使用している言語に応じて .ts (TypeScript) または .js (JavaScript) ファイルになります。

      注記

      アクションは を置き換えます。NPMUSER また、NPMTOKEN Secrets で指定した npm ユーザー名とアクセストークンを持つ 変数。

  4. cdk.json ファイルを保存します。

  5. アクションを手動で再実行して、変更によってエラーが修正されたかどうかを確認します。アクションの手動実行の詳細については、「」を参照してくださいワークフローの手動実行の開始。

複数のワークフローが同じ名前を持つのはなぜですか？

ワークフローは、リポジトリごとにブランチごとに保存されます。2 つの異なるワークフローは、異なるブランチに存在する場合、同じ名前を持つことができます。ワークフロー ページで、ブランチ名を確認することで、同じ名前のワークフローを区別できます。詳細については、「ソースコードの整理は、Amazon のブランチと連携します。 CodeCatalyst」を参照してください。

ワークフローブランチ

ワークフロー定義ファイルを別のフォルダに保存できますか？

いいえ、すべてのワークフロー定義ファイルを .codecatalyst/workflowsフォルダ、またはそのフォルダのサブフォルダに保存する必要があります。複数の論理プロジェクトでモノリポジトリを使用している場合は、すべてのワークフロー定義ファイルを .codecatalyst/workflowsフォルダまたはそのサブフォルダの 1 つに配置し、トリガー内でファイル変更フィールド (ビジュアルエディタ) またはFilesChangedプロパティ (YAMLエディタ) を使用して、指定されたプロジェクトパスでワークフローを自動的にトリガーします。詳細については、「ワークフローへのトリガーの追加」および「例: プッシュ、ブランチ、ファイルを含むトリガー」を参照してください。

ワークフローにアクションを順番に追加するにはどうすればよいですか？

デフォルトでは、ワークフローにアクションを追加すると、依存関係はなく、他のアクションと並行して実行されます。

アクションを順番に配置したい場合は、 DependsOnフィールドを設定することで、別のアクションへの依存関係を設定できます。他のアクションの出力であるアーティファクトまたは変数を使用するようにアクションを設定することもできます。詳細については、「シーケンスアクション」を参照してください。

ワークフローが正常に検証されても実行時に失敗するのはなぜですか？

Validate ボタンを使用してワークフローを検証したが、ワークフローが失敗した場合は、検証機能の制限が原因である可能性があります。

ワークフロー設定のシークレット、環境、フリートなどの CodeCatalyst リソースを参照するエラーは、コミット中に登録されません。無効な参照が使用されている場合、エラーはワークフローの実行時にのみ識別されます。同様に、必須フィールドの欠落やアクション属性の誤字など、アクション設定にエラーがある場合、ワークフローが実行されたときにのみ識別されます。詳細については、「ワークフローの作成」を参照してください。

自動検出では、 アクションのレポートは検出されません

問題： テストを実行するアクションに自動検出を設定しましたが、 によってレポートが検出されません CodeCatalyst。

解決方法： これはいくつかの問題が原因である可能性があります。次の解決策を 1 つ以上試してください。

  • テストの実行に使用されるツールが、 が CodeCatalyst 理解する形式のいずれかで出力を生成していることを確認します。例えば、 CodeCatalyst がテストとコードのカバレッジレポートを検出pytestできるようにする場合は、次の引数を含めます。

    --junitxml=test_results.xml --cov-report xml:test_coverage.xml

    詳細については、「品質レポートタイプ」を参照してください。

  • 出力のファイル拡張子が、選択した形式と一致していることを確認します。例えば、 を設定pytestして JUnitXML 形式で結果を生成する場合は、ファイル拡張子が であることを確認します.xml。詳細については、「品質レポートタイプ」を参照してください。

  • 特定のフォルダを意図的に除外しない限りIncludePaths、 がファイルシステム全体 (**/*) を含むように設定されていることを確認します。同様に、レポートが配置されていることが予想されるディレクトリを除外ExcludePathsしないようにしてください。

  • 特定の出力ファイルを使用するようにレポートを手動で設定した場合、自動検出から除外されます。詳細については、「品質レポートYAMLの例」を参照してください。

  • 出力が生成される前にアクションが失敗したため、自動検出でレポートが見つからない場合があります。例えば、ユニットテストが実行される前にビルドが失敗した可能性があります。

成功基準を設定した後、自動検出されたレポートでアクションが失敗する

問題： 自動検出を有効にして成功基準を設定すると、一部のレポートが成功基準を満たさず、結果としてアクションが失敗します。

解決方法： これを解決するには、次の解決策を 1 つ以上試してください。

  • IncludePaths または を変更ExcludePathsして、関心のないレポートを除外します。

  • 成功基準を更新して、すべてのレポートが合格できるようにします。例えば、2 つのレポートが 50% のラインカバレッジと 70% の別のレポートで見つかった場合は、最小ラインカバレッジを 50% に調整します。詳細については、「成功基準」を参照してください

  • 失敗したレポートを手動で設定したレポートに変換します。これにより、その特定のレポートに対して異なる成功基準を設定できます。詳細については、「レポートの成功基準の設定」を参照してください。

自動検出では不要なレポートが生成されます

問題： 自動検出を有効にすると、不要なレポートが生成されます。例えば、 は、 に保存されているアプリケーションの依存関係に含まれるファイルのコードカバレッジレポート CodeCatalyst を生成しますnode_modules。

解決方法： 不要なファイルを除外するようにExcludePaths設定を調整できます。例えば、 を除外するにはnode_modules、 を追加しますnode_modules/**/*。詳細については、「パスの包含/除外」を参照してください。

自動検出は、1 つのテストフレームワークに対して多数の小さなレポートを生成します。

問題： 特定のテストおよびコードカバレッジレポートフレームワークを使用すると、自動検出によって多数のレポートが生成されることに気付きました。例えば、Maven の Surefire プラグインを使用する場合、自動検出はテストクラスごとに異なるレポートを生成します。

解決方法： フレームワークは出力を 1 つのファイルに集約できる場合があります。例えば、Maven の Surefire プラグインを使用している場合は、 npx junit-mergeを使用してファイルを手動で集計できます。完全な式は次のようになります。

mvn test; cd test-package-path/surefire-reports && npx junit-merge -d ./ && rm *Test.xml

CI/CD にリストされているワークフローがソースリポジトリのワークフローと一致しません

問題： CI/CD のワークフローページに表示されるワークフローが、ソースリポジトリの ~/.codecatalyst/workflows/フォルダにあるワークフローと一致しません。次の不一致が表示される場合があります。

  • ワークフローがワークフローページに表示されますが、対応するワークフロー定義ファイルがソースリポジトリに存在しません。

  • ワークフロー定義ファイルはソースリポジトリに存在しますが、対応するワークフローはワークフローページに表示されません。

  • ワークフローはソースリポジトリページとワークフローページの両方に存在しますが、2 つは異なります。

この問題は、ワークフローページを更新する時間がない場合、またはワークフロークォータを超えた場合に発生する可能性があります。

解決方法:

  • 待ちます。通常、ソースへのコミットから 2 ～ 3 秒待ってから、ワークフローページで変更を確認する必要があります。

  • ワークフロークォータを超えた場合は、次のいずれかを実行します。

    注記

    ワークフロークォータを超過したかどうかを判断するには、「」を確認しのワークフローのクォータ CodeCatalyst、文書化されたクォータをソースリポジトリまたはワークフローページのワークフローと照合します。クォータを超過したことを示すエラーメッセージがないため、自分で調査する必要があります。

    • スペースクォータあたりのワークフローの最大数を超えた場合は、一部のワークフローを削除してから、ワークフロー定義ファイルに対してテストコミットを実行します。テストコミットの例は、ファイルにスペースを追加する場合です。

    • 最大ワークフロー定義ファイルサイズのクォータを超えた場合は、ワークフロー定義ファイルを変更して長さを短くします。

    • 1 つのソースイベントクォータで処理されるワークフローファイルの最大数を超えた場合は、複数のテストコミットを実行します。各コミットのワークフローの最大数よりも少ない数を変更します。

ワークフローを作成または更新できない

問題： ワークフローを作成または更新したいが、変更をコミットしようとするとエラーが表示される。

解決方法： プロジェクトまたはスペース内のロールによっては、プロジェクト内のソースリポジトリにコードをプッシュするアクセス許可がない場合があります。ワークフローのYAMLファイルはリポジトリに保存されます。詳細については、「ワークフロー定義ファイル」を参照してください。Space 管理者ロール、プロジェクト管理者ロール、および寄稿者ロールにはすべて、プロジェクト内のリポジトリにコードをコミットしてプッシュするアクセス許可があります。

Contributor ロールはあるが、特定のブランチYAMLのワークフローに対する変更を作成またはコミットできない場合、そのロールを持つユーザーがその特定のブランチにコードをプッシュできないようにするブランチルールが、そのブランチに設定されている可能性があります。別のブランチでワークフローを作成するか、変更を別のブランチにコミットしてみてください。詳細については、「ブランチルールを使用してブランチに対して許可されるアクションを管理する」を参照してください。