2252501_ja-JP

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

2252501_ja-JP

2252501_ja-JP

CI/CD のベストプラクティス

このトピックについては以前にも類似の投稿がいくつかありましたが、回答は少し古く、私の質問も少し異なるため、SOもう一度質問する価値があるかもしれません。質問が2つあります。


1. 時々、S32DS(v 3.6.2、OS は Windows 11 ですが、特定の標準ヘッダー ファイルが見つからないためビルドが失敗します。プロジェクトの.mexファイルを再度開くだけでファイルを更新し、「更新コード」を実行して(実際には何も更新されないはずですが)、再構築すると、問題は解決します。私の質問は、なぜこのようなことが起こるのかということです。これはランダムに発生するようなので、「再現手順」を提供することはできませんが、頻繁に発生するため、少なくともそれに気付いていないとしたら驚きです。フォーラムでこの問題について言及している他の人も見かけました。


2. 私たちは、フラッシュにプログラムされるコードベース全体(アプリケーション コードのみではなく)を Git に配置し、ヘッドレス環境の IDEs 外部で CI/CD パイプラインを使用してイメージを構築することに取り組んでいます。RHEL 上で実行される gitlab を使用しています。

これに関して「ベストプラクティス」の推奨事項はありますか?特に、RTD、C 標準ライブラリなどはプロジェクトの外にあり、IDEs が多くの接続をセットアップするため、CI/CD 環境でこれをどのように処理すればよいのでしょうか。また、スタンドアロン ツールチェーンはどのようにインストールすればよいのでしょうか。

Re: Best practices for CI/CD

ヒントを教えてくれた@petervlnaさんに感謝します。CI/CD パイプラインに関してまだ疑問が 1 つあります。


Linux 環境で IDEs から独立してビルド ツール チェーンをインストールするにはどうすればよいですか?

Re: Best practices for CI/CD

こんにちは、

1. 時々、S32DS(v 3.6.2、OS は Windows 11 ですが、特定の標準ヘッダーファイルが見つからないためビルドが失敗します。プロジェクトの.mexファイルを再度開くだけでファイルを更新し、「更新コード」を実行して(実際には何も更新されないはずですが)、再構築すると、問題は解決します。私の質問は、なぜこのようなことが起こるのかということです。これはランダムに発生するようなので、「再現手順」を提供することはできませんが、頻繁に発生するため、少なくともそれに気付いていないとしたら驚きです。フォーラムでこの問題について言及している他の人も見かけました。

この問題は、S32DS のような Eclipse ベースの IDEs では比較的よく見られます。最も可能性の高い原因は次のとおりです。

  • インデックス/パス解決の不具合
    S32DS は、インクルード パスを解決するために Eclipse の CDT インデクサーとプロジェクト メタデータに依存します。場合によっては、インデクサーまたは内部ビルド構成が同期しなくなることがあります。特に、.mex または環境変数を変更した後にこの状況が発生します。.mexの再開ファイルとコードを再生成すると、IDEs はパスを更新し、インデックスを再構築するようになります。

  • 一時的なワークスペースの破損
    IDEs はワークスペースに多くの状態を保存します。ワークスペース キャッシュが不整合になった場合 (ビルドが中断された後や IDEs がクラッシュした後など)、更新されるまでインクルード パスが認識されないことがあります。

  • Windows ファイルシステムのタイミング
    Windows では、ウイルス対策やファイルロックにより、並列ビルド手順中にヘッダー ファイルへのアクセスが遅延され、断続的な障害が発生する可能性があります。

2. 私たちは、フラッシュにプログラムされるコードベース全体(アプリケーション コードのみではなく)を Git に配置し、ヘッドレス環境の IDEs 外部で CI/CD パイプラインを使用してイメージを構築することに取り組んでいます。RHEL 上で実行される gitlab を使用しています。

これに関して「ベストプラクティス」の推奨事項はありますか?特に、RTD、C 標準ライブラリなどはプロジェクトの外にあり、IDEs が多くの接続をセットアップするため、CI/CD 環境でこれをどのように処理すればよいのでしょうか。また、スタンドアロン ツールチェーンはどのようにインストールすればよいのでしょうか。


RTD と外部 SDKs を扱う

バージョン管理またはアーティファクトリポジトリ:

RTD および SDKs パッケージを Git (許可されている場合) または Nexus/Artifactory などのアーティファクト リポジトリに保存します。

環境変数:

CI/CD パイプラインで RTD_PATH や SDK_PATH などの変数を定義します。
ハードコードされたパスの代わりに、これらの変数を Makefile またはビルド スクリプトで使用します。

ヘッドレスビルド用のプロジェクトをエクスポートする

S32DS で、プロジェクトを Makefile プロジェクトとしてエクスポートします (プロジェクト → Makefile の生成)。
これにより、IDEs 外部で使用できる Makefile が提供されます。
あるいは、Windows ベースのヘッドレス ビルドには s32ds.exe --build を使用しますが、Linux CI/CD の場合は Makefile が推奨されます。

IDEsの依存を避ける

.mexに頼らないCI/CD での再生。
すべてのインクルード パスとコンパイラ フラグが Makefile または CMake 構成にキャプチャされていることを確認します。

一般的な推奨事項以外に何かあるかどうかはわかりません。

よろしくお願いいたします。

ピーター



Re: Best practices for CI/CD

こんにちは@petervlna


ご提案ありがとうございます。これについてはもう少し情報が必要です。S32 Design Studio ページには、IDE 全体のダウンロード オプションが表示され、ツールチェーンは IDE インストールの一部としてインストールされるようです。ツールチェーンが個別のダウンロードとして提供されるとは思えません。


Windows11(現在使用しています)では、ツールチェーンは次のようにインストールされています。

C:\NXP\S32DS.3.6.2\S32DS\ビルドツール


あなたが提案しているのは次のことです:

1. LinuxデスクトップにIDEのLinuxバージョンをインストールする

2. インストールしたツールチェーンをこのマシンからヘッドレスCI/CDサーバーにコピーします。

3. 上記の手順に従ってください


説明をお願いします。

Re: Best practices for CI/CD

こんにちは、

Linux 環境で IDEs から独立してビルド ツール チェーンをインストールするにはどうすればよいですか?

残念ながら、私は Linux 環境に関する知識がないので、一般的な回答しかできません。

公式手順の概要:


  1. S32DS ダウンロード ページから ARM 用の NXP GCC ツールチェーン (Linux バージョン) をダウンロードします。
  2. アーカイブを /opt/armgcc などのディレクトリに抽出します。
  3. ツールチェーンの bin ディレクトリを PATH に追加します。
  4. Linux システムにビルド ツール (make、cmake) をインストールします。
  5. ヘッドレス ビルドには S32DS からエクスポートされた Makefile を使用します。

Linux に関する質問については別のThreadを立てることをお勧めします。

よろしくお願いいたします。

ピーター


Re: Best practices for CI/CD

こんにちは、

スタンドアロンの gcc は、たとえば NXP のページからダウンロードできますhttps://www.nxp.com/webapp/sps/download/preDownload.jsp?render=true


または他のバージョンhttps://www.nxp.com/search?keyword=gcc%2520&start=0

Re: Best practices for CI/CD

こんにちは@petervlna @jiri_kral


既にクローズ済みのチケットへの返信が遅れてしまい申し訳ありません。ようやくこの問題に取り組む時間ができました。


ピーターの提案は私には完全に理にかなっているように思えますが、 S32 IDE (v3.6.6) で「プロジェクト → メイクファイルの生成」オプションが見つかりません。生成されたメイクファイルをコピーしてみることもできますが、それにはいくつか問題があります。

1.これは単体のMakefileではなく、他の.mkファイルに依存しています。生成されるファイルも含まれています。

2. メイクファイルはビルドターゲットごとに生成されます(.cprojectとは異なります)。ファイルサイズが大きいため、やや扱いにくい。理想としては、ビルドターゲットが「make」コマンドの引数となるようなMakefileを1つ作成したいです。


他の人がこれまでこの質問をしなかったこと、あるいはこの件に関する「ハウツー」ドキュメントがないことに少し驚いています。このプロセッサは非常に人気があり、セーフティが極めて重要であることを考えると、CI/CD Linux環境でビルドを行うことは一般的だと思っていたからです。

タグ(1)
評価なし
バージョン履歴
最終更新日:
‎03-31-2026 03:33 AM
更新者: