Need a way to determine what release of checkout_externals was used in a specific CESM tag
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
調査の方向性
まず、CESM のタグの plans ページを、CESM を clone してその log を調べることで見つかる checkout_externals の参照と比較します。タグに取り込まれたときに plans ページのどこで checkout_externals のバージョンを示せるかを特定します。完了の条件は、各タグページが手作業で log を調べなくてもそのバージョンを特定できることです。
索引モデルが issue の本文から書いたものです。
説明
Summary of Issue:
External components which maintain standalone capability need to maintain the checkout_externals version. Typically for CAM's case we take a previously tested CESM tag and duplicate the externals used in it. This is now being extended to needing to also maintain the version of checkout_externals. We want to identify and use the version of checkout_externals that was used in a specific CESM tag. Being able to check this easily, becomes more important as time goes on and checkout_externals is only updated sporadically - we need an easy way to determine that it has been updated.
Expected behavior and actual behavior:
An ideal solution would be for the plans page to have a location somewhere on each tag's page which indicates the checkout_externals which was used. Perhaps this could be populated (automatically?) when checkout_externals is brought into the CESM tag. Currently, there is no good way to determine the checkout_externals tag other than cloning cesm and mining the log.
Steps to reproduce the problem. Include externals description file(s) and link to public repository):
N/A
What is the changeset ID of the code, and the machine you are using:
N/A
have you modified the code? If so, it must be committed and available for testing:
N/A
Screen output or log file showing the error message and context:
N/A
@bjandre suggested that I bring @mvertens , @fischer-ncar , @bertinia and possibly @jedwards4b into this discussion.
- 主要言語
- Python
- スター
- 495
- フォーク
- 253
- 平均マージ
- 34分
- マージ済み PR（30日）
- 4
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
ESCOMP/CESM のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
-
fleximod-test GitHub workflow isn't working right対応中かも @samsrabin が 1 日前に担当しました。 オープンbug
-
There are no default PE layouts using the tx2_3v3 grid再び着手できるかも @mnlevy1981 が 58 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
-
No default PE layout on derecho for CESM3 development runs with MARBL再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
似ている issue
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
awslabs/social-messaging-agent-runtime-toolkit#140 ·
メンテナーはふだん 1 日以内に返信
-
subtask
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
fga-eps-mds/2026.2-MeasureSoftGram-DOC#187 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
txn2/mcp-data-platform#2493 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
YO-WHATS-UP2/minigit#78 ·
メンテナーはふだん 3 日以内に返信
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
liberation-data/drivine-python#432 ·
メンテナーはふだん 1 日以内に返信