Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution

• URL: http://arxiv.org/abs/2607.12541v1
• Date: Tue, 14 Jul 2026 09:12:26 GMT
• Title: Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution
• Abstract summary: Cadre is a context-aware framework for automated Dockerfile drift repair.<n>CDG maps each Dockerfile instruction to its file-level and inter-instruction dependencies.<n>DodeX mines real-world Dockerfile drift instances from GitHub Actions CI logs.
• Score: 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.

Related papers

• IACM-RL: Intent-Aware Context Management and Reinforcement Learning for Complex Tool Invocation under Dynamic Intent Fluctuations [86.93902234336393]
  IACM-RL is a comprehensive framework for robust tool invocation.<n>We introduce the DynamicIntent pipeline, synthesizing trajectories across 13 fine-grained fluctuation scenarios.<n>Second, IACM-RL deploys a BeliefState-based Self-Generated Context Manager.
  arXiv  Detail & Related papers  (2026-08-03T12:09:50Z)
• Distill Once, Adapt Life-Long: Exploring Dataset Distillation for Continual Test-Time Adaptation [58.69982623883049]
  Continual Test-Time Adaptation (CTTA) aims to maintain model performance under evolving target domains by adapting online without labeled data.<n>We introduce DO-ALL (Distill Once, Adapt Life-Long), a plug-and-play framework that revisits source information in a compact and privacy-conscious form.
  arXiv  Detail & Related papers  (2026-06-18T13:11:13Z)
• From Patches to Trajectories: Privileged Process Supervision for Software-Engineering Agents [56.31499185764872]
  Supervised fine-tuning (SFT) on long teacher trajectories is the dominant way to instill investigation and reasoning in open software-engineering (SWE) agents.<n>We propose Patches-to-Trajectories (P2T), which uses $pstar$ as privileged information during curation and formulates trajectory construction as bi-objective optimization over per-step effectiveness and trajectory length.
  arXiv  Detail & Related papers  (2026-05-21T04:54:55Z)
• Beyond the Tip of the Iceberg: Understanding SATD in Dockerfiles through the Lens of Co-evolution [10.059038321113546]
  We study self-admitted technical debt (SATD) in Dockerfiles alongside the related source code.<n>We find that approximately 27% of admission events and 40% of repayment events are coupled to non-Dockerfile artifacts.
  arXiv  Detail & Related papers  (2026-05-20T14:26:56Z)
• RACER: Retrieval-Augmented Contextual Rapid Speculative Decoding [80.12789199134511]
  Autoregressive decoding in Large Language Models (LLMs) generates one token per step, causing high inference latency.<n>We propose $textbfRACER, a lightweight and training-free method that integrates retrieved exact patterns with logit-driven future cues.<n>Experiments on Spec-Bench, HumanEval, and MGSM-ZH demonstrate that RACER consistently accelerates inference, achieving more than $2times$ speedup over autoregressive decoding.
  arXiv  Detail & Related papers  (2026-04-16T11:23:55Z)
• It's Not Just Timestamps: A Study on Docker Reproducibility [0.3553493344868413]
  We build a Docker measurement pipeline and apply it to a sample of 2,000 GitHub repositories that contained a Dockerfile.<n>We found that only 56% produce any buildable image, and just 2.7% of those are bitwise reproducible without any infrastructure configurations.<n>We derive concrete Dockerfile guidelines from these patterns and discuss how they can inform future linters and Continuous Integration (CI) checks for reproducible containers.
  arXiv  Detail & Related papers  (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)<n>Unlike traditional static benchmarks, SwingArena models the collaborative process of software by pairing LLMs as iterations, who generate patches, and reviewers, who create test cases and verify the patches through continuous integration (CI) pipelines.
  arXiv  Detail & Related papers  (2025-05-29T18:28:02Z)
• Doctor: Optimizing Container Rebuild Efficiency by Instruction Re-Orchestration [11.027705516378875]
  We present Doctor, a method for improving Dockerfile build efficiency through instruction re-ordering.<n>We developed a dependency taxonomy based on Dockerfile syntax and a historical modification analysis to prioritize frequently modified instructions.<n>Experiments show Doctor improves 92.75% of Dockerfiles, reducing rebuild time by an average of 26.5%, with 12.82% of files achieving over a 50% reduction.
  arXiv  Detail & Related papers  (2025-04-02T13:53:35Z)
• Refactoring for Dockerfile Quality: A Dive into Developer Practices and Automation Potential [0.0]
  This paper explores the utility and practicality of automating Dockerfile using 600files from 358 open-source projects.<n>Our approach leads to an average reduction of 32% in image size and a 6% decrease in build duration, with improvements in understandability and maintainability observed in 77% and 91% of cases.
  arXiv  Detail & Related papers  (2025-01-23T23:10:47Z)
• Dockerfile Flakiness: Characterization and Repair [6.518508607788089]
  We present the first comprehensive study of Dockerfile flakiness, featuring a nine-month analysis of 8,132 Dockerized projects.<n>We propose a taxonomy categorizing common flakiness causes, including dependency errors and server connectivity issues.<n>We introduce FLAKIDOCK, a novel repair framework combining static and dynamic analysis, similarity retrieval, and an iterative feedback loop powered by Large Language Models.
  arXiv  Detail & Related papers  (2024-08-09T23:17:56Z)

This list is automatically generated from the titles and abstracts of the papers in this site.

This site does not guarantee the quality of this site (including all information) and is not responsible for any consequences.