論文の概要: Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution
- arxiv url: http://arxiv.org/abs/2607.12541v1
- Date: Tue, 14 Jul 2026 09:12:26 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-07-15 17:08:30.093573
- Title: Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution
- Title（参考訳）: ドリフトの試行 - ソフトウェア進化の過程でDockerfileドリフトのコンテキスト対応の修復
- Abstract要約: Cadreは、Dockerfileの自動ドリフト修復のためのコンテキスト認識フレームワークである。
CDGは、各Dockerfile命令をファイルレベルとインストラクション間の依存関係にマップする。
DodeXはGitHub Actions CIログから現実のDockerfileドリフトインスタンスをマイニングする。
- 参考スコア（独自算出の注目度）: 52.50730821321986
- License: http://creativecommons.org/licenses/by/4.0/
- Abstract: Docker is widely used to create reproducible build environments, but Dockerfile drift, the divergence between a Dockerfile and its evolving source code, can cause CI/CD builds to fail. Existing rule-based and retrieval-based repair approaches analyze Dockerfiles in isolation and therefore struggle with context-dependent failures. We present Cadre, a context-aware framework for automated Dockerfile drift repair. Cadre uses static analysis to construct a Context-aware Dependency Graph (CDG), which maps each Dockerfile instruction to its file-level and inter-instruction dependencies. Guided by the CDG, Cadre first selects the context causally relevant to a failure and then generates a targeted patch from that context. We also introduce DodeX, a pipeline that mines real-world Dockerfile drift instances from GitHub Actions CI logs while preserving the complete build configurations omitted by static-snapshot datasets. Using DodeX, we construct $D^3$, a benchmark of 1,040 drift instances reproducible locally with the original CI parameters. Across $D^3$, Cadre achieves a 35.22\% repair rate, 2.78$\times$ that of the rule-based baseline and 1.24$\times$ that of the best LLM-based baseline. Its two-step workflow keeps 95.25\% of prompts below 30k tokens and avoids the prompt-overflow failures that prevent competing LLM-based methods from producing patches in 41 to 58 cases per method. Ablation results confirm that both the CDG and the two-step workflow improve repair performance. Cadre's advantage over diff-only approaches also increases as drift ages across commits, supporting explicit dependency modeling for context-aware infrastructure-as-code maintenance. Code and data are available at https://github.com/dw763j/Cadre.
- Abstract（参考訳）: Dockerは再現可能なビルド環境を作成するために広く使用されているが、Dockerfileのドリフト、Dockerfileとその進化するソースコードの相違により、CI/CDビルドが失敗する可能性がある。
既存のルールベースおよび検索ベースの修復アプローチは、Dockerfileを分離して分析し、そのためコンテキスト依存の障害に対処する。
Cadreは、Dockerfileドリフトの自動修復のためのコンテキスト対応フレームワークです。
Cadreは静的解析を使用して、各Dockerファイル命令をファイルレベルとインストラクション間の依存関係にマッピングする、Context-aware Dependency Graph(CDG)を構築する。
CDGによってガイドされたCadreは、まず障害に関連するコンテキストを選択し、そのコンテキストからターゲットパッチを生成する。
これは、GitHub Actions CIログから実際のDockerfileドリフトインスタンスをマイニングするパイプラインで、静的スナップショットデータセットによって省略された完全なビルド設定を保存する。
DodeXを用いて、元のCIパラメータでローカルに再現可能な1040のドリフトインスタンスのベンチマークである$D^3$を構築した。
D^3$を越えれば、カドレは35.22.%の修理率、2.78$\times$ルールベースのベースライン、1.24$\times$最高のLCMベースのベースラインとなる。
2段階のワークフローでは、プロンプトの95.25\%を30kトークン以下に保ち、競合するLCMベースのメソッドが1メソッドあたり41から58のケースでパッチを生成するのを防ぐプロンプトオーバーフローの失敗を避ける。
アブレーションの結果,CDGと2ステップのワークフローの両方で修復性能が向上した。
差分のみのアプローチに対するCadreのアドバンテージは、コミット間のドリフト年齢の増加とともに、コンテキスト対応のインフラストラクチャ・アズ・コードメンテナンスのための明示的な依存性モデリングをサポートする。
コードとデータはhttps://github.com/dw763j/Cadre.comで公開されている。
関連論文リスト
- IACM-RL: Intent-Aware Context Management and Reinforcement Learning for Complex Tool Invocation under Dynamic Intent Fluctuations [86.93902234336393]
IACM-RLは、堅牢なツール呼び出しのための包括的なフレームワークである。
我々は、13のきめ細かいゆらぎシナリオにまたがる軌道を合成するDynamicIntentパイプラインを導入する。
第2に、IACM-RLはBeliefStateベースのセルフ生成コンテキストマネージャをデプロイする。
論文 参考訳（メタデータ） (2026-08-03T12:09:50Z) - Distill Once, Adapt Life-Long: Exploring Dataset Distillation for Continual Test-Time Adaptation [58.69982623883049]
連続テスト時間適応(CTTA)は、ラベル付きデータなしでオンラインに適応することで、進化するターゲットドメインの下でモデルパフォーマンスを維持することを目的としている。
DO-ALL(Distill Once, Adapt Life-Long)は、ソース情報をコンパクトでプライバシに意識した形で再考するプラグイン・アンド・プレイのフレームワークである。
論文 参考訳（メタデータ） (2026-06-18T13:11:13Z) - From Patches to Trajectories: Privileged Process Supervision for Software-Engineering Agents [56.31499185764872]
教師の長い軌道上の監督された微調整(SFT)は、オープンソフトウェアエンジニアリング(SWE)エージェントに調査と推論を浸透させる主要な方法である。
本稿では,P2T (Patches-to-Trajectories) を提案する。P2T (Patches-to-Trajectories) は,P2T (Patches-to-Trajectories) において,P2T (Patches-to-Trajectories) とP2T (Patches-to-Trajectories) の2つの最適化法である。
論文 参考訳（メタデータ） (2026-05-21T04:54:55Z) - Beyond the Tip of the Iceberg: Understanding SATD in Dockerfiles through the Lens of Co-evolution [10.059038321113546]
我々は,Dockerfileの自己許容技術的負債(SATD)と関連するソースコードについて検討する。
受け入れイベントの約27%と返済イベントの40%が、Dockerfile以外のアーティファクトに結合されていることが分かりました。
論文 参考訳（メタデータ） (2026-05-20T14:26:56Z) - RACER: Retrieval-Augmented Contextual Rapid Speculative Decoding [80.12789199134511]
大規模言語モデル(LLM)における自己回帰デコーディングは、ステップ毎に1つのトークンを生成し、高い推論遅延を引き起こす。
我々は,検索した正確なパターンとロジット駆動の将来の手がかりを統合する軽量でトレーニング不要な $textbfRACER を提案する。
Spec-Bench、HumanEval、MGSM-ZHの実験では、RACERは推論を継続的に加速し、自動回帰デコーディングよりも2倍以上のスピードアップを達成した。
論文 参考訳（メタデータ） (2026-04-16T11:23:55Z) - It's Not Just Timestamps: A Study on Docker Reproducibility [0.3553493344868413]
Dockerの測定パイプラインを構築して,Dockerfileを含む2,000のGitHubリポジトリのサンプルに適用します。
構築可能なイメージは56%に過ぎず、2.7%はインフラストラクチャの設定なしでビット単位で再現可能である。
これらのパターンから具体的なDockerfileガイドラインを導き、再現可能なコンテナに対する将来のlinterとContinuous Integration(CI)チェックを通知する方法について説明します。
論文 参考訳（メタデータ） (2026-02-03T00:26:53Z) - SwingArena: Competitive Programming Arena for Long-context GitHub Issue Solving [90.32201622392137]
We present SwingArena, a competitive evaluation framework for Large Language Models (LLMs)。
従来の静的ベンチマークとは異なり、SwingArenaはLLMをイテレーションとして組み合わせて、テストケースを作成し、継続的インテグレーション(CI)パイプラインを通じてパッチを検証するパッチとレビュアーを生成することで、ソフトウェアのコラボレーションプロセスをモデル化する。
論文 参考訳（メタデータ） (2025-05-29T18:28:02Z) - Doctor: Optimizing Container Rebuild Efficiency by Instruction Re-Orchestration [11.027705516378875]
命令の再注文によってDockerfileのビルド効率を改善する方法であるDoctorを提案する。
我々はDockerfileの構文に基づく依存性分類と、頻繁に修正される命令を優先順位付けするための履歴修正分析を開発した。
実験の結果、Doctorは92.75%のDockerfileを改善し、ビルド時間を平均26.5%削減し、ファイルの12.82%が50%以上削減された。
論文 参考訳（メタデータ） (2025-04-02T13:53:35Z) - Refactoring for Dockerfile Quality: A Dive into Developer Practices and Automation Potential [0.0]
本稿では,358のオープンソースプロジェクトの600fileを使用したDockerfileの自動化の有用性と実用性について検討する。
提案手法では,画像サイズが平均32%減少し,ビルド期間が6%減少し,77%,91%の症例で理解性と保守性が向上した。
論文 参考訳（メタデータ） (2025-01-23T23:10:47Z) - Dockerfile Flakiness: Characterization and Repair [6.518508607788089]
Dockerfileのフレキネスに関する最初の包括的な研究で、Docker化された8,132のプロジェクトの9ヶ月にわたる分析を特徴としている。
本稿では,依存性エラーやサーバ接続の問題など,一般的なフラキネスの原因を分類する分類法を提案する。
静的および動的解析,類似性検索,および大規模言語モデルを用いた反復的フィードバックループを組み合わせた新しい修復フレームワークであるFLAKIDOCKを紹介する。
論文 参考訳（メタデータ） (2024-08-09T23:17:56Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。