Pith. sign in

REVIEW 4 major objections 6 minor 53 references

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

T0 review · 4 major / 6 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Automated Dockerfile refactoring cuts image size 32%

desk verdict A serious first study on automating Dockerfile refactoring with ICL, but a too-narrow behavior-preservation definition weakens the core claim. read the letter →

arxiv 2501.14131 v1 pith:7ISXMO6P submitted 2025-01-23 cs.SE

Emna Ksontini , Meriem Mastouri , Rania Khalsi , Wael Kessentini This is my paper · ORCID
classification cs.SE
keywords Dockerfilerefactoringin-contextlearninglargelanguagemodelsimagesizereductiontechnicaldebtinfrastructureascodeGPT-4obuildduration
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper claims that Dockerfile refactoring—a task developers usually put off until a project's middle or late stages—can be automated effectively with a large language model using in-context learning. The authors analyze 600 refactored Dockerfiles from 358 open-source projects and find that image size and build duration grow as projects age, while refactoring activity clusters late. Their method feeds the model up to 50 refactoring examples selected by a score that mixes textual similarity with measured quality gains. In the best configuration, it reduced image size by 32% on average (322 MB per build, 35 GB total), cut build duration by 6%, and improved maintainability and understandability in 91% and 77% of cases, respectively. They also report that automated refactoring reduced image size twice as much as developers' manual refactoring and about ten times as much as the smell-fixing tool PARFUM.

What carries the argument

The load-bearing mechanism is a score-based demonstration selection strategy for in-context learning. For a test Dockerfile, each candidate demonstration is scored as the weighted sum of five components—textual similarity by BM-25, understandability gain, maintainability gain, image-size reduction, and build-duration reduction—and the top-ranked examples are inserted into the prompt ordered from highest to lowest score, closest to the query. The prompt itself is the template $P = \{N + RD + V_{Before\_Test}\}$, where $N$ is the task description with definitions of all refactoring actions, $RD$ is the chosen demonstrations, and $V_{Before\_Test}$ is the input Dockerfile. This selection is what lets the model see the most relevant and most improved examples before generating its own refactoring; the paper finds that the number of demonstrations is a key driver of improvement, rising from a 38% build success rate at zero shots to 63% at 50 shots.

What would settle it

Take one of the LLM-refactored Dockerfiles that switched base images (for example, node:9.11 to node:9.11-slim) and run the application's own test suite under both the original and refactored images; if the tests pass differently or the application fails at runtime, the behavior-preservation filter missed functional changes, which would undermine the paper's claim that the quality gains come with unchanged behavior.

Watch

Extended reading notes

Core claim

The paper's central claim is that in-context learning with a score-based demonstration selection strategy lets a single LLM (GPT-4o) perform refactorings that reduce technical debt across an entire Dockerfile, not just inside RUN instructions. With 50 demonstrations, 63% of the generated Dockerfiles built successfully, successful builds shrank by an average of 32% (322 MB), and build duration fell by 6%, with 77% of refactorings improving understandability and 91% improving maintainability. Comparing only the 66 Dockerfiles that both methods built successfully, the LLM brought median image size from 599 MB to 95 MB (an 85% reduction) while developers only reached 340 MB (43%), and the LLM improved maintainability and understandability in a larger share of cases. The authors conclude that automated Dockerfile refactoring outperforms both manual refactoring and smell-repair tools, and that it could serve as a new standard step in CI/CD pipelines.

Load-bearing premise

The paper assumes that a Dockerfile's functional behavior is fully determined by the files it copies in (COPY/ADD) and the startup command (ENTRYPOINT/CMD), so refactorings that change the base image or installed packages are counted as behavior-preserving even though they can change runtime behavior.

Editorial extensions

If this is right

  • CI/CD pipelines could adopt the 50-shot scoring recipe as an automated refactoring step, catching image bloat and maintainability loss before they accumulate.
  • Teams using this automation would face a measurable trade-off: smaller images tend to come with longer build durations (-0.60 correlation), so the pipeline would need to target one objective.
  • Developers' habit of refactoring late—after image size and build duration have already grown—means automation could be most valuable early, before the debt builds.
  • The comparison against PARFUM suggests that whole-file refactoring (restructuring stages and images) is a more powerful lever than smell repair inside RUN commands.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Inference: Because the paper only checks behavior preservation for COPY/ADD and ENTRYPOINT/CMD, a production deployment of this automation should add a runtime validation step—running the application's tests after refactoring—to catch functional changes the paper's filter would miss.
  • Inference: The score's equal weighting (0.2 per component) is a design choice the paper does not test; reweighting toward image size or build duration could yield a configuration that improves both, since the observed negative correlations sit at the demonstration-selection level.
  • Inference: The paper measures developer refactorings as they actually occurred, not as an idealized expert baseline; a controlled study with experts given the same task would clarify whether the 2x gap is due to the LLM's strategy or to developers' lack of time or incentive.
  • Inference: The finding that build context errors caused 52% of LLM refactoring failures suggests a cheap extension: a pre-check that validates COPY/ADD paths against the declared build context before the refactoring is proposed, which the paper discusses only as future work.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper studies Dockerfile refactoring as practiced by developers and proposes an LLM-based automation approach using GPT-4o with in-context learning (ICL). The dataset consists of 600 Dockerfile revision pairs mined from 358 open-source projects, split into 398 training and 202 test revisions. RQ1 analyzes how image size and build duration evolve over project lifecycles and when developers tend to refactor. RQ2 evaluates zero-shot, one-shot, and few-shot (20/30/50 demonstration) prompting, using a score-based demonstration-selection strategy defined in Eq. (1). RQ3 compares the best automated refactoring (50-shot) with the developers' own refactorings and with the PARFUM smell-repair tool. RQ4 analyzes build failure causes via qualitative inspection. The headline results are a 63% build success rate for 50-shot, a 32% average image-size reduction (322 MB), a 6% build-duration reduction, and understandability/maintainability improvements in 77%/91% of cases; the paper also claims a 2x image-size reduction over manual refactoring and a 10x reduction over PARFUM.

Significance. If the results are valid, this is a substantial contribution to the emerging area of LLM-based infrastructure-as-code maintenance. The study is the first large-scale evaluation of automated Dockerfile refactoring with ICL, and it includes an original demonstration-selection score, a manual evaluation by six industry developers with a Cohen's kappa of 0.84, a comparison against both human developers and an existing smell-fixing tool, and a qualitative analysis of build failures. The replication package is named, and the authors provide detailed figures. However, the validity of the headline claims depends on a behavior-preservation definition that is too narrow, and the automated-vs-manual comparison is computed on a highly selected subset. These issues are load-bearing and would need to be addressed before the central contribution can be accepted.

major comments (4)
  1. [Section III-B and Sections IV-B/IV-C] The paper defines functional behavior as covering only COPY/ADD and ENTRYPOINT/CMD, explicitly excluding the base image (FROM) and installed packages (RUN). This definition is used both to filter the dataset and to validate LLM refactorings in RQ2. The case study in Figure 7 shows an 'Update Image Tag' refactoring from node:9.11 to node:9.11-slim, and the paper's own RQ4 analysis attributes build failures to base-image changes and dependency errors after refactoring. Since slim images commonly omit runtime libraries and packages can alter application behavior, the refactorings measured in the headline results (32% image-size reduction, 91%/77% maintainability/understandability improvements) are not demonstrated to be behavior-preserving. The authors should broaden the behavior check to include base-image and dependency changes, or clearly scope the claims to the narrow definition and justify why that scope is meaningful for refactoring.
  2. [Section IV-C, Table I, Figure 6] The automated-vs-manual comparison is performed on only the 66 Dockerfiles that built successfully under both the 50-shot LLM and the developer, which is 33% of the 202 test files. The abstract's '2x' claim is drawn from medians over this nonrandom subset, while the build-success-rate comparison in Table I uses the full 202-file set. The two analyses therefore address different populations, and the comparison does not account for the trade-off between success rate and quality gains. Please report results on the full test set with an explicit treatment of build failures (for example, as lower bounds or via imputation), and justify the subset analysis as a separate robustness check.
  3. [Section IV-C and Section IV-B] No statistical significance tests are reported for any comparison: between the LLM and developers, between the LLM and PARFUM, or across prompting settings. The improvement/deterioration rates and average reductions in Table I and Figure 6 are presented as point estimates, and the Spearman correlations in Section IV-B are given without p-values or confidence intervals. Given that the central claim is that automated refactoring outperforms manual refactoring, the authors should add appropriate significance tests (for example, paired tests on the 66-case subset, or bootstrap confidence intervals) and report effect sizes.
  4. [Section III-D, Eq. (1)] The demonstration-selection score assigns equal hand-picked weights (0.2 each) to five components, including the same metrics that are later used for evaluation. Because the test set is held out, this is not circular for the evaluation itself, but the paper provides no ablation or sensitivity analysis isolating the effect of the score-based selection. Without a comparison to random demonstration selection or to a simpler textual-similarity-only baseline, the contribution of the scoring function to the improved few-shot results is not established. A short ablation would be sufficient to support the claim that the selection strategy matters beyond the number of demonstrations.
minor comments (6)
  1. [Section III-B] The definition of functional behavior contains the typo 'ENTERPOINT/CMD'; this should read 'ENTRYPOINT/CMD'.
  2. [Table I and Section IV-C] The developer build success rate is listed as 94/202 in Table I but as 92/202 in the RQ3 text; these numbers should be reconciled.
  3. [Table I] For the 50-shot row, an average image-size reduction of 322 MB over 128 successful builds implies a total reduction of roughly 41 GB, not the reported 35 GB; please clarify whether the total is computed over the 128 builds or over a different denominator, such as only the improved cases.
  4. [Section IV-A] The criteria for removing the three outliers with 300-500% image-size increases are not specified; state the exact exclusion rule and report whether the RQ1 findings are sensitive to this removal.
  5. [Figure 1] Figure 1 is very dense and the text is difficult to read; a higher-resolution version and a clearer separation of the four RQ pipelines would improve readability.
  6. [References] Reference [38] contains a placeholder URL (https://arxiv.org/abs/XXXX.XXXXX%7D%7D) and reference [24] lists the author as 'iwei Xu' (likely 'Yiwei Xu'); both entries should be corrected.

Circularity Check

1 steps flagged · score 5.0 of 10

Behavior-preservation validation is self-definitional (only COPY/ADD and ENTRYPOINT/CMD count as behavior), but the core image-size/build-duration results are independently measured on a held-out test set; partial circularity.

  1. self definitional [Section III-B (Refactored Dockerfiles Data Collection); applied in Section IV-B (RQ2) behavior assessment]
    "Functional behavior refers to Dockerfile elements that affect the application’s runtime behavior, namely application files (COPY/ADD) and startup commands (ENTERPOINT/CMD). ... The behavior assessment revealed a very low incidence of functional changes, with only 5 cases (2 zero-shot, 3 one-shot) where Dockerfile behavior changed post-refactoring."

    The paper defines 'functional behavior' to include only COPY/ADD and ENTRYPOINT/CMD changes, so any change to a base image (e.g., node:9.11 to node:9.11-slim), a RUN-installed package, ENV, WORKDIR, or EXPOSE is by definition not a behavior change. This definition is used both to pre-screen the dataset ('excluded files with functional behavior changes') and to assess the LLM outputs in RQ2. The resulting 'very low incidence' of behavior changes (5 cases) is therefore an artifact of the operationalization, not empirical evidence that the refactorings preserve runtime behavior.

full rationale

I examined the paper's derivation chain for the claimed predictions. The main empirical results (average 32% image-size reduction, 6% build-duration reduction, 91%/77% maintainability/understandability improvements) are measured on a held-out test set of 202 Dockerfiles, and the 50-shot configuration is not fitted to those outcomes; the demonstration-selection score in Eq. (1) uses the same four quality metrics as evaluation, but it ranks training demonstrations only and never touches the test set, so this is not a fitted-input-called-prediction circularity. The reliance on the authors' prior DRMiner tool [28] and technical-debt taxonomy [8] is substantial but not circular for scoring purposes: DRMiner is an externally published tool with a reported F1 of 0.94, and [8] is a peer-reviewed empirical study, so these are independent supports rather than unverified self-citations. The one genuine circularity is the operational definition of 'functional behavior,' which is restricted to COPY/ADD and ENTRYPOINT/CMD. Because both dataset filtering and RQ2's behavior-change assessment use that definition, the low behavior-change rate is true by construction rather than by verification. This partially undermines the 'refactoring' (behavior-preserving) characterization of the generated edits, even though the objective quality metrics remain independently measured. Overall, the core quantitative contributions are not forced by the inputs, but the behavioral-safety claim is self-definitionally limited, giving a partial-circularity score of 5.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The central results rest on hand-chosen design decisions (score weights, shot counts, outlier removal) and domain assumptions about refactoring detection and behavior preservation. No invented entities are introduced.

free parameters (3)
  • Demonstration selection weights (w_text, w_und, w_maint, w_size, w_duration) = 0.2, 0.2, 0.2, 0.2, 0.2
    Equal weights in the score formula (Section III-D) are chosen by hand without sensitivity analysis; they determine which demonstrations are selected and thus affect all downstream metrics.
  • Outlier removal threshold = image size increases of 300-500% (3 Dockerfiles removed)
    Section IV-A removes three outliers with 300-500% image size increases before computing RQ1 trends; this arbitrary cutoff changes the reported lifecycle growth curves.
  • Number of demonstrations (shots) = 0, 1, 20, 30, 50
    The shot counts are experimental settings, not fitted, but the choice of 20/30 as intermediate values and 50 as max is ad hoc, and the main result is the best-performing setting rather than a robust optimum.
assumptions (4)
  • domain assumption DRMiner correctly detects Dockerfile refactorings in commit history (reported F1 = 0.94)
    Used to build the train/test dataset and to filter commits in RQ1; any misdetections propagate into all downstream measurements.
  • ad hoc to paper Functional behavior of a Dockerfile is captured solely by COPY/ADD and ENTRYPOINT/CMD
    This assumption (Section III-B) defines which Dockerfile pairs are kept as refactorings and is also used to validate LLM outputs; it excludes base images and package installations.
  • domain assumption Self-affirmed commit messages (refactor*, fix*, improve*) plus mention of Dockerfile identify refactoring commits
    The dataset is built from BigQuery commits whose messages contain these patterns, following prior work; this can miss or include non-refactoring changes.
  • domain assumption Manual assessments of understandability and maintainability by three authors and six developers are reliable
    These labels are used both to score demonstrations and to evaluate results; Cohen's kappa of 0.84 is reported, but the evaluators are not independent of the research team.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Refactoring for Dockerfile Quality: A Dive into Developer Practices and Automation Potential." pith.science (2026). https://pith.science/paper/7ISXMO6P

@misc{pith2026250114131,
  author       = {Pith},
  title        = {Pith review of: Refactoring for Dockerfile Quality: A Dive into Developer Practices and Automation Potential},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7ISXMO6P}},
  note         = {Machine review of arXiv:2501.14131}
}
read the original 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.

Figures

Figures reproduced from arXiv: 2501.14131 by the authors.

Figure 1
Figure 1. Approach overview and addressed RQs (RQ1: yellow arrows, RQ2: green arrows, RQ3: blue arrows, and RQ4: red arrows) automated repairs or Dockerfile smells. In contrast, other tech￾niques, such as Shipwright [27], Hadolint [41], and Binnacle [23], focus on detecting error patterns or smells and require manual intervention for their operation. To answer RQ3, we use the results from the best￾performing ICL approach iden… view at source ↗
Figure 2
Figure 2. Mean Image Size & Build Duration Increase Over Project Lifecycle 0 1 2 3 4 5 6 7 8 9 10 Lifecycle Stages 20 40 60 80 100 Dockerfiles with first refactoring commit (%) [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 5
Figure 5. This consistency is observed in zero-shot, one [PITH_FULL_IMAGE:figures/full_fig_p008_5.png] view at source ↗
Figures from the paper (2 more)
Figure 6
Figure 6. Figure 6: Docker image sizes and build durations across three categories: the original Dockerfiles (pre-refactoring), those refactored by developers, and those refactored using the 50-shot LLM approach. refactoring), using a node:9.11 base image, resulted in an image size of 111…
Figure 7
Figure 7. Figure 7: Illustrative Example of Dockerfile Refactoring: Manual vs. Automated (Commit 729ee76 from cars10/elasticvue; comments have been removed) present in our dataset (125 Dockerfiles and 74 projects). Automated refactoring achieves a 10x reduction in Dock￾erfile image size a…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

53 extracted references · 43 canonical work pages

  1. [1]

    Bullington-McGuire, A

    R. Bullington-McGuire, A. K. Dennis, and M. Schwartz, Docker for Developers: Develop and run your appli- cation with Docker containers using DevOps tools for continuous delivery. Packt Publishing Ltd, 2020

    work page 2020

  2. [2]

    Miell and A

    I. Miell and A. Sayers, Docker in practice . Simon and Schuster, 2019

    work page 2019

  3. [3]

    Empirical study of the docker smells impact on the image size,

    T. Durieux, “Empirical study of the docker smells impact on the image size,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, 2024, pp. 1–12

    work page 2024

  4. [4]

    Character- izing the occurrence of dockerfile smells in open-source software: An empirical study,

    Y . Wu, Y . Zhang, T. Wang, and H. Wang, “Character- izing the occurrence of dockerfile smells in open-source software: An empirical study,” IEEE Access, 2020

    work page 2020

  5. [5]

    Docker- cleaner: Automatic repair of security smells in docker- files,

    Q.-C. Bui, M. Laukötter, and R. Scandariato, “Docker- cleaner: Automatic repair of security smells in docker- files,” in 2023 IEEE International Conference on Soft- ware Maintenance and Evolution (ICSME). IEEE, 2023, pp. 160–170

    work page 2023

  6. [6]

    Parfum: Detection and automatic repair of dockerfile smells,

    T. Durieux, “Parfum: Detection and automatic repair of dockerfile smells,” arXiv preprint arXiv:2302.01707 , 2023

    arXiv 2023

  7. [7]

    Not all dockerfile smells are the same: An empirical evaluation of hadolint writing practices by experts,

    G. Rosa, S. Scalabrino, G. Robles, and R. Oliveto, “Not all dockerfile smells are the same: An empirical evaluation of hadolint writing practices by experts,” in 2024 IEEE/ACM 21st International Conference on Min- ing Software Repositories (MSR). IEEE, 2024, pp. 231– 241

    work page 2024

  8. [8]

    Refactorings and technical debt for docker projects,

    E. Ksontini, M. Kessentini, T. d. N. Ferreira, and F. Hassan, “Refactorings and technical debt for docker projects,” in 2021 36th IEEE/ACM International Confer- ence on Automated Software Engineering (ASE) . IEEE, 2021

    work page 2021

Show all 53 references
  1. [9]

    An empirical study of container image configurations and their impact on start times,

    M. Straesser, A. Bauer, R. Leppich, N. Herbst, K. Chard, I. Foster, and S. Kounev, “An empirical study of container image configurations and their impact on start times,” in 2023 IEEE/ACM 23rd International Symposium on Cluster, Cloud and Internet Computing (CCGrid). IEEE, 202...

    2023

  2. [10]

    An empirical study on self-admitted technical debt in dockerfiles,

    H. Azuma, S. Matsumoto, Y . Kamei, and S. Kusumoto, “An empirical study on self-admitted technical debt in dockerfiles,” Empirical Software Engineering , vol. 27, no. 2, p. 49, 2022

    2022

  3. [11]

    Understanding and predicting docker build duration: An empirical study of containerized workflow of oss projects,

    Y . Wu, Y . Zhang, K. Xu, T. Wang, and H. Wang, “Understanding and predicting docker build duration: An empirical study of containerized workflow of oss projects,” in Proceedings of the 37th IEEE/ACM Interna- tional Conference on Automated Software Engineering , 2022, pp. 1–13

    2022

  4. [12]

    Dockerfile changes in practice: A large-scale empirical study of 4,110 projects on github,

    Y . Wu, Y . Zhang, T. Wang, and H. Wang, “Dockerfile changes in practice: A large-scale empirical study of 4,110 projects on github,” in 2020 27th Asia-Pacific Software Engineering Conference (APSEC) , 2020, pp. 247–256

    2020

  5. [13]

    One thousand and one stories: a large- scale survey of software refactoring,

    Y . Golubev, Z. Kurbatova, E. A. AlOmar, T. Bryksin, and M. W. Mkaouer, “One thousand and one stories: a large- scale survey of software refactoring,” in Proceedings of the 29th ACM Joint Meeting on European Software Engi- neering Conference and Symposium on the Foundations of...

    2021

  6. [14]

    Automatically generating dockerfiles via deep learning: Challenges and promises,

    G. Rosa, A. Mastropaolo, S. Scalabrino, G. Bavota, and R. Oliveto, “Automatically generating dockerfiles via deep learning: Challenges and promises,” in 2023 IEEE/ACM International Conference on Software and System Processes (ICSSP) . IEEE Computer Society, 2023, pp. 1–12

    2023

  7. [15]

    Gpt-4 technical report,

    OpenAI, “Gpt-4 technical report,” https://arxiv.org/pdf/ 2303.08774.pdf, 2023, [Online; accessed 2024-11-08]

    2023 arXiv

  8. [16]

    Large language models for software engineering: A systematic literature review,

    X. Hou, Y . Zhao, Y . Liu, Z. Yang, K. Wang, L. Li, X. Luo, D. Lo, J. Grundy, and H. Wang, “Large language models for software engineering: A systematic literature review,”ACM Transactions on Software Engineering and Methodology, 2023

    2023

  9. [17]

    Retrieval-based prompt selection for code-related few-shot learning,

    N. Nashid, M. Sintaha, and A. Mesbah, “Retrieval-based prompt selection for code-related few-shot learning,” in 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) . IEEE, 2023, pp. 2450– 2462

    2023

  10. [18]

    Learning to re- trieve prompts for in-context learning,

    O. Rubin, J. Herzig, and J. Berant, “Learning to re- trieve prompts for in-context learning,” arXiv preprint arXiv:2112.08633, 2021

    2021 arXiv

  11. [19]

    How to create dockerfiles with genai,

    D. Labs, “How to create dockerfiles with genai,” https://www.docker.com/blog/ how-to-create-dockerfiles-with-genai/, 2024, [Online; posted Jul. 29, 2024; accessed 2024-11-08]

    2024

  12. [20]

    Replication package msr 2025,

    E. Ksontini, M. Mastouri, R. Khalsi, and W. Kessen- tini, “Replication package msr 2025,” https://sites.google. com/view/msrdra25/home

    2025

  13. [21]

    (2024) Dockerfile best practices

    Docker. (2024) Dockerfile best practices. Accessed: 2023-06-04. [Online]. Available: https://docs.docker. com/develop/develop-images/dockerfile_best-practices/

    2024

  14. [22]

    Does your configuration code smell?

    T. Sharma, M. Fragkoulis, and D. Spinellis, “Does your configuration code smell?” in Proceedings of the IEEE/ACM 13th Working Conference on Mining Software Repositories (MSR ’16) . IEEE, 2016, pp. 189–200

    2016

  15. [23]

    Learning from, understanding, and supporting devops artifacts for docker,

    J. Henkel, C. Bird, S. K. Lahiri, and T. Reps, “Learning from, understanding, and supporting devops artifacts for docker,” in Proceedings of the 42nd International Con- ference on Software Engineering (ICSE ’20) , 2020

    2020

  16. [24]

    Dockerfile tf smell detection based on dynamic and static analysis methods,

    iwei Xu, Y . Wu, Z. Lu, and T. Wang, “Dockerfile tf smell detection based on dynamic and static analysis methods,” in Proceedings of the 43rd IEEE Annual Computer Software and Applications Conference (COMPSAC ’19) , 2019

    2019

  17. [25]

    Exploring the relationship between dockerfile quality and project characteristics,

    Y . Wu, “Exploring the relationship between dockerfile quality and project characteristics,” in Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Companion Proceedings , 2020, pp. 128– 130

    2020

  18. [26]

    An empirical analysis of the docker container ecosystem on github,

    J. Cito, G. Schermann, J. E. Wittern, P. Leitner, S. Zum- beri, and H. C. Gall, “An empirical analysis of the docker container ecosystem on github,” in Proceedings of the IEEE/ACM 14th International Conference on Mining Software Repositories (MSR ’17) , 2017, pp. 323–333

    2017

  19. [27]

    Shipwright: A human-in-the-loop system for dockerfile repair,

    J. Henkel, D. Silva, L. Teixeira, M. d’Amorim, and T. Reps, “Shipwright: A human-in-the-loop system for dockerfile repair,” in 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE) . IEEE, 2021, pp. 1148–1160

    2021

  20. [28]

    Dr- miner: A tool for identifying and analyzing refactorings in dockerfile,

    E. Ksontini, A. Abid, R. Khalsi, and M. Kessentini, “Dr- miner: A tool for identifying and analyzing refactorings in dockerfile,” in Proceedings of the 21st International Conference on Mining Software Repositories , 2024, pp. 584–594

    2024

  21. [29]

    Assessing and improving the quality of docker artifacts,

    G. Rosa, S. Scalabrino, and R. Oliveto, “Assessing and improving the quality of docker artifacts,” in 2022 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2022, pp. 592–596

    2022

  22. [30]

    Refactoring operations grounded in manual code changes,

    A. M. Eilertsen, “Refactoring operations grounded in manual code changes,” in Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Companion Proceedings, 2020, pp. 182–185

    2020

  23. [31]

    Search- based software engineering: Trends, techniques and ap- plications,

    M. Harman, S. A. Mansouri, and Y . Zhang, “Search- based software engineering: Trends, techniques and ap- plications,” ACM Computing Surveys , vol. 45, no. 1, p. 11, 2012

    2012

  24. [32]

    Search-based refactoring: Towards semantics preserva- tion,

    A. Ouni, M. Kessentini, H. Sahraoui, and M. S. Hamdi, “Search-based refactoring: Towards semantics preserva- tion,” in 2012 28th IEEE International Conference on Software Maintenance (ICSM) . IEEE, 2012, pp. 347– 356

    2012

  25. [33]

    An interactive and dynamic search-based approach to software refactoring recom- mendations,

    V . Alizadeh, M. Kessentini, W. Mkaouer, M. Ocinneide, A. Ouni, and Y . Cai, “An interactive and dynamic search-based approach to software refactoring recom- mendations,” IEEE Transactions on Software Engineer- ing, 2018

    2018

  26. [34]

    Automated recommendation of software refactorings based on feature requests,

    A. Nyamawe, H. Liu, N. Niu, Q. Umer, and Z. Niu, “Automated recommendation of software refactorings based on feature requests,” 09 2019, pp. 187–198

    2019

  27. [35]

    Comparing commit messages and source code metrics for the prediction refactoring activities,

    P. Sagar, E. Alomar, M. W. Mkaouer, A. Ouni, and C. Newman, “Comparing commit messages and source code metrics for the prediction refactoring activities,” Algorithms, vol. 14, p. 289, 09 2021

    2021

  28. [36]

    What makes good in-context demonstrations for code intelligence tasks with llms?

    S. Gao, X.-C. Wen, C. Gao, W. Wang, H. Zhang, and M. R. Lyu, “What makes good in-context demonstrations for code intelligence tasks with llms?” ASE, 2023

    2023

  29. [37]

    A critical review of large language model on software engineering: An example from chatgpt and auto- mated program repair,

    Q. Zhang, T. Zhang, J. Zhai, C. Fang, B. Yu, W. Sun, and Z. Chen, “A critical review of large language model on software engineering: An example from chatgpt and auto- mated program repair,” arXiv preprint arXiv:2310.08879, 2023

    arXiv

  30. [38]

    Self-refine: Iterative refinement with self- feedback,

    A. Madaan, N. Tandon, P. Gupta, S. Hallinan, L. Gao et al. , “Self-refine: Iterative refinement with self- feedback,” https://arxiv.org/abs/XXXX.XXXXX%7D% 7D, 2023, arXiv preprint

    2023

  31. [39]

    Refactoring programs using large lan- guage models with few-shot examples,

    A. Shirafuji, Y . Oda, J. Suzuki, M. Morishita, and Y . Watanobe, “Refactoring programs using large lan- guage models with few-shot examples,” in 2023 30th Asia-Pacific Software Engineering Conference (APSEC). IEEE, 2023, pp. 151–160

    2023

  32. [40]

    A survey of using large language models for generating infrastructure as code,

    K. G. Srivatsa, S. Mukhopadhyay, G. Katrapati, and M. Shrivastava, “A survey of using large language models for generating infrastructure as code,” arXiv preprint arXiv:2404.00227, 2024

    2024 arXiv

  33. [41]

    hadolint/hadolint: Dockerfile linter, validate inline bash, written in haskell,

    “hadolint/hadolint: Dockerfile linter, validate inline bash, written in haskell,” https://github.com/hadolint/hadolint, (Accessed on 11/17/2023)

    2023

  34. [42]

    Bigquery github database,

    Google, “Bigquery github database,” https://codelabs. developers.google.com/codelabs/bigquery-github

  35. [43]

    Can refac- toring be self-affirmed? an exploratory study on how developers document their refactoring activities in com- mit messages,

    E. AlOmar, M. W. Mkaouer, and A. Ouni, “Can refac- toring be self-affirmed? an exploratory study on how developers document their refactoring activities in com- mit messages,” in 2019 IEEE/ACM 3rd International Workshop on Refactoring (IWoR). IEEE, 2019, pp. 51– 58

    2019

  36. [44]

    Rethinking the role of demonstrations: What makes in-context learning work?

    S. Min, X. Lyu, A. Holtzman, M. Artetxe, M. Lewis, H. Hajishirzi, and L. Zettlemoyer, “Rethinking the role of demonstrations: What makes in-context learning work?” arXiv preprint arXiv:2202.12837 , 2022

    2022 arXiv

  37. [45]

    Okapi at trec-3,

    S. E. Robertson, S. Walker, S. Jones, M. M. Hancock- Beaulieu, M. Gatford et al. , “Okapi at trec-3,” Nist Special Publication Sp , vol. 109, p. 109, 1995

    1995

  38. [46]

    Language models are few-shot learn- ers,

    T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Ka- plan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell et al. , “Language models are few-shot learn- ers,” Advances in neural information processing systems , vol. 33, pp. 1877–1901, 2020

    1901

  39. [47]

    Ai-assisted coding: Experiments with gpt-4,

    R. A. Poldrack, T. Lu, and G. Beguš, “Ai-assisted coding: Experiments with gpt-4,” arXiv preprint arXiv:2304.13187, 2023

    2023 arXiv

  40. [48]

    Kubeplaybook: A repository of ansible playbooks for kubernetes auto-remediation with llms,

    Z. Namrud, K. Sarda, M. Litoiu, L. Shwartz, and I. Watts, “Kubeplaybook: A repository of ansible playbooks for kubernetes auto-remediation with llms,” in Companion of the 15th ACM/SPEC International Conference on Performance Engineering, 2024, pp. 57–61

    2024

  41. [49]

    The proof and measurement of association between two things

    C. Spearman, “The proof and measurement of association between two things.” 1961

    1961

  42. [50]

    Build context error example, project: zhoumingithub/my-zipkin, commit:4e74b2, dockerfile: docker/dockerfile,

    “Build context error example, project: zhoumingithub/my-zipkin, commit:4e74b2, dockerfile: docker/dockerfile,” https://github.com/zhoumingithub/ my-zipkin/commit/4e74b2

  43. [51]

    Dependency errors example, project: mattolson/docker- base, commit:ee4d42, dockerfile: Dockerfile,

    “Dependency errors example, project: mattolson/docker- base, commit:ee4d42, dockerfile: Dockerfile,” https:// github.com/mattolson/docker-base/commit/ee4d42

  44. [52]

    Syntax errors example, project: ipcjk/ixgen, com- mit:9e1f90, dockerfile: docker/dockerfile,

    “Syntax errors example, project: ipcjk/ixgen, com- mit:9e1f90, dockerfile: docker/dockerfile,” https://github. com/ipcjk/ixgen/commit/9e1f90

  45. [53]

    Missing base images example, project: ekumenlabs/terminus, commit:e2305d, dockerfile: docker/gazebo-terminus-intel-dev/dockerfile,

    “Missing base images example, project: ekumenlabs/terminus, commit:e2305d, dockerfile: docker/gazebo-terminus-intel-dev/dockerfile,” https://github.com/ekumenlabs/terminus/commit/e2305d

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.