Refactoring for Dockerfile Quality: A Dive into Developer Practices and Automation Potential

• URL: http://arxiv.org/abs/2501.14131v1
• Date: Thu, 23 Jan 2025 23:10:47 GMT
• Title: Refactoring for Dockerfile Quality: A Dive into Developer Practices and Automation Potential
• Abstract summary: 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.
• Score: 0.0
• License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
• Abstract: Docker, the industry standard for packaging and deploying applications, leverages Infrastructure as Code (IaC) principles to facilitate the creation of images through Dockerfiles. However, maintaining Dockerfiles presents significant challenges. Refactoring, in particular, is often a manual and complex process. This paper explores the utility and practicality of automating Dockerfile refactoring using 600 Dockerfiles from 358 open-source projects. Our study reveals that Dockerfile image size and build duration tend to increase as projects evolve, with developers often postponing refactoring efforts until later stages in the development cycle. This trend motivates the automation of refactoring. To achieve this, we leverage In Context Learning (ICL) along with a score-based demonstration selection strategy. 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, respectively. Additionally, our analysis shows that automated refactoring reduces Dockerfile image size by 2x compared to manual refactoring and 10x compared to smell-fixing tools like PARFUM. This work establishes a foundation for automating Dockerfile refactoring, indicating that such automation could become a standard practice within CI/CD pipelines to enhance Dockerfile quality throughout every step of the software development lifecycle.

Related papers

• Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution [52.50730821321986]
  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.
  arXiv  Detail & Related papers  (2026-07-14T09:12:26Z)
• 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)
• Architecture-Aware Multi-Design Generation for Repository-Level Feature Addition [53.50448142467294]
  RAIM is a multi-design and architecture-aware framework for repository-level feature addition.<n>It shifts away from linear patching by generating multiple diverse implementation designs.<n>Experiments on the NoCode-bench Verified dataset demonstrate that RAIM establishes a new state-of-the-art performance.
  arXiv  Detail & Related papers  (2026-03-02T12:50:40Z)
• SWE-World: Building Software Engineering Agents in Docker-Free Environments [91.17484806743641]
  SWE-World is a Docker-free framework that replaces physical execution environments with a learned surrogate for training and evaluating software engineering agents.<n>We show that SWE-World raises Qwen2.5-Coder-32B from 6.2% to 52.0% via Docker-free SFT, 55.0% with Docker-free RL, and 68.2% with further TTS.
  arXiv  Detail & Related papers  (2026-02-03T11:44:39Z)
• 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)
• Docker Does Not Guarantee Reproducibility [8.363502352389188]
  Containerization technologies like Docker address the problem by encapsulating software environments into shareable snapshots known as images.<n>While Docker is frequently cited in the literature as a tool that enables in theory, the extent of its guarantees and limitations in practice remains under-explored.<n>First, we conduct a systematic review to examine how Docker is framed in scientific discourse on literature.<n>Then, we perform a large-scale empirical study of 5298 Dockerfiles collected from GitHub.
  arXiv  Detail & Related papers  (2026-01-19T08:16:43Z)
• ABC-Bench: Benchmarking Agentic Backend Coding in Real-World Development [72.4729759618632]
  We introduce ABC-Bench, a benchmark to evaluate agentic backend coding within a realistic, executable workflow.<n>We curated 224 practical tasks spanning 8 languages and 19 frameworks from open-source repositories.<n>Our evaluation reveals that even state-of-the-art models struggle to deliver reliable performance on these holistic tasks.
  arXiv  Detail & Related papers  (2026-01-16T08:23:52Z)
• PIPer: On-Device Environment Setup via Online Reinforcement Learning [74.52354321028493]
  Automated environment setup methods could assist developers by providing fully configured environments for arbitrary repositories without manual effort.<n>Recent studies reveal that even state-of-the-art Large Language Models (LLMs) achieve limited success in automating this task.<n>We combine supervised fine-tuning for generating correct scripts and Reinforcement Learning with Verifiable Rewards (RLVR) to adapt it to the task of environment setup.<n>On EnvBench-Python, our method enables Qwen3-8B (a model runnable on consumer hardware) to perform on par with larger models-Qwen3-32B and GPT-4
  arXiv  Detail & Related papers  (2025-09-29T20:03:05Z)
• Bugs in the Shadows: Static Detection of Faulty Python Refactorings [44.115219601924856]
  Python's dynamic type system poses significant challenges for automated code transformations.<n>Our analysis uncovered 29 bugs across four types from a total of 1,152 attempts.<n>These results highlight the need to improve the robustness of current Python tools to ensure the correctness of automated code transformations.
  arXiv  Detail & Related papers  (2025-07-01T18:03:56Z)
• Toward Automated Test Generation for Dockerfiles Based on Analysis of Docker Image Layers [1.1879716317856948]
  The process for building a Docker image is defined in a text file called a Dockerfile. A Dockerfile can be considered as a kind of source code that contains instructions on how to build a Docker image. We propose an automated test generation method for Dockerfiles based on processing results rather than processing steps.
  arXiv  Detail & Related papers  (2025-04-25T08:02:46Z)
• Paper2Code: Automating Code Generation from Scientific Papers in Machine Learning [57.09163579304332]
  We introduce PaperCoder, a framework that transforms machine learning papers into functional code repositories. PaperCoder operates in three stages: planning, designs the system architecture with diagrams, identifies file dependencies, and generates configuration files. We then evaluate PaperCoder on generating code implementations from machine learning papers based on both model-based and human evaluations.
  arXiv  Detail & Related papers  (2025-04-24T01:57:01Z)
• 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. We developed a dependency taxonomy based on Dockerfile syntax and a historical modification analysis to prioritize frequently modified instructions. 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)
• Thinking Longer, Not Larger: Enhancing Software Engineering Agents via Scaling Test-Time Compute [61.00662702026523]
  We propose a unified Test-Time Compute scaling framework that leverages increased inference-time instead of larger models. Our framework incorporates two complementary strategies: internal TTC and external TTC. We demonstrate our textbf32B model achieves a 46% issue resolution rate, surpassing significantly larger models such as DeepSeek R1 671B and OpenAI o1.
  arXiv  Detail & Related papers  (2025-03-31T07:31:32Z)
• An LLM-based Agent for Reliable Docker Environment Configuration [9.436480907117415]
  Repo2Run is an agent designed to fully automate environment configuration and generate executable Dockerfiles for arbitrary Python repositories. We address two major challenges: (1) enabling the LLM agent to configure environments within isolated Docker containers, and (2) ensuring the successful configuration process is recorded and accurately transferred to a Dockerfile without error. We evaluate Repo2Runon our proposed benchmark of 420 recent Python repositories with unit tests, where it achieves an 86.4% success rate, outperforming the best baseline by 63.9%.
  arXiv  Detail & Related papers  (2025-02-19T12:51:35Z)
• Codev-Bench: How Do LLMs Understand Developer-Centric Code Completion? [60.84912551069379]
  We present the Code-Development Benchmark (Codev-Bench), a fine-grained, real-world, repository-level, and developer-centric evaluation framework. Codev-Agent is an agent-based system that automates repository crawling, constructs execution environments, extracts dynamic calling chains from existing unit tests, and generates new test samples to avoid data leakage.
  arXiv  Detail & Related papers  (2024-10-02T09:11:10Z)
• Temporal Analysis and Repair of Flaky Dockerfiles [6.518508607788089]
  Dockerfile flakiness is characterized by inconsistent build behavior without Dockerfile or project source code changes. We present a comprehensive taxonomy of common flakiness categories, including dependency-related errors and server connectivity issues. We introduce FlakiDock, a tool leveraging large language models and retrieval-augmented generation techniques to automatically repair flaky Dockerfiles.
  arXiv  Detail & Related papers  (2024-08-09T23:17:56Z)
• Leveraging Large Language Models for Efficient Failure Analysis in Game Development [47.618236610219554]
  This paper proposes a new approach to automatically identify which change in the code caused a test to fail. The method leverages Large Language Models (LLMs) to associate error messages with the corresponding code changes causing the failure. Our approach reaches an accuracy of 71% in our newly created dataset, which comprises issues reported by developers at EA over a period of one year.
  arXiv  Detail & Related papers  (2024-06-11T09:21:50Z)
• Patterns of Multi-Container Composition for Service Orchestration with Docker Compose [5.1861106408299635]
  This work curates a dataset of successful projects that employ Docker Compose as an orchestration tool to run multiple service containers. The collection of data and analysis enables the identification and naming of repeating multi-container composition patterns. These patterns highlight how software systems are orchestrated in the real-world and can give examples to anybody wishing to compose their own service orchestrations.
  arXiv  Detail & Related papers  (2023-05-18T20:32:58Z)
• Do code refactorings influence the merge effort? [80.1936417993664]
  Multiple contributors frequently change the source code in parallel to implement new features, fix bugs, existing code, and make other changes. These simultaneous changes need to be merged into the same version of the source code. Studies show that 10 to 20 percent of all merge attempts result in conflicts, which require the manual developer's intervention to complete the process.
  arXiv  Detail & Related papers  (2023-05-10T13:24:59Z)
• DRIVE: Dockerfile Rule Mining and Violation Detection [6.510749313511299]
  A Dockerfile defines a set of instructions to build Docker images, which can then be instantiated to support containerized applications. Recent studies have revealed a considerable amount of quality issues with Dockerfiles. We propose a novel approach to mine implicit rules and detect potential violations of such rules in Dockerfiles.
  arXiv  Detail & Related papers  (2022-12-12T01:15:30Z)
• CLUTR: Curriculum Learning via Unsupervised Task Representation Learning [130.79246770546413]
  CLUTR is a novel curriculum learning algorithm that decouples task representation and curriculum learning into a two-stage optimization. We show CLUTR outperforms PAIRED, a principled and popular UED method, in terms of generalization and sample efficiency in the challenging CarRacing and navigation environments.
  arXiv  Detail & Related papers  (2022-10-19T01:45:29Z)
• Studying the Practices of Deploying Machine Learning Projects on Docker [9.979005459305117]
  Docker is a containerization service that allows for convenient deployment of websites, databases, applications' APIs, and machine learning (ML) models with a few lines of code. We conducted an exploratory study to understand how Docker is being used to deploy ML-based projects.
  arXiv  Detail & Related papers  (2022-06-01T18:13:30Z)

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.