7.2.2 マニフェストの更新時のエラーに関する対処方法

（1）マニフェストファイルのnameキーとデータモデルのテーブル名でエラーが発生しマニフェストファイルが登録できない場合の対処

次の要因が考えられます。

名前が予約語と衝突しているおそれがあります。名前にプレフィックスを付けることで、予約語との衝突を回避してください。以下に予約語を示します。

（表）予約語一覧

項目	予約語
マニフェストファイルのnameキー	acl、activity、api、cmdb、conf、datamodel、doc、opsi、otobo、otobo-mapping、policy、practice、resource、resource-api、schedule、statement、sys、system、task、ticket、ui、workflow
ボタンのnameキー	edit、revert_finish_editing
データモデルのテーブル名	group、mapping_group、node、role、sys、system、ticket、user

予約語と完全に一致する場合、または予約語から始まり、かつ予約語の直後が_（アンダーバー）の場合はエラーが発生します。以下に使用例を示します。

（表）予約語の使用例

使用できる場合	使用できない場合
・xxx_mapping_group_yyy ・mapping_groupxxx_yyy	・mapping_group ・mapping_group_xxx

（2）エラーメッセージが表示されないが、意図しない動作になる場合の対処

次の要因が考えられます。

Include対象となるマニフェストファイルで、他のnameキーと衝突しているおそれがあります。以下に例を示します。
1つのUIでScriptAとScriptBをIncludeし、アクションとして「action」を定義します。ScriptA ではJS_A.js、ScriptBではJS_B.jsが実行されるように、どちらも「action」というnameキーのアクションを定義した場合nameキーが衝突し、AとBどちらのアクションが実行されるか不明確になり意図しない動作になります。
この場合は「A_action」、「B_action」などのようにnameキーが衝突しないようにする必要があります。

（3）依存関係があるマニフェストファイルを同時に登録（または削除）した後に、バリデーションエラーが起こっていた場合の対処

依存関係があるマニフェストファイルのセットを同時に登録（または削除）し、かつマニフェストファイルの一部にバリデーションエラーがある場合、エラーがないマニフェストファイルも含めOps Iにドキュメント登録（または削除）されていない状態になります。
（登録時の例：Commit1、削除時の例：Commit3）

エラーを修正し、再度Commitすると、エラーがないマニフェストファイルも同時に登録（または削除）されます。
この時、エラーがないマニフェストファイルを再度Commit（または削除）する必要はありません。
（登録時の例：Commit2、削除時の例：Commit4）

エラーの有無はAPI「gitops-logs」で確認します。

【登録時の例】

関係：マニフェストファイルAをマニフェストファイルBが参照

Commit1：依存関係があるマニフェストファイルA（エラーあり）とマニフェストファイルB（エラーなし）を登録

①マニフェストファイルA（エラーあり）：Ops Iへの登録失敗

②マニフェストファイルB（エラーなし）：Ops Iへの登録失敗

Commit2：マニフェストファイルAをエラー修正後、再度Commit

①マニフェストファイルA（修正によりエラーなし）：Ops Iへの登録成功
再適用処理→マニフェストファイルB（エラーなし）：Ops Iへの登録成功

【削除時の例】

関係：マニフェストファイルAをマニフェストファイルBが参照

Commit3：依存関係があるOps I登録済みマニフェストファイルAを削除

①マニフェストファイルA：Ops Iへの削除失敗（マニフェストファイルBの参照があるため）

Commit4：依存があるマニフェストファイルBを削除

②マニフェストファイルB：Ops Iへの削除成功
再適用処理→マニフェストファイルA：Ops Iへの削除成功