GitLab CI パイプラインの実行¶

このリポジトリには、自動テストとドキュメントのビルドをサポートするための Dockerfile と GitLab Runner の構成ファイルが含まれています。 GitLab CI パイプラインの一般的な構成に関する情報は、公式の Gitlab documentation <https://docs.gitlab.com/ee/ci/yaml/> で確認できます。

GitLab CI の設定ファイルは、ソースツリーのルートにある .gitlab-ci.yml ファイルです。設定テンプレートは、admin/ci-templates/ ディレクトリ内のファイルにあります。

GitLab Runnerで使用されるDockerイメージは、当社の`GitLab Container Registry <https://gitlab.com/gromacs/gromacs/container_registry>`にあります。 (詳細は：ref:`containers`を参照) イメージは、`admin/containers`に記載されている手順に従って手動でビルドされます。 (詳細は：ref:`gitlab-ci tools`を参照)

注釈

完全自動テストは、主要なリポジトリ https://gitlab.com/gromacs/gromacs のブランチから発生したマージリクエストに対してのみ利用可能です。フォークされたリポジトリで作成された GitLab CI パイプラインでは、テストパイプラインに含まれるジョブ数が少なくなります。複雑なマージリクエストを受け入れる前に、十分なテストを受けるためには、gromacs プロジェクトのネームスペースにあるブランチから発行する必要がある場合があります。

設定ファイル¶

リポジトリのルートにある：file:`.gitlab-ci.yml`は、ステージといくつかのデフォルトパラメータを定義し、また：file:`admin/gitlab-ci/`からパイプラインで実行されるジョブを定義するファイルを含みます。

注意: ドット（.）で始まるジョブ名は「非表示」です（<https://docs.gitlab.com/ee/ci/yaml/#hidden-keys-jobs>）。これらのジョブは直接実行できませんが、`extends プロパティ <https://docs.gitlab.com/ee/ci/yaml/#extends> を使用して、テンプレートとして使用できます。

ジョブパラメータ¶

詳しくは、https://docs.gitlab.com/ee/ci/yaml で GitLab CI ジョブパラメータに関する完全なドキュメントを参照してください。ただし、以下の GROMACS に固有の規則についてはご注意ください。

before_script¶: 複数のテンプレートで使用され、ジョブの script パラメータにシェルコマンドを付加するために使用されます。 before_script を直接使用することは避け、ネストされた extends が複数の before_script 定義を上書きしないように注意してください。
ジョブキャッシュ¶: グローバルなデフォルトは存在しませんが、ソフトウェアをビルドするジョブは通常、`cache`を設定します。`cache`ディレクティブを明示的に無効にするには、`cache: {}`というジョブパラメータを指定します。詳細は、`GitLabドキュメント <https://docs.gitlab.com/ee/ci/yaml/#cache>`__を参照してください。特に、`cache:key <https://docs.gitlab.com/ee/ci/yaml/#cachekey>`__のキャッシュの識別に関する詳細を確認してください。
イメージ¶: 詳細については、コンテナを参照してください。CI パイプラインで使用されている Docker イメージに関する情報が記載されています。ジョブが以前のジョブの成果物に依存している場合は、依存関係と同じ (または互換性のある) イメージを使用するようにしてください!
ルール¶
のみ¶
ただし¶
トリガー条件¶: ジョブ*のパラメータは、ジョブが実行される状況を制御するために使用されます。(一部のキーワードは、他のパラメータ（例：*archive:when）の要素として使用する場合、異なる意味を持つことがあります。ただし、このドキュメントは、このキーワードに適用されません。）GitLabのルールは特殊であり、最初に一致するルールがジョブをトリガーし、その後、残りのすべてのルールは無視されます。ジョブをスキップするためのルールを作成するには、「never」という実行時間を指定したルールを作成します。複数の .rules:... テンプレートを指定した場合、またはこれらのパラメータを .rules... テンプレートと組み合わせて使用した場合、エラーや予期しない動作が発生する可能性があります。したがって、extends タグを使用してルールを継承することはできません。代わりに、ルールを組み合わせるには、!reference タグを使用してルールエントリを参照する、シンプルなルールタグを使用することをお勧めします（例：!reference [.rules:<something>, rules]）。各参照は、リスト内の個別のルールとして使用できます。エラーや予期しない動作を減らすには、これらの制御を通常のジョブ定義でのみ使用するようにしてください（「隠された」ジョブや親ジョブには使用しないでください）。注：rules は、古い only および except パラメータとは互換性がないことに注意してください。当社では、より新しい rules メカニズムに標準化しています。
タグ¶: 現在、一般的な（つまりCPUのみ）|Gromacs| CIジョブに対して、特別なタグを使用していません。これにより、誰かがリポジトリをクローンした場合でも、少なくともCPUジョブが実行されるようにします。テスト目的であれば、トップレベルの`:file:`.gitlab-ci.yml`の先頭にデフォルトのタグを追加できますが、これは特定のランナーが動作するかどうかを確認するためにのみ使用してください。本番環境では、GitLabでランナーが受け入れることができるジョブを選択することで対応します。現在、|Gromacs|プロジェクトのジョブは、ストックホルムのインフラストラクチャで実行していますが、すべてのCPUジョブが共有ランナーでも動作するように設計してください。
変数¶: 多くのジョブ定義では、*変数*内のキーを追加または上書きします。詳細については、`GitLab <https://docs.gitlab.com/ee/ci/yaml/#variables>`を参照してください。ローカルでの使用については、:ref:`variables`を参照してください。

スケジューリングとトリガー¶

パイプライン「スケジュール <https://gitlab.com/help/ci/pipelines/schedules>」は、GitLabのWebインターフェースを通じて設定されます。スケジュールされたパイプラインは、環境変数を通じて、schedules 条件で実行されるジョブに異なる変数の定義を提供できます。

毎日のスケジュールされたパイプラインは、|Gromacs|リポジトリの main および release 分支に対して実行されます。

rules.gitlab-ci.yml で定義されたルールは、ジョブが特定のパイプライン、またはウェブインターフェースで定義された変数の設定に基づいて、特定のスケジュールのみで実行されるように制限します。たとえば、if-weekly-then-on-success のルールは、スケジュールが GMX_PIPELINE_SCHEDULE=weekly を設定した場合にのみジョブを実行します。

マージ後の受け入れパイプラインの実行

Gitlab CI は、GROMACS の場合、デフォルトで MR が受け入れられ、その結果として生成されたコミットが main または リリース ブランチに含まれている場合にのみ、ジョブを実行します。これらのジョブは、Gitlab の Web インターフェースから新しいパイプラインを実行する際に、以下の POST_MERGE_ACCEPTANCE 入力変数を使用して手動でトリガーできます。

こちらも参照してください：trigger-post-merge.py.

グローバルなテンプレート¶

また、主なジョブ定義ファイルに定義されているテンプレートに加えて、一般的な「mixin」機能と動作テンプレートは、admin/gitlab-ci/global.gitlab-ci.yml`に定義されています。可読性を高めるために、一部のパラメータは個別のファイルに分割され、パラメータ名に基づいて命名されます（例：:file:`rules.gitlab-ci.yml）。

``.use-``で始まるジョブは、特定のツールチェーンを使用するジョブに必要なテンプレート機能など、ミックスインの動作を提供します。

parameter という名前で始まるジョブでは、共通のジョブ特性に対して、パラメータを1つの場所に設定できます。デフォルトのパラメータ値以外の値を設定する場合は、ジョブ名には意味のある記述を追加し、admin/gitlab-ci/global.gitlab-ci.yml ファイルにドキュメントを記載する必要があります。

ジョブ名¶

ジョブ名は

ジョブの目的を示します。
マルチステージタスク間の関係を示す。
同じステージ内のジョブを区別する。
設定全体を通して、ジョブの定義を区別してください。

ジョブは時間とともに異なるステージに再割り当てされる可能性があるため、通常、ジョブ名にステージの名前を含めることは役立ちません。たとえば、「ウェブページ」のフェーズを区別するために、「pre」や「post」、または「build」と「test」のようなタグが必要な場合は、これらのタグはジョブ名の末尾に含めることができます。

文体としては、基本ジョブ名とクォリファイや詳細を区別するために、``:``のような区切り文字を使用することが役立ちます。また、「ジョブのグループ化 <https://docs.gitlab.com/ee/ci/pipelines/index.html#grouping-jobs>」も検討してください。

回帰テストの更新¶

GROMACS の変更で、回帰テストの変更が必要となるものは、非常に困難です。なぜなら、回帰テストの非更新版を対象としたマージリクエストは、必ず失敗するからです。また、現在の変更がメインブランチに統合される前に回帰テストを更新すると、他のマージリクエストのパイプラインが失敗する可能性があります。

解決策は、新しい回帰テストブランチまたはコミットを作成し、それを GitLab にアップロードすることです。その後、REGRESSIONTESTBRANCH または特定のコミットを REGRESSIONTESTCOMMIT として指定して、回帰テストを実行する必要がある特定のパイプラインを実行します。特定のパイプラインの設定方法については、下記を参照してください。

変数¶

GitLab CIフレームワーク、GitLab Runner、プラグイン、および独自のスクリプトは、複数の`<https://docs.gitlab.com/ee/ci/variables/README.html>`変数を設定および使用します。

デフォルト値は、global.gitlab-ci.yml のトップレベルの variables 定義から利用できます。多くのミックスイン/テンプレートジョブは、追加の定義または上書き定義を提供します。最終的なジョブ定義を作成する際には、他の変数も設定できます。

変数（「CI_」で始まるものを含む）は、GitLab-CI、GitLab Runner、および関連インフラの動作を制御したり、ジョブ定義で使用したり、実行されるコマンドの環境に渡したりすることができます。

変数で、KUBERNETES_ で始まるキーは、GitLab Runner の Kubernetes エグゼクटर (<https://docs.gitlab.com/runner/executors/kubernetes.html#the-kubernetes-executor>) に関連します。

その他の重要な変数キーは以下のとおりです。

BUILD_DIR¶: GROMACS 特定のディレクトリを指定して、設定、ビルド、テストを実行します。通常、ジョブによって異なります。依存関係のあるジョブのすべてのタスクで同じディレクトリを指定する必要があります。
CI_PROJECT_NAMESPACE¶: 「gromacs」GitLabプロジェクトスペース内のリポジトリで作成されたパイプラインを区別します。パイプラインの作成前に、GROMACS GitLabインフラが利用可能かどうかを事前に確認するために使用できます。
COMPILER_MAJOR_VERSION¶: ツールチェーンのミックスインによって提供される整数バージョンの番号は、利便性と内部での使用を目的としています。
CMAKE¶: gromacs/ci-... Dockerイメージ（2020年10月以降にビルドされたもの）には、複数のCMakeバージョンがインストールされています。コンテナ内の最新バージョンのCMakeが最初に``PATH``に表示されます。個々のジョブで特定のバージョンのCMakeを使用できるようにするには、ジョブの*スクリプト*セクションで``$CMAKE``を使用し、*スクリプト*セクションの先頭に、例えば - CMAKE=${CMAKE:-$(which cmake)} のような行を追加してください。使用したいCMakeバージョンの完全な実行パスを設定することで、CMakeのバージョンを指定できます。詳細は：ref:containers を参照してください。
CMAKE_COMPILER_SCRIPT¶: CMake コマンドラインオプション（ツールチェーン用）。ツールチェーンの定義（例：.use-gcc8）は、ジョブの スクリプト 内の cmake コールに追加されるように提供されます。
CMAKE_MPI_OPTIONS¶: GROMACS の MPI ビルドオプションを定義するために、CMake コマンドライン引数を指定してください。
DRY_RUN¶: 読み取り専用の環境変数で、スクリプトが FTP および Web サーバーにアーティファクトファイルをアップロードする動作を制御するために使用されます。実際にファイルをアップロードするには、この変数を false に設定します。通常、これはパイプラインのサブミットスクリプトを通じて設定されますが、Web インターフェースからも手動で設定できます。
GROMACS_MAJOR_VERSION¶: CI スクリプトで使用する、ビルドジョブの成果物から期待するライブラリ API のバージョンを確認するための、読み取り専用環境変数。この変数は、当初は admin/gitlab-ci/api-client.matrix/gromacs-main.gitlab-ci.yml にのみ定義されていますが、一般的に使用される場合は admin/gitlab-ci/global.gitlab-ci.yml に移動することもできます。
GROMACS_RELEASE¶: 読み取り専用の環境変数で、タグ付きのリリースを準備するためのパイプライン内でジョブが実行中かどうかを確認できます。GitLabのWebインターフェースからパイプラインを開始するときに設定できます。たとえば、admin/gitlab-ci/global.gitlab-ci.yml の rules ミックスインを参照してください。
REGRESSIONTESTBRANCH¶: main ではなく、このブランチを使用してください。これにより、有効な CI テストを含む、更新された回帰テストを必要とするマージリクエストを可能にします。
REGRESSIONTESTCOMMIT¶: このコミットを、メインブランチの「head」ではなく、regressiontestsに適用することで、有効なCIテストを含む、更新されたregressionテストを必要とするマージリクエストを可能にします。
POST_MERGE_ACCEPTANCE¶: 読み取り専用の環境変数で、ジョブがターゲットブランチにマージされた後に実行されるようにスケジュールされている場合にのみ実行されることを示します。ウェブインターフェースまたはスケジュールを使用してパイプラインを実行するように設定できます。使用方法については、次の場所にある rules ミックスインを参照してください：:file:admin/gitlab-ci/global.gitlab-ci.yml
GMX_PIPELINE_SCHEDULE¶: 読み取り専用の環境変数で、ジョブのルールのみで使用されます。 if-<value>-then-on-success の形式のルール要素は、GMX_PIPELINE_SCHEDULE==value をチェックします。許可される値は、admin/gitlab-ci/rules.gitlab-ci.yml に存在するルール要素によって決定され、nightly および weekly を使用して、ジョブが指定されたスケジュールでのみ実行されるように制限できます。

変数の設定¶

個々のパイプラインで使用する変数は、GitLabインターフェースの「CI/CD」→「パイプライン」の下で設定します。「パイプラインを実行」を選択すると、右上の「実行」で、目的のブランチを選択し、以下のフィールドに変数を設定できます。

Gitlab-runner で GPU を使用する¶

以前は、|Gromacs|はKubernetes拡張リソースに対応した、Gitlab-runnerのハック版を使用していました。しかし、Gitlabは残念ながら、これらの機能をマージすることに関心を示していません。また、runnerが進化するにつれて、最新の状態を維持することが難しくなっています。将来的に、ジョブ設定でGPUを直接選択できるようになるかもしれませんが、現時点では、Gitlab-runnerの設定で指定できるようにすることで、CPUのみ、またはNvidia、AMD、Intelの単一またはデュアルGPUデバイスの両方に対応した、個別のrunnerを使用しています。

両方のユーザー（usおよび他のユーザー）が共有のGitLabランナーを使用できるようにするため、トップレベルの構成ファイル：`*.gitlab-ci.yml`には、GitLabランナーで使用するタグを選択するためのいくつかの変数が含まれています。これにより、各ベンダーから単一またはデュアルデバイスを取得できます。また、これらのランナーで利用できる最大デバイス数を設定するための変数も用意されています。もし、必要なハードウェアが不足しているため、テストを実行できない場合は、そのテストを自動的にスキップします。

コンテナ¶

GROMACS プロジェクトのインフラは、Dockerコンテナ化を使用して、自動化されたタスクを分離しています。幅広いテストカバレッジを提供するために、複数のイメージが維持されています。

ビルドに使用するスクリプトと設定ファイルは、リポジトリの admin/containers/ フォルダに保存されています。イメージは、GROMACS プロジェクトのスタッフが手動でビルドし、DockerHubとGitLabにプッシュします。詳細は、https://hub.docker.com/u/gromacs および https://gitlab.com/gromacs/gromacs/container_registry を参照してください。

GitLab コンテナレジストリ¶

CIパイプラインは、Docker Hubからプルするのではなく、GitLabコンテナレジストリを使用します。

プロジェクトのメンバーで、「開発者」またはそれ以上の権限を持つユーザーは、push images <https://docs.gitlab.com/ee/user/packages/container_registry/index.html#build-and-push-images-by-using-docker-commands> をコンテナレジストリにプッシュできます。

Steps:

「個人アクセストークン <https://gitlab.com/-/profile/personal_access_tokens>`__（`ドキュメント）を作成し、write_registry と read_registry のスコープを設定します。ハッシュを保存してください！」
コマンドラインから docker login registry.gitlab.com -u <ユーザー名> -p <ハッシュ> を使用して認証します。
docker push registry.gitlab.com/gromacs/gromacs/<imagename>

現在ビルドされているイメージのセットについては、main ブランチにある buildall.sh を参照してください。

パイプラインジョブ内で、ジョブは image プロパティを使用して Docker イメージを指定します。イメージ名の命名規則については、utility.image_name() を参照してください。 GitLab レジストリから取得したイメージは、上記の識別子と同じで簡単にアクセスできます。移植性を考慮する場合、イメージ識別子の一部には、CI 環境変数を使用する方が適している場合があります。例:

some_job:
  image: ${CI_REGISTRY_IMAGE}/ci-<configuration>
  ...

より詳細な設定をご希望の場合は、以下の代替表現をご検討ください: ${CI_REGISTRY}/${CI_PROJECT_PATH} または ${CI_REGISTRY}/${CI_PROJECT_NAMESPACE}/${CI_PROJECT_NAME}。参照: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html

ツール¶

(ファイル：admin/)

make-release-build.py¶

自動リリースオプション。

usage: make-release-build.py [-h] (--local | --server) [--token TOKEN]
                             [--ssh-key SSH_KEY] [--release | --no-release]
                             [--dry-run | --no-dry-run] [--branch BRANCH]

-h, --help¶: このヘルプメッセージを表示して終了する

--local¶: ローカルモード（パイプラインの実行）で実行する場合に設定します。

--server¶: サーバーで実行する場合（アーティファクトのアップロードモード）に設定します。

--token <token>¶: GitLabへのアクセストークンが必要です。パイプラインの実行には必要です。

--ssh-key <ssh_key>¶: サーバーへのアップロードに必要なSSHキーへのパス。ローカルモードで実行すると、ジョブ内で利用できます。

--release¶

--no-release¶

--dry-run¶

--no-dry-run¶

--branch <branch>¶: パイプラインを実行するブランチ (デフォルト: "main")

trigger-post-merge.py¶

手動でパイプラインを送信するためのオプション

usage: trigger-post-merge.py [-h] [--type TYPE] --token TOKEN
                             [--branch BRANCH]
                             [--regtest-branch REGTEST_BRANCH]
                             [--regtest-commit REGTEST_COMMIT]

-h, --help¶: このヘルプメッセージを表示して終了する

--type <type>¶: どのようなパイプラインを実行するか（デフォルトは「POST_MERGE_ACCEPTANCE」）

--token <token>¶: GitLabへのアクセストークンが必要です。パイプラインの実行には必要です。

--branch <branch>¶: パイプラインを実行するブランチ (デフォルト: "main")

--regtest-branch <regtest_branch>¶: 回帰テストを実行するために使用するブランチ (デフォルトは none で、これは main にフォールバックすることを意味します)

--regtest-commit <regtest_commit>¶: テストを実行するために、regtest-branch の最新コミットを使用する (デフォルト: 空)

admin/containers/buildall.sh¶

NVIDIA の HPC Container Maker <https://github.com/NVIDIA/hpc-container-maker/tree/master/docs> を使用して、scripted_gmx_docker_builds モジュールを使用して Dockerfile を生成します。現在使用されているフラグについては、admin/buildall.sh ファイルを参照してください。スクリプトを実行して、現在生成されているタグ付きのイメージを確認できます。

scripted_gmx_docker_builds.py¶

(ファイル：admin/containers/)

GROMACS CI image creation script

usage: scripted_gmx_docker_builds.py [-h] [--cmake [CMAKE ...]] [--gcc GCC |
                                     --llvm [LLVM] | --oneapi [ONEAPI] |
                                     --intel-llvm [INTEL_LLVM]]
                                     [--ubuntu [UBUNTU] | --centos [CENTOS]]
                                     [--cuda [CUDA]] [--mpi [MPI]]
                                     [--tsan [TSAN]]
                                     [--adaptivecpp [ADAPTIVECPP]]
                                     [--rocm [ROCM]] [--intel-compute-runtime]
                                     [--oneapi-plugin-nvidia]
                                     [--oneapi-plugin-amd] [--clfft [CLFFT]]
                                     [--heffte [HEFFTE]]
                                     [--nvhpcsdk [NVHPCSDK]] [--rocfftmp]
                                     [--doxygen [DOXYGEN]] [--cp2k [CP2K]]
                                     [--hdf5] [--plumed]
                                     [--cross [{aarch64,riscv64}]]
                                     [--libtorch [LIBTORCH]]
                                     [--venvs [VENVS ...]]
                                     [--format {docker,singularity}]

Named Arguments¶

--cmake

Selection of CMake version to provide to base image. (default: ['3.28.0', '3.30.3', '4.0.5'])

--gcc

Select GNU compiler tool chain. (default: 11) Some checking is implemented to avoid incompatible combinations

--llvm

Select LLVM compiler tool chain. Some checking is implemented to avoid incompatible combinations

--oneapi

Select Intel oneAPI package version.

--intel-llvm

Select Intel LLVM release (GitHub tag).

--ubuntu

Select Ubuntu Linux base image. (default: '24.04')

--centos

Select Centos Linux base image.

--cuda

Select a CUDA version for a base Linux image from NVIDIA.

--mpi

Enable MPI (default disabled) and optionally select distribution (default: openmpi)

--tsan

Build special compiler versions with TSAN OpenMP support

--adaptivecpp

Select AdaptiveCpp repository tag/commit/branch.

--rocm

Select AMD compute engine version.

--intel-compute-runtime

Include Intel Compute Runtime.

--oneapi-plugin-nvidia

Install Codeplay oneAPI NVIDIA plugin.

--oneapi-plugin-amd

Install Codeplay oneAPI AMD plugin.

--clfft

Add external clFFT libraries to the build image

--heffte

Select heffte repository tag/commit/branch.

--nvhpcsdk

Select NVIDIA HPC SDK version.

--rocfftmp

Install rocfftMp for current ROCm version

--doxygen

Add doxygen environment for documentation builds. Also adds other requirements needed for final docs images.

--cp2k

Add build environment for CP2K QM/MM support

--hdf5

Install an HDF5 library.

--plumed

Install PLUMED library.

--cross

Possible choices: aarch64, riscv64

Add cross-compilation support for the specified architecture with QEMU emulation

--libtorch

Add build environment for LibTorch support

--venvs

List of Python versions ("major.minor.patch") for which to install venvs. (default: ['3.9.13', '3.12.5'])

--format

Possible choices: docker, singularity

Container specification format (default: 'docker')

サポートされているモジュール：`admin/containers`¶

`scripted_gmx_docker_builds.py`¶

CI テストイメージ用の、ビルディングブロックに基づいた Dockerfile の生成。

GROMACS CI を GitLab で実行するために使用される Docker イメージのセットを生成します。これらのイメージは、さまざまなシステムを網羅するのに十分な範囲のビルド構成ターゲットに基づいて作成され、コンパイラの種類とバージョン、およびアクセラレータや並列通信システムで使用されるライブラリを確認できるようにします。各組み合わせは、ビルド構成辞書内のエントリとして記述され、スクリプトはロジックを分析し、必要に応じてビルドステージを追加します。

NVIDIA HPCCMリポジトリで提供されている例のスクリプトに基づいて。

Reference:

NVIDIA HPC コンテナ作成ツール <https://github.com/NVIDIA/hpc-container-maker>

著者：

ポール・バウアー <paul.bauer.q@gmail.com>
エリック・イランク <ericirrgang@gmail.com>
ジョー・ジョーダン <e.jjordan12@gmail.com>
マーク・アブラハム <mark.j.abraham@gmail.com>
ガウラヴ・ガルグ <gaugarg@nvidia.com>

使用方法:

$ python3 scripted_gmx_docker_builds.py --help
$ python3 scripted_gmx_docker_builds.py --format docker > Dockerfile && docker build .
$ python3 scripted_gmx_docker_builds.py | docker build -

参考

buildall.sh

scripted_gmx_docker_builds.add_base_stage(name: str, input_args, output_stages: MutableMapping[str, hpccm.Stage])¶: 複数の並行ステージで共有される依存関係を定義します。

scripted_gmx_docker_builds.add_cross_compilation_support(args, output_stages: MutableMapping[str, hpccm.Stage])¶: クロスコンパイルツールチェーンとQEMUのサポートを設定します。

scripted_gmx_docker_builds.add_documentation_dependencies(input_args, output_stages: MutableMapping[str, hpccm.Stage])¶: 適切なレイヤーを、doxygen の入力引数に基づいて追加します。

scripted_gmx_docker_builds.add_intel_llvm_compiler_build_stage(input_args, output_stages: Mapping[str, hpccm.Stage])¶

Intel LLVM (オープンソースのoneAPI) の準備段階を分離する。

このステージは分離されており、最終イメージにインストールされるコンポーネントが最小限に抑えられ、環境設定スクリプトを実行できます。これにより、再構築時間と最終イメージのサイズを短縮できます。

scripted_gmx_docker_builds.add_oneapi_compiler_build_stage(input_args, output_stages: Mapping[str, hpccm.Stage])¶

oneAPI の準備段階を分離する。

scripted_gmx_docker_builds.add_python_stages(input_args: Namespace, *, base: str, output_stages: MutableMapping[str, hpccm.Stage])¶

必要な venvs に対応するために、必要なステージを追加します。

各 venv に対して、中間ビルドステージが 1 つ作成されます (「--venv」オプションを参照)。

各ステージは、ホームディレクトリにPythonのインストールと仮想環境の一部を配置します。ホームディレクトリは、'pyenv'ステージによって、メインのビルドステージで使用するために収集されます。

scripted_gmx_docker_builds.add_tsan_compiler_build_stage(input_args, output_stages: Mapping[str, hpccm.Stage])¶

TSAN の準備段階のコストのかかる処理を分離する。

このステージは非常にコストがかかりますが、依存関係は少なく、分離されており、出力は簡単に分割できます（/usr/local）ため、このビルドステージを分離することで、ビルドキャッシュのヒット率を最大化し、再ビルド時間を短縮し、管理作業と最終イメージのサイズを削減できます。

scripted_gmx_docker_builds.base_image_tag(args) → str¶: hpccm.baseimage() を使用して、*イメージ*を生成します。

scripted_gmx_docker_builds.build_stages(args) → Iterable[hpccm.Stage]¶: レシピに指定された args に対応するステージを定義し、順序を決定します。

scripted_gmx_docker_builds.get_cmake_stages(*, input_args: Namespace, base: str)¶

必要なCMakeバージョンに対応するステージ(ステージ)を取得します。

各 CMake バージョンに対して、ベース ステージを基盤として、1 つの中間ビルドステージが作成されます。詳細は、--cmake オプションを参照してください。

各ステージはバージョン番号を使用して、インストール場所を決定します。: /usr/local/cmake-{version}

生成されたパスは、簡単にメインステージにコピーできます。

戻り値:: 「cmake-{version}」というキーを持つ、分離された CMake インストール段階の辞書

scripted_gmx_docker_builds.get_cross_compilation_packages(args)¶: クロスコンパイルに必要なパッケージを取得する。

scripted_gmx_docker_builds.hpccm_distro_name(args) → str¶

*_distro を hpccm.baseimage() で生成する。

Linuxディストリビューションの変数を、hpccmが理解できる形式に変換します。

同じ形式は、より低レベルの hpccm.config.set_linux_distro() でも使用されています。

scripted_gmx_docker_builds.prepare_venv(version: Version) → Sequence[str]¶: 指定されたPythonバージョンのvenvを設定するためのシェルコマンドを取得します。

`utility.py`¶

CIテストおよびビルドコンテナの構成マトリックスを管理するためのユーティリティモジュール。

スタンドアロンのスクリプトとして実行された場合、コマンドライン引数に基づいてDockerイメージの名前を出力します。Dockerイメージの名前は、GROMACS CIパイプラインのジョブで使用される形式です。

例:

$ python3 -m utility --llvm --doxygen
gromacs/ci-ubuntu-24.04-llvm-14-docs

参考

buildall.sh

モジュールとして、インポート可能な引数解析器とDockerイメージ名の生成機能を提供します。

注意: パラースは add_help=False で作成されており、親パラースとして使いやすくしていますが、これにより、完全な生成されたコマンドラインヘルプを表示するには、このパラースから新しいパラースを派生させる必要があります。

例:

import utility.parser
# utility.parser does not support `-h` or `--help`
parser = argparse.ArgumentParser(
    description='GROMACS CI image creation script',
    parents=[utility.parser])
# ArgumentParser(add_help=True) is default, so parser supports `-h` and `--help`

参考

scripted_gmx_docker_builds.py

著者：

ポール・バウアー <paul.bauer.q@gmail.com>
エリック・イランク <ericirrgang@gmail.com>
ジョー・ジョーダン <e.jjordan12@gmail.com>
マーク・アブラハム <mark.j.abraham@gmail.com>
ガウラヴ・ガルグ <gaugarg@nvidia.com>

utility.image_name(configuration: Namespace) → str¶

Docker イメージの名前を生成する。

イメージ名は ci-<slug> という形式で、設定のslugは以下の形式になります:

<distro>-<version>-<compiler>-<major version>[-<gpusdk>-<version>][-<use case>]

この関数は、適切なDockerイメージリポジトリプレフィックスも適用します。

パラメータ:: configuration -- 解析された引数で記述されているDockerイメージの設定。

utility.parser = ArgumentParser(prog='sphinx-build', usage=None, description='GROMACS CI image slug options.', formatter_class=<class 'argparse.HelpFormatter'>, conflict_handler='error', add_help=False)¶

画像パラメータを参照するツール用の、親パーサー。

この argparse パーサーは、利便性を考慮して定義されており、ツールの一部を初期化するために使用できます。

警告

このパーサーは変更しないでください。

代わりに、:py:class:`argparse.ArgumentParser の parents 引数を使用して、それを継承します。

GitLab CI パイプラインの実行¶

設定ファイル¶

ジョブパラメータ¶

スケジューリングとトリガー¶

グローバルなテンプレート¶

ジョブ名¶

回帰テストの更新¶

変数¶

変数の設定¶

Gitlab-runner で GPU を使用する¶

コンテナ¶

GitLab コンテナレジストリ¶

ツール¶

make-release-build.py¶

trigger-post-merge.py¶

admin/containers/buildall.sh¶

scripted_gmx_docker_builds.py¶

Named Arguments¶

サポートされているモジュール：admin/containers¶

scripted_gmx_docker_builds.py¶

utility.py¶

サポートされているモジュール：`admin/containers`¶

`scripted_gmx_docker_builds.py`¶

`utility.py`¶