arXiv CSopen access

Beyond the Tip of the Iceberg: Understanding SATD in Dockerfiles through the Lens of Co-evolution

Noname manuscript No. (will be inserted by the editor)

Beyond the Tip of the Iceberg: Understanding SATD in Dockerfiles through the Lens of Co-evolution

arXiv:2605.21238v1 [cs.SE] 20 May 2026

Wei Minn · Yan Naing Tun · Biniam Demissie · Rui’ang Hu · Jiakun Liu ⋆ · Mariano Ceccato Lwin Khin Shar · David Lo

·

Received: date / Accepted: date

Abstract Dockerfiles enable the creation of portable container-based execution environments for the application code, and have become an important part of the modern software development process. As Dockerfiles are a form of Infrastructure-as-Code (IaC), they can include temporary workarounds and other suboptimal implementations, leading to the accrual of technical debt that affects their reliability, security, and maintainability in the future. Prior work characterized technical debt in Dockerfiles by analyzing self-admitted technical debt (SATD) in Dockerfile comments and the surrounding file chunks. This single-file view is incomplete since source code evolution involves changes across different types of software artifacts such as production, test, build, and other configuration files. Thus, we address this gap by studying SATD events in Dockerfiles alongside the related source code. ⋆

Corresponding author.

Wei Minn, Yan Naing Tun, Lwin Khin Shar, and David Lo Singapore Management University E-mail: [email protected], [email protected], [email protected], [email protected] Biniam Fesseha Demissie Technology Innovation Institute, UAE E-mail: [email protected] Rui’ang Hu, Jiakun Liu Harbin Institute of Technology, China E-mail: [email protected], [email protected] Mariano Ceccato University of Verona, Italy E-mail: [email protected]

2

Wei Minn

et al.

We construct a dataset of 1,316 SATD instances from 393 Docker Hub– GitHub linked repositories with full Dockerfile histories, manually validate and categorize the SATD instances using the taxonomy of Azuma et al., and annotate whether each admission and repayment event is coupled to non-Dockerfile co-changes. Our findings complement the existing Dockerfile SATD literature’s singular dimension of SATD subtypes with source code-side co-evolutionary dimension for extra contextual insights. More specifically, we find that approximately 27% of admission events and 40% of repayment events are coupled to non-Dockerfile artifacts, and coupling sources are subtype-specific. We also observed that coupled SATD in general are repaid significantly faster overall (p = 0.0201), while coupled SATD regarding missing functionalities persists longer than its isolated counterparts; Lastly, we conducted open and axial coding of coupled SATD events, and we observe that external dependency issues, more particularly regarding unreleased upstream packages and bug fixes, are the most common cause of admission triggers in the source code; we also observe that architectural refactoring is the most common prerequisite for the repayment of SATD in Dockerfiles. These findings indicate that both practitioners (e.g. developers and project managers) and SATD researchers should integrate the source code-side co-evolution, rather than the single-file view, as the primary unit of analysis. For example, automated SATD detection and repair tools should integrate cross-artifact signals, and project-level remediation triage and task delegation should follow the coupling source rather than the file location. Keywords Self-Admitted Technical Debt (SATD) · Dockerfiles · Coevolution · Software Maintenance 1 Introduction Dockerfiles have become an integral part of modern software development as they allow software systems to be built, packaged, and executed in portable containerized environments. They enable convenient dependency installation and environment configuration, consistent builds, and deployment portability across production settings [4]. As such, Dockerfiles serve as the crucial interface between application code and its development environment, making them a widely-adopted technology in the Software Development Life Cycle (SDLC) [8]. Various works have studied Dockerfiles from perspectives akin to the study of conventional source code analyses. For example, existing works have mined recurring specification patterns and rules from large Dockerfile corpora to characterize common practices and infer usage regularities [27, 77]. Other studies have focused on Dockerfile refactoring, proposing techniques to identify and restructure suboptimal constructs to improve maintainability [32]. A substantial body of work has examined Dockerfile smells, including their characterization, detection, repair, and empirical consequences [61, 14, 20, 60, 21, 71]. More recently, research has explored automated Dockerfile repair, aiming to synthesize fixes for faulty or undesirable specifications [63].

Title Suppressed Due to Excessive Length

3

Commit 3220272 containing SATD Admission getglide.sh 1 +

dockerfile

/bin/sh

2 + 3

1 +# RUN curl https://glide.sh/get | sh 2 +# Workaround for the requirement to pin the version of glide to v0.13.1 3 +ADD getglide.sh . Admitted SATD Comment in 4 +RUN sh ./getglide.sh Dockerfile

4 + 5 +# To run this script execute: 6 +#

`curl https:

glide.sh/get | sh`

7 + 8 +PROJECT_NAME="glide" 9 + 10 +# LGOBIN represents the local bin location. This can be either the GOBIN, if set, 11 +# or the GOPATH/bin. 12 + 13 +LGOBIN=""

Commit cbe1557 Containing SATD Repayment Repaid SATD Comment in Dockerfile dockerfile 1 -# RUN curl https:

glide.sh/get | sh

2 -# Workaround for the requirement to pin the version of glide to v0.13.

Co-evolved Files in the same commit The project migrated from Glide to Go

Go module added go.mod

Makefile 1 @@ -0,0 +1,9 @@

1 @@ -3 +3 @@

2

2 -GO=CGO_ENABLED=0 go 3 +GO=CGO_ENABLED=0 GO111MODULE=on go 4 @@ -17 +17 @@ build: $(MICROSERVICES) 5 -

go build ./

6 +

$(GO) build ./ go test ./

9 +

$(GO) test ./

4

require (

5 +

github.com/edgexfoundry/device sdk go v0.0.0-

20190220033957-9ab31b9a2564 6 +

7 @@ -23 +23 @@ test: 8 -

module github.com/edgexfoundry/device modbus go

3 +

github.com/edgexfoundry/go mod core contracts

v0.0.0-20190206111100-148998445693

cover

7 +

github.com/goburrow/modbus v0.1.0

cover

8 +

github.com/goburrow/serial v0.1.0

10 @@ -29,4 +28,0 @@ prepare:

9 +

github.com/tbrandon/mbserver v0.0.0-

11 -

glide install

20170611213546-993e1772cc62 10 +)

12 13

update:

14 -

glide update

Glide Module Removed glide.yaml 1 @@ -1,15 +0,0 @@ 2

package: github.com/edgexfoundry/device modbus go

3

import:

getglide.sh 1 @@ -1,187 +0,0 @@ 2 -

/bin/sh

4

package: github.com/edgexfoundry/device sdk go

3 -

5 -

version: delhi

4 -# The install script is licensed under the

6 -

subpackages:

7 -

- pkg/models

8

package: github.com/edgexfoundry/edgex go

MIT license Glide itself is under. 5 -# See https:

github.com/Masterminds/glide/blob/mast

9 -

version: delhi

10 -

subpackages:

11 -

- pkg/models

6 -

12 -

- pkg/clients/logging

13

package: github.com/goburrow/modbus

7 -# To run this script execute:

14 -

version: =0.1.0

15

package: github.com/tbrandon/mbserver

16 -

version: 993e1772cc62aabcd5a5b9f7b58b03dd091a86c0

er/LICENSE for more details.

8 -#

`curl https:

glide.sh/get | sh`

9 10 -PROJECT_NAME="glide"

Figure 1 In commit 3220272 of edgexfoundry/device-modbus-go project, an SATD comment (about using Glide package manager) was added to the Dockerfile, and, in the same commit, getglide.sh script for configuring Glide is added. Later in commit cbe1557, the Dockerfile shows the removal of the SATD comment; the four co-changed files (Makefile, go.mod, getglide.sh, and glide.yaml) in the same commit are semantically linked to the repayment.

4

Wei Minn

et al.

Among these lines of work, self-admitted technical debt (SATD) in Dockerfiles has received only limited attention. Within our knowledge, the only dedicated study is the empirical investigation by Azuma et al., which identifies and categorizes SATD comments appearing in Dockerfiles [9]. While it offers valuable insights into the taxonomy of Dockerfile SATD, it analyzes Dockerfile SATD localized only within a single file. Prior work on IaC-source co-evolution has long established that IaC artifacts and application code are closely interconnected and evolve together [29, 72, 47]. Despite this understanding of IaC-code coupling, no existing work has investigated whether SATD is admitted, maintained, or repaid in connection with changes outside the SATDoccurring artifact. For instance, the latest work on automated SATD repayment [46] only uses the code chunks containing SATD comments to fine-tune their model. Their model is only able to resolve 2.30% of the cases on first attempt and 8.10% of the cases in 10 attempts, thus demonstrating that there is still a long way to go in the topic of automated SATD repayment. Therefore, we hypothesize that SATD comments, more specifically in Dockerfiles, are not merely local workarounds. Rather, they are the resultant of limitations, constraints, and workarounds in related source-code side artifacts such as application logic code, test code, dependency manifests, and other configuration files. For example, there may be missing functionality inside logic code, compatibility issues regarding dependency version changes, and constraints in the CI/CD pipeline and infrastructure. Thus, the repayment of such kind of Dockerfile SATD is contingent upon source-code side improvement in terms of implementing new application logic, upgrading dependencies, and updating configuration values. Figure 1 shows an SATD comment admitted in a Dockerfile at commit 3220272 in the edgexfo-undry/device-modbus-go project on GitHub1 . The SATD comment and the surrounding code chunk implies a version-related workaround caused by a Glide-related script somewhere in the project. The commit-level inspection reveals the addition of the getglide.sh script which was mentioned by the SATD comment in the Dockerfile. Thus, the broader project-level build system-related workaround is reflected in this Dockerfile SATD event. Figure 1 also shows the removal (repayment) of the SATD comment in the same Dockerfile in a follow-up commit cbe15572 . In this commit, Gliderelated artifacts (getglide.sh, and glide.yaml) are totally removed, while Go-related configuration file (go.mod) is added. Moreover, in the Makefile, Glide-related statements make way for the Go-related ones. Thus, the repayment of the Dockerfile SATD comment happens only when the project migrated from Glide to Go package management system. Motivated by such correlated changes between Dockerfile SATD and broader project artifacts, we constructed a large-scale dataset of Docker Hub-GitHub linked projects that contain Dockerfiles, and manually annotated SATD life1 2

https://github.com/edgexfoundry/device-modbus-go/commit/3220272 https://github.com/edgexfoundry/device-modbus-go/commit/cbe1557

Title Suppressed Due to Excessive Length

5

cycle events and coupling relationships. Our study is guided by the following research questions: – RQ1: How often are different SATD subtypes coupled to nonDockerfile artifacts during admission and repayment? What coupling sources dominate per subtype? This RQ adds an additional dimension to the existing empirical landscape as existing literature characterizes only the content of Dockerfile SATD comments, and not whether those SATD events are primarily isolated to the Dockerfile or linked to changes elsewhere in the repository. 27% of admission events and 40% of repayment events are coupled with non-Dockerfile artifacts, which suggests that the Dockerfile-only view is limited when studying automated SATD annotation and repayment. Coupling sources are subtype-specific: code-centric subtypes co-evolve primarily with application logic files, test-related subtypes with CI/CD artifacts, and design or size-reduction subtypes with infrastructure files. – RQ2: Do coupled SATD instances differ from isolated ones in time-to-repayment? In order to study SATD repayment dynamics, we track SATD instances over time, identifying admission, persistence, and repayment events, and compare the survival behavior of coupled versus isolated debt using Kaplan-Meier analysis and log-rank tests [31, 54]. Counterintuitively, coupled SATD instances are repaid significantly faster overall (p = 0.0201), with Defect/Workaround showing the strongest effect (p = 0.0084), suggesting that developers assign higher priority to crossartifact debt. By contrast, Code/MissingFunctionality coupled instances tend to persist longer, indicating that missing-feature debt requiring upstream effort is harder to resolve even once the coupling is recognized. – RQ3: What cross-artifact changes trigger Dockerfile SATD admissions and enable their repayments? In order to understand the full lifecycle of Dockerfile SATD, we need to supplement with the analysis of co-changed artefacts at both admission and repayment time. We taxonomized coupled admission and repayment events using open and axial coding [52] to derive different types of admission triggers and repayment requisites. For admissions, we identify four themes: External Dependency Constraints, Compatibility and Environment Issues, Incomplete Implementation, and Maintenance Overhead. For repayments, we identify three requisite themes: Upstream Progression, Internal Refactoring, and Feature Completion. This paper makes the following contributions: – (New paradigm) We introduce a co-evolutionary dimension to the study of Dockerfile SATD, extending prior single-artifact views with the perspective of different types of co-evolved source files. – (Dataset) We build and curate a large-scale dataset of Docker HubGitHub linked repositories with full Dockerfile histories, SATD candidate extraction, manually labeled SATD instances along with their SATD subtypes, and manually labeled semantic coupling candidates [49].

6

Wei Minn

et al.

1. Stratified Prefix Sampling Stratified Prefix Sampling

Filter Projects with < 1 star

Filter invalid GitHub URLs

Filter Projects without Corresponding GitHub URLs

Docker Hub API

Filter GitHub Repositories w/o Dockerfiles

2. Commit Mining Enumerate Commits

Enumerate Dockerfiles

Parse Diff of Co-changed files

Parse Diff of Dockerfiles

3. Data Annotation and Emprical Study Extract Keyword-based SATD Candidates

SATD Identification and SATD subtype classification

Semantic Link Identification of Co-changed files

1. Coupling and Correlation Analysis 2. Survival Analysis 3. Cross-artifact Taxonomy Study

Figure 2 Overview of our dataset construction pipeline: first, we perform stratified prefix sampling to scrap all the Docker Hub projects with at least 1 start, and extract URLs to valid corresponding GitHub repositories. Then, for each Dockerfile in the GitHub repositories, we look into all the commits that touched the Dockerfile, and extracted diff snippets of the Dockerfile and co-changed files. Then, we perform keyword-based SATD candidate comment extraction from the Dockerfiles. These candidates are then verified by human annotators as part of SATD identification and subtype classification step. The annotators also label semantic link between the SATD in Dockerfile and the co-changed file. Finally, we use the labelled SATD and semantic link data for our empirical analyses.

– (Coupling and Survival Analysis) We analyze coupling sources, and repayment dynamics of Dockerfile SATD and show that coupled and isolated debt instances differ systematically in their time-to-repayment behavior depending on their SATD subtypes. – (Taxonomy) We present a qualitative taxonomy covering cross-artifact admission triggers and repayment requisites, explaining why Dockerfile SATD is introduced and what enables its removal.

Title Suppressed Due to Excessive Length

7

Table 1 Dataset construction statistics. Stage 1 2 3 4 5

Description

Count

Docker Hub projects after star ≥ 1 filter Docker Hub projects with extractable GitHub URL Corresponding GitHub repositories Corresponding GitHub repositories with Dockerfile history Corresponding GitHub repositories with SATD candidate comments

151, 295 4, 300 3, 021 2, 962 393

2 Dataset Construction Understanding Dockerfile SATD through a co-evolutionary lens requires a dataset that captures not only the SATD comments themselves, but also the surrounding co-evolved source files. We separate (i) SATD identification and subtype classification for Dockerfile comments from (ii) event-level coupling assessment for SATD admissions and repayments.

2.1 Stratified Prefix Sampling In order to explore a representative set of Docker-related projects, we query Docker Hub repositories using string prefixes where we query the Docker Hub API [5] to retrieve all Docker Hub projects that start with all possible combinations of 3-character prefixes. Table 1 summarizes the number of retained project throughout the dataset construction pipeline. Then, we obtain 151,295 Docker Hub projects with at least one star. Thereby, we exclude 14 million 0-star Docker Hub projects, making the scope of our project feasible. For each retained Docker Hub projects, we extract GitHub URLs from the project descriptions and metadata using a documented set of regular expressions. There are 4,300 Docker Hub projects that has metadata that contain links to their corresponding GitHub repositories. Extracted URLs are normalized to canonical Git Hub repository identifiers of the form <owner>/<repo>. We discover 3,021 valid corresponding GitHub repositories, and excluded the Docker Hub repositories that cannot be linked to valid public GitHub repositories from subsequent mining. 2,962 out of the 3,021 corresponding GitHub repositories contain Dockerfiles. and 393 out of the 2,962 Dockerfile-containing GitHub repositories contain SATD candidate comments.

2.2 Heuristics for Artifact-Type Classification In order to study the coupling source of the different types of SATD, we need to classify the different types of co-changed files. Following McIntosh et al. [48] and Jiang & Adams [29] that studied co-evolution between IaC and source code, we leverage known file naming patterns to classify the source file type into Logic, Test, Build/Dependency, CI/CD, and Infrastructure:

8

Wei Minn

et al.

– Test ← file path contains test or spec. – Logic ← file path ends in common source-code extensions (e.g., .java, .py, .go, .js). – Build/Dependency ← file path matches well-known build and dependency manifests such as pom.xml, package.json, requirements.txt, go.mod, build.gradle, Cargo.toml, or Makefile. – Infrastructure ← file path with extension (e.g., .tf, .tfvars for Terraform; .yaml/.yml files matching Kubernetes, Ansible, or CloudFormation naming conventions; .toml, .jsonnet, Vagrantfile) or by path fragment (e.g., docker-compose, Dockerfile). This coarse artifact-type annotation is used in later steps to characterize the dominant coupling sources for each SATD subtype in Section 3 (RQ1) and to support the qualitative coding in Section 5 (RQ3).

2.3 Data Annotation Our manual annotation process involves three labeling tasks: (1) SATD identification which labels whether a candidate Dockerfile comment is a genuine SATD, (2) SATD subtype classification which classifies the SATD instances to a subtype from the Dockerfile SATD taxonomy presented by Azuma et al. [9], and (3) SATD event coupling classification which classifies whether a SATD admission or repayment event is semantically linked to cochanged non-Dockerfile files from the same commit. Table 2 summarizes the annotation tasks, their units of analysis, label sets, and the data shown to annotators. Annotators and annotation protocol. Two annotators, with 12 and 15 respective years of programming experience, independently labeled all three tasks. The annotation for each of the three tasks happens in three phases: (1) pilot phase, (2) reliability phase, and (3) production phase. In the pilot phase, both annotators independently labeled a shared sample of 60 instances per task, and discussed disagreements to refine the codebook. In the reliability phase, both annotators independently labeled a new shared sample of 100 instances per task, and measured inter-rater agreement statistics in terms of Cohen’s κ [17]. In the production phase, the remaining instances were split evenly between the two annotators, with a final adjudication meeting to resolve conflicting cases.

2.4 SATD Identification In order to extract all SATD instances from the GitHub repositories, we enumerate all Dockerfile paths throughout the full commit history for all the repositories. Then, we filter for commits that touch a Dockerfile, and extract comment lines that were added to or removed from the Dockerfiles. We treat a comment line inside a Dockerfile as SATD candidate if it contains at least one

Title Suppressed Due to Excessive Length

9

Table 2 Annotation schema used in the study. Task

Unit of analysis

Labels

SATD identification

Candidate Dockerfile comment Validated SATD comment

SATD SATD

SATD subtype classification SATD event coupling classification

SATD admission or repayment event

Data shown to annotators /

Not-

SATD taxonomy subtypes presented by Azuma et al. [9] Coupled / Isolated

Comment text, Dockerfile path, surrounding Dockerfile context, commit message Comment text, Dockerfile path, surrounding Dockerfile context, commit message SATD comment, Dockerfile context, event type, commit message, co-changed file paths, cochanged file diffs

of the phrases from the SATD keyword list such as TODO, FIXME, HACK, WORKAROUND, UGLY, or PROBLEMATIC. This keyword-based SATD candidate filtering is in line with the prior work in SATD empirical study [26], and is specifically validated for Dockerfile domain by Azuma et al. [9] which sampled 330 Dockerfile comments without the SATD keywords and found that only 1.83% of them were SATD. Thus, we consider the use of keyword-based filtering good enough for initial SATD candidate collection. For each discovered SATD candidate, we further extract the context of the SATD instance: (1) comment text itself, (2) Dockerfile path, (3) surrounding code block preceding and following the comment, (4) commit message, (5) cochanged files in the same commit, and (6) commit hash and timestamp. Using the information from the extracted SATD context, the annotators independently assign each SATD candidate to one of two labels: – SATD: the candidate explicitly admits a suboptimal, temporary, workaround, or to-be-revisited technical condition as presented by prior works in SATD identification [26, 9], and – Non-SATD: the candidate does not self-admit technical debt. Following the three-phase protocol described in Section 2.3, the two annotators achieved a Cohen’s κ of 0.66 on the shared subset in the reliability phase, indicating substantial agreement [33]. As the total number of candidate comments is manageable (1,316 candidates), we annotate all 1,316 candidates rather than sampling a subset of them. Thus, we avoid potential sampling errors and biases at this SATD identification stage and present a representative comment-level SATD dataset. 2.5 SATD Subtype Classification In order to enable analysis of Dockerfile SATD by their subtypes, we classified the labelled SATD instances into Dockerfile SATD subtypes based on the taxonomy presented by Azuma et al. [9]. Table 3 shows the 10 Dockerfile SATD subtypes from the taxonomy study. Following the three-phase protocol

10

Wei Minn

et al.

Table 3 SATD Subtypes presented by Azuma et al. [9] SATD Subtype

Description

Code/Workaround Code/MissingFunctionality Code/BaseImage Test/IntegrityCheck Test/ImprovementForTest Defect/Workaround Defect/LatentBug Design/SizeReduction Process/Deployment Process/Review Unclassifiable

SATDs on suboptimal implementation SATDs on the lack of functionality inside containers SATDs on the base image SATDs on binary integrity verification SATDs on improvement for testing SATDs on working around bugs in external systems SATDs on latent bugs SATDs on size optimization of Docker image SATDs on deployment processes SATDs on review of the Dockerfile Clear SATD, but not enough information

described in Section 2.3, two annotators classify each SATD instance to exactly one subtype, and discuss disagreements to refine the codebook that comprises the SATD subtype definitions, and their corresponding examples. In the reliability phase, the two annotators achieved a Cohen’s κ of 0.63 on the shared subset, indicating substantial agreement [33]. Figure 3 summarizes the resulting distribution of validated SATD instances across subtypes, providing an overview of the SATD landscape in our dataset as the context for the coupling and lifecycle analyses in Section 3 and 4. 2.6 SATD Coupling Annotation To study SATD in Dockerfile from the lens of co-evolution, we need to analyze changes in other co-changed source files in the same commit. However, we need to determine if the co-changed files are semantically linked (coupled) to the SATD comment inside the Dockerfile or just a coincidental change that is related to a different task in the same commit. Thus, we need to label which of the SATD events from the identified SATD events in Section 2.4 are coupled or not. More precisely, we define coupling as follows: A SATD event is labeled Coupled if at least one co-changed nonDockerfile artifact plausibly contributed to the admission of the SATD or to the conditions enabling its repayment. Otherwise, the event is labeled Isolated. For each sampled SATD event, the two annotators refer to the information in the SATD comment text, Dockerfile code chunk context around the SATD, event type (Admission or Repayment), commit message, the list of diff snippets of co-changed non-Dockerfile files in the same commit. Following the threephase protocol described in Section 2.3, the two annotators independently labeled the shared pilot sample to construct a codebook for semantic linking of co-changed file to the Dockerfile SATD comment. Then, in the reliability phase, the two annotators achieved a Cohen’s κ of 0.62 on the shared reliability subset, indicating substantial agreement [33]. Afterwards, in production phase,

Title Suppressed Due to Excessive Length

11

300 250

Count

200 150 100

Defect/LatentBug

Process/Deployment

Test/ImprovementForTest

SATD Category

Unclassifiable

Test/IntegrityCheck

Process/Review

Code/BaseImage

Code/Version

Design/SizeReduction

Code/MissingFunctionality

Defect/Workaround

0

Code/Workaround

50

Figure 3 Distribution of manually validated Dockerfile SATD instances across subtypes.

the two annotators split the remaining SATD events, and labeled the coupling statuses of respective part of the dataset. Lastly, the two annotators held a discussion to manually resolve conflicting labels from production phase.

3 Coupling and Correlation Analysis (RQ1) 3.1 Motivation As the existing Dockerfile SATD study [9] characterizes only the content of Dockerfile SATD comments and surrounding code context in the same Dockerfile, it overlooks the possibility of Dockerfile SATD being frequently coupled with other artifects in the project such as application code, build system, and other configurations files. This would severely limit our understanding of Dockerfile SATD in terms of root causes, and remediation strategies that could only be found inside the source code. Thus, we first get an overview of the SATD landscape in Dockerfiles in terms of the distribution or prevalence of Dockerfile SATD subtypes. Then, we examine whether their admission and repayment events occur in isolation or together with semantically linked non-

12

Wei Minn

et al.

Dockerfile changes. Finally, we characterize the dominant coupling sources for each subtype.

3.2 Approach To explore the prevalence landscape of SATD, we quantified the manuallyannotated Dockerfile SATD instances and their subtypes during the dataset construction phase in Section 2.5. Figure 3 shows the distribution of SATD subtypes across all identified instances. To find out the coupling rates of Dockerfile SATD, we look at two kinds of SATD lifecycle events: admission and repayment. We use the manuallyannotated of SATD coupling data from Section 2.6, and quantified the proportion of Coupled vs. Isolated events for each SATD subtype where Coupled denotes events that has at least one semantically-linked file change in the same commit, and Isolated if otherwise. Figure 4 displays the proportion of Isolated and Coupled events per SATD subtype for both admissions and repayments, together with the corresponding number of instances. To further investigate the nature of Dockerfile SATD coupling, we analyzed the relationship between SATD subtypes and co-changed source file types using binary correlation analysis. For every co-changed file in each SATD instance, we mapped the semantically-linked files into five source categories: Build/Dependency, CI/CD, Infrastructure, Logic, and Test using the file pathbased heuristics discussed in Section 2.2. For every SATD event, we encoded binary variables for SATD subtype and file types on whether the SATD admission belongs to an SATD subtype, and whether its co-changes at least one file of the file type. Then we computed the ϕ coefficient [19] which is a special case of Pearson correlation [52] for binary variables, and assessed significance using Fisher’s exact test with Benjamini-Hochberg correction [11]. Table 4 reports SATD subtype-file type correlations ranked by absolute ϕ, and Figure 5 visualizes the ϕ coefficients for the five most prevalent SATD subtypes.

3.3 Results Dockerfile SATD is dominated by workarounds related to both code and defect themes. Figure 3 shows that Code/Workaround is the most prevalent subtype (292), followed by Defect/Workaround (252) and Code/MissingFunctionality (145). Together, these three categories account for the large majority of all identified SATD instances, far exceeding less frequent categories such as Design/SizeReduction (44), Code/Version (37), and process- or testing-related debt. This suggests that the most prevalent forms of Dockerfile SATD are not merely comments about image hygiene or build optimization. Rather, they highlight mismatches, workarounds, or limitations in the underlying software system. This insight is also consistent with the study of SATD in source-code corpora, where workaround and requirement debts have been

De f Pro ect/L ce ate ss/ nt De Bu g p Pro loym ce en ss/ t R Co evie de w Co /V de /M Unc ersio iss las n ing sif Fu iab Tes Co nctio le t/Im de/ nal pro Base ity De vem Ima sig en ge n/S tFo De izeRe rTest fec du t/W ct Co ork ion de aro Tes /Wor und t/In kar teg oun rity d Ch ec k Ov era ll Percentage (%)

Percentage (%)

Coupled

100

80 800

60 600

40 400

20 200

0 0

80

60

40

20 100

0 0

Number of Instances (N)

Isolated

400

Number of Instances (N)

De De fect sig /La n/S ten ize tB Co Red ug de uct /Ba ion Pro seIm Pro ces ag ce s/R e ss/ ev De iew pl Un oyme Co Defe class nt de ct ifi /M /W ab iss ork le ing ar o Tes Func und t t/In ion teg ali Tes Cod rity ty t/Im e/W Che pro ork ck ve aro me un nt d Co ForTe de st /Ve rsi on Ov era ll Title Suppressed Due to Excessive Length 13

Instance Count

(a) Admitted SATD: Isolation vs. Coupled 1000

(b) Repaid SATD: Isolation vs. Coupled

100 500

300

200

Figure 4 Isolation versus coupling rates by SATD subtype for (a) admissions and (b) repayments. The line plot indicates the number of instances per subtype.

14

Wei Minn

et al.

Table 4 Correlation analysis between SATD subtypes and co-changed source file types sorted by Phi which denotes the binary correlation coefficient. Q-values are BenjaminiHochberg adjusted Fisher exact test p-values. SATD Subtype Process/Review Process/Review Design/SizeReduction Code/Version Code/Workaround Process/Deployment Defect/Workaround Defect/Workaround Code/MissingFunctionality Code/Version Code/Workaround Code/Workaround

File Type CI/CD Test CI/CD CI/CD CI/CD Test CI/CD Infrastructure CI/CD Logic Test Build/Dependency

N 10 6 13 10 26 3 23 6 25 5 17 23

ϕ 0.157 0.123 0.115 0.089 -0.084 0.074 -0.071 0.064 0.058 0.042 -0.042 0.042

q 0.009 0.073 0.064 0.233 0.203 0.547 0.345 0.664 0.665 1.000 1.000 1.000

found to be the most prevalent as well [10, 43, 55, 38]. One major departure from existing SATD literature is the high occurrence of Defect/Workaround in our dataset. Defect/Workaround is a type of Dockerfile-specific SATD that highlights a workaround due to bugs in external systems [9]. This reflects the nature of Dockerfiles that have to compensate for the behavior of external base images and upstream dependencies that are outside the developer’s control. A substantial share of admitted SATD comments in Dockerfiles are coupled with non-Dockerfile artifacts, and repaid SATD comments have even higher coupling rates. Figure 4(a) shows that about 27% of SATD admission events are coupled, whereas roughly 73% are isolated. In contrast, Figure 4(b) shows 40% of repayment events are coupled and about 60% are isolated. Methodologically, this result validates the co-evolutionary perspective of our study: a Dockerfile-only view may be misleading when studying SATD removal, because repayment is frequently conditioned on changes elsewhere in the repository. This finding challenges a tacit assumption in the SATD repayment literature, which has predominantly measured repayment by examining edits within the same file or module where the debt was originally admitted [46, 24, 23]. The substantially higher coupling rate at repayment time suggests that the resolution of IaC debt is intrinsically cross-artifact, consistent with broader co-evolution evidence showing that Dockerfile changes and application changes are strongly correlated [72, 29]. Furthermore, prior IaC quality studies have treated Dockerfile smells and debt as self-contained issues amenable to local refactoring [21, 61]; our results imply that automated repair tools targeting Dockerfiles in isolation systematically miss the external preconditions required for a large fraction of repayments. Code-related SATD subtypes are predominantly co-occurring with application logic files. As shown in Figure 5, Code/Version has the highest conditional probability with Logic files (P (Logic | Code/Version) = 0.83), followed by Code/MissingFunctionality, Code/Workaround, and Defect/Work-

Title Suppressed Due to Excessive Length

15

SATD Category

Build/Dependency CI/CD

Source File Type Infrastructure

Logic

Test

Code/MissingFunctionality

0.03

0.15

0.01

0.52

0.29

Code/Version

0.04

0.06

0.01

0.83

0.05

Code/Workaround

0.14

0.21

0.00

0.46

0.19

Defect/Workaround

0.16

0.19

0.05

0.45

0.16

Design/SizeReduction

0.02

0.26

0.48

0.19

0.05

0.1

0.2

0.3

0.4

0.5

0.6

Conditional Probability (P(File|SATD))

0.7

0.8

Figure 5 Heatmap of conditional probability scores for the top-5 most prevalent SATD subtypes vs. co-changed file types.

around (0.52, 0.46, and 0.45, respectively). Due to these relatively strong conditional probabilities, we can expect logic files to co-change in the same commit where code-related SATD is admitted in a Dockerfile, However, the corresponding ϕ coefficients for code-related SATD with co-changed Logic files are weak (e.g., ϕ = 0.042 for Code/Version-Logic). Also, none of the SATD subtype-file type pairs reach statistical significance after Benjamini-Hochberg correction. This suggests the binary correlation between SATD subtypes and file types is inconclusive even though co-change is frequent. Therefore, Dockerfile comments about hacks, temporary workarounds, or missing features may reflect broader architectural limitations rather than narrow coupling with a particular file type. This finding does not contradict the IaC co-evolution literature, which has established that source code is the primary driver of IaC file change [72, 29]. Design-related SATD is positively correlated with CI/CD artifacts. Table 4 shows that Design/SizeReduction exhibits a statistically marginal positive correlation with CI/CD files (ϕ = 0.115, q = 0.064), and also has the highest conditional probability with Infrastructure files among all subtypes (P (Infrastructure | Design/SizeReduction) = 0.48). Together, these results suggest that image-size and other image-optimization debt in Dockerfiles tends to co-evolve with deployment architecture and integration pipeline configurations, rather than arising from purely localized Dockerfile changes. The CI/CD

16

Wei Minn

et al.

correlation, while not reaching the conventional q < 0.05 threshold, is the second-largest ϕ value in our dataset and reflects the practical impact of build constraints on integration and deployment processes. The only statistically significant correlation in our entire dataset is Process/Review -CI/CD (ϕ = 0.157, q = 0.009), which indicates that process-oriented debt—such as comments flagging inadequate review or approval steps—is reliably co-committed with CI/CD pipeline files. Prior Dockerfile quality research has mainly studied image size as an aspect of Dockerfile that can be optimized through localized instruction changes [20, 14]. Our correlation results suggest a different mechanism: size-reduction decisions in practice co-occur with changes to surrounding infrastructure and CI/CD configurations, pointing to a systemic rather than purely local remediation pattern. Summary of RQ1 Dockerfile SATD is dominated by a code-related subtypes such as Code/Workaround, Defect/Workaround, and Code/MissingFunctionality. Across all subtypes, non-trivial proportions of SATD events are coupled with source code changes in both admission and repayment scenarios. Correlation analysis shows that coupling sources are subtypespecific: code-related SATD subtypes co-occur most frequently with cochange in Logic files, whereas size optimization-related SATD shows a statistically marginal positive correlation with CI/CD files. Process/Review is the only subtype with a statistically significant correlation, found with CI/CD files.

4 Survival Analysis (RQ2) 4.1 Motivation Although RQ1 quantifies how often Dockerfile SATD admissions and repayments are coupled with non-Dockerfile artifacts, frequency alone does not reveal whether such coupling is associated with different dynamics in which developers repay the debt. For instance, coupled SATD instances may exhibit distinct repayment dynamics from isolated SATD instances. More specifically, both the subtype of an SATD instance and its coupling status (coupled or isolated ) can influence the dynamics of its repayment. Analyzing SATD repayments along these two dimensions provides evidence on whether some forms of Dockerfile SATD should be expected to persist longer, require coordination across teams, or benefit from different debt management strategies. Thus, for RQ2, we investigate whether coupled and isolated Dockerfile SATD instances differ in their time-to-repayment.

Title Suppressed Due to Excessive Length

17

4.2 Approach Followin previous empirical studies in SATD repayment [39, 50, 76, 12], we model SATD repayment as a survival problem [30], where each SATD admission instance enters the risk set at the time it is introduced and exits when it is repaid. Instances not repaid by the end of the observation window are treated as right-censored. We compare two groups: Isolated SATD events, whose admission/repayment commits have no manually identified semantically linked co-changed non-Dockerfile files, and Coupled SATD events, for which at least one co-changed file was manually judged to be semantically linked. 1. First, we examine whether Kaplan–Meier survival curves [31] visually diverge, indicating different repayment dynamics over time. Figure 6 shows the survival curves for all SATD instances combined and for the three most common SATD subtypes. 2. Then, we use the log-rank test [54] to assess whether these differences are statistically distinguishable. Table 5 reports the corresponding log-rank tests, sample sizes, and approximate statistical power. 3. Finally, we inspect median time-to-repayment (TTR) values [30] among repaid instances to characterize the practical direction of the difference for those instances that are eventually repaid. Table 6 reports median TTR in days among repaid instances only, separately for isolated and coupled groups.

4.3 Results Overall, coupled Dockerfile SATD instances are repaid faster than isolated SATD. Top-left of Figure 6 shows the survival curve of coupled SATD remains consistently below the curve of isolated SATD for all SATD subtypes combined. This difference is statistically significant for the two population (χ2 = 5.4067, p = 0.0201) as shown in Table 5. Moreover, Table 6 shows a slightly shorter median TTR for coupled instances than isolated ones (39 vs. 41 days). This result contradicts our initial intuition and prevailing assumption that coupled SATD events might be harder and take longer to repay because they represent broader and more complex architectural limitations and compromises. Instead, our finding indicates that developers may dedicate more effort and priority toward resolving more complex technical debt instances. To investigate why coupled Dockerfile SATD in general is repaid faster, we conducted a hypothesis test about the structural difference between coupled SATD events and the isolated ones. More specifically, we use the MannWhitney U test [18] to confirm statistical difference (p = 0.0127) in the number of co-changed files between the coupled and isolated SATD events. This is consistent with findings from adjacent fields of bug-triaging [67] and issuetracking [57] where issues with broader system impact tend to be assigned higher priority and attract more attention due to their blocking nature that delay other works.

Survival Probability

18

Wei Minn

Overall (p=0.0201)

1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3

Code/Workaround (p=0.2332)

Isolated (n=633) Coupled (n=237)

Isolated (n=203) Coupled (n=89)

Defect/Workaround (p=0.0084)

Code/MissingFunctionality (p=0.1907)

Isolated (n=189) Coupled (n=63)

0

1000

2000

3000

et al.

4000

Isolated (n=106) Coupled (n=39)

0

Timeline (Days)

1000

2000

3000

4000

Figure 6 Kaplan–Meier survival curves comparing isolated and coupled SATD instances overall and for the three most frequent SATD subtypes. Lower curves indicate a lower probability of remaining unrepaid over time. Shaded areas denote confidence intervals.

The SATD subtype with most difference in survival between coupled and isolated events is Defect/Workaround, where coupled SATD is significantly less persistent than isolated SATD. The bottom-left of Figure 6 shows the coupled curve drops steeply early in the timeline and stays well below the isolated curve throughout the observation window. Log-rank test shown in Table 5 confirms the statistical significance of this difference (χ2 = 6.9559, p = 0.0084), with the highest power of all subtype analyses (0.7509). On the other hand, Table 6 shows that isolated Defect/Workaround SATD has median TTR of 47 days, compared with 51 days for coupled instances. This minor reversal in median indicates that the key distinction is not necessarily that every coupled workaround is repaid faster, but that coupled workarounds are less likely to remain indefinitely unrepaid. This is in line with prior works that showed that workarounds for bugs in upstream libraries tend to accumulate as long-lived debt [41, 73]. However, the bug is being actively tracked by maintainers, which in turn increases the probability that the workaround will eventually be retired rather than left indefinitely. This aligns with the finding from the aforementioned hypothesis test on structural difference that confirmed coupled SATDs are more often repaid, as they represent coordinated remediation efforts that comprises higher-priority bug fixes observed in open-source maintenance studies [67, 57].

Title Suppressed Due to Excessive Length

19

Table 5 Survival Analysis and Log-Rank Statistical Power per SATD subtype, sorted by statistical significance (p-value) in descending order. SATD Category Defect/Workaround Code/Version Code/BaseImage Code/MissingFunctionality Test/IntegrityCheck Design/SizeReduction Code/Workaround Test/ImprovementForTest Unclassifiable Process/Review Process/Deployment Defect/LatentBug Overall

# Iso. 189 17 18 106 13 41 203 4 13 17 10 2

# Cpl. 63 20 4 39 5 3 89 2 4 5 3 0

χ2 6.9559 5.0185 1.9429 1.7122 1.5687 1.4574 1.4214 1.25 0.4865 0.4447 0.3 -

p-value 0.0084 0.0251 0.1634 0.1907 0.2104 0.2273 0.2332 0.2636 0.4855 0.5049 0.5839 -

Power 0.7509 0.6104 0.2857 0.2574 0.2396 0.2258 0.2213 0.1999 0.1034 0.098 0.0789 -

633

237

5.4067

0.0201

0.6425

Code/Workaround shows a similar directional pattern as Defect/Workaround, but the evidence is not strong enough to claim a reliable difference. In Figure 6 (top-right), the coupled curve is generally below the isolated curve early on, suggesting that coupled instances may be repaid somewhat faster. Moreover, Table 6 shows that among repaid instances, coupled Code/Workaround SATD has a much shorter median TTR than isolated SATD (27 vs. 84 days). This large difference in medians suggests that the difference remains consistent within the subtype. However, Table 5 shows that the survival difference is not statistically significant (p = 0.2332), and the estimated power is low (0.2213). Thus, the data suggest a potentially meaningful practical effect, but one that our existing sample cannot establish with confidence. Despite this lack of statistical significance, the large gap in median TTR (27 vs. 84 days) provides an alternative perspective to the survival analysis, following prior empirical studies SATD repayment [42, 13, 50]. Code/MissingFunctionality exhibits the opposite trend from workaround-related SATD subtypes: coupled SATD appears more persistent than isolated SATD. Bottom-right of Figure 6 shows the coupled survival curve above the isolated one throughout the timeline, indicating a higher probability of remaining unrepaid. Median TTR statistics in Table 6 reinforces this observation, as repaid coupled instances have a longer median TTR than isolated instances (42 vs. 10 days). This could indicate that SATD in Dockerfile caused by missing functionality may require non-trivial implementation in the source code that require more substantial effort compared to simple cleanup and refactoring. However, as with Code/Workaround, the log-rank test shown in Table 5 is not statistically significant (p = 0.1907). This pattern is consistent with findings in the SATD literature regarding requirement debt [43, 55, 10], where missin feature debt has been identified as the most persistent and costliest category because its repayment is contingent on implementation work rather than simple cleanup.

20

Wei Minn

et al.

Table 6 Time-to-Repayment (TTR) in Days Comparison for Repaid Instances, sorted by Median TTR for Coupled SATD instances in ascending order. SATD Category Unclassifiable Code/Workaround Code/Version Code/MissingFunctionality Defect/Workaround Design/SizeReduction Code/BaseImage Process/Review Test/IntegrityCheck Process/Deployment Test/ImprovementForTest Defect/LatentBug Overall

# Iso. Repaid 4 59 10 37 67 13 12 11 3 1 4 0

Iso. Median TTR 1.0 84.0 121.5 10.0 47.0 21.0 30.5 8.0 415.0 27.0 1137.5 -

# Cpl. Repaid 2 31 18 9 32 2 1 3 2 0 0 0

Cpl. Median TTR 18.0 27.0 27.0 42.0 51.0 58.5 253.0 563.0 636.5 -

221

41.0

100

39.0

Other subtypes and statistical strength. Beyond the three most prevalent SATD subtypes, Code/Version is the only subtype to exhibit statistical significance in survival difference (p = 0.0251) where coupled instances more likely to be repaid than isolated ones. However, the caveat is that this finding rests on a small sample (#iso=17, #cpl=20) with an estimated power of only 0.6104. Several other subtypes (Process/Review and Code/BaseImage) exhibit large descriptive gaps in median TTR, but are too sparse to support strong inferential claims. This general limitation in statistical power for subtype-level analyses is natural result of the long tail of Dockerfile SATD categories first presented by Azuma et al. [9] and later corroborated by us in Section 2.5. This implies that a purely quantitative lens does not suffice for explaining the nature of Dockerfile SATD and its co-evolution and thus, warrants a qualitative study follow-up for all the SATD subtypes in RQ3 (Section 5). Summary of RQ2 Coupled Dockerfile SATD instances are repaid faster than isolated ones overall (p = 0.02), contradicting our initial intuition that cross-artifact debt incurs greater costs in terms of repayment time. In particular, with Defect/Workaround, coupled instances are significantly less likely to remain unrepaid (p = 0.0084). Our further quantitative analysis reveals that coupled SATD events are repaid with statistically higher number of co-changed files (p = 0.0127), in line with prior findings where co-evolution means active bug tracking and issue prioritization. While Code/Workaround exhibits a large gap in median TTR (27 vs. 84 days), the effect is not statistically significant. Conversely, Code/MissingFunctionality coupled SATD appears more persistent than isolated SATD, consistent with requirement debt that is contingent on substantial implementation work rather than simple cleanup.

Title Suppressed Due to Excessive Length

21

5 SATD-source code Co-evolution Patterns (RQ3) 5.1 Motivation As presented in previous sections, Dockerfile SATD comments have non-trivial coupling rates both during admission and repayment. The existing work that taxonomizes SATD in Dockerfile [9] only looks at the content inside the comment (e.g., Defect, Workaround ) and surrounding code chunk, but they do not study the cross-artifact reasons that caused the debt to be admitted or that eventually enabled its repayment. Without this perspective, both practitioners and researchers cannot answer actionable questions such as: “What kind of change in our application code is most likely to introduce a new Dockerfile SATD?” or “What kind of code evolution is a prerequisite for retiring a suboptimal Dockerfile workaround?” To fill this gap, we conduct a qualitative study that taxonomizes (a) the admission triggers which are cross-artifact changes that necessitate the introduction of a Dockerfile SATD comment, and (b) the repayment requisites which are cross-artifact changes that enable the removal of a Dockerfile SATD comment. These two taxonomies collectively answer RQ3 and complement the quantitative coupling measurements reported for RQ1 and RQ2.

5.2 Approach Following prior taxonomy studies in empirical software engineering [15, 51, 70], we conduct open-coding and axial-coding to characterize the source code-side co-evolution in the SATD events in our dataset. Co-evolution dataset. Our SATD coupling annotation in Section 2.6 produced a set of 411 coupled SATD events where there is at least one co-changed nonDockerfile file was manually labelled as semantically-linked. Each SATD event is represented by the schema described in Table 2 of Section 2.3, containing the SATD comment, its Dockerfile context, the commit message, and the diff snippets of all semantically linked co-changed files. Open coding. In the pilot round, we randomly sample a subset of 15 events from each SATD subtype. If a subtype has less than 15 events, we include all of the events for the subtype in this iteration. Consequently, we end up with a pilot set of 82 admission events and 82 repayment events (164 units in total). The first three authors independently analyzed the pilot set where for each SATD event, they read the full context of the SATD event, (the SATD comment text, the surrounding Dockerfile instructions, the commit message, and the diff snippets of semantically-linked co-changed files), and drafted a free-text category label and corresponding rationale that captures (i) what changed in the source code file, and (ii) why that change caused the Dockerfile SATD to be admitted or enabled it to be repaid, After the pilot round, a

22

Wei Minn

et al.

synchronization meeting was held: the annotators discussed the initial codes and disagreements, and produced a preliminary fine-grained codebook that comprises source codce change patterns observed in the SATD events both admission and repayment events. Using the preliminary codebook, the annotators independently applied it to the remaining 249 coupled events in the co-evolution dataset. An adjudication meeting was held to resolve labeling conflicts and to refine the codebook. Axial coding. After the fine-grained codebook stabilized, the first three authors discussed the categories and grouped the finer-grained codes into higher-level themes. Each higher-level theme was assigned a concise name, a definition, with representative examples drawn from the dataset for each fine-grained codes, and highlight of the common theme across those examples. Validation. The draft taxonomies were presented to the remaining co-authors in a face-to-face review session. For each category, all the co-authors discussed the category name, definition, and representative examples. The first three authors answered the questions raised by the remaining co-authors, and rearranged themes for some of the fine-grained codes, and clarified cases where the boundaries were ambiguous and causing confusions. The taxonomies were revised iteratively until consensus was reached among all authors.

5.3 Results Figures 7 and 8 show the taxonomies of SATD admission triggers, and repayment requisites discovered via the open- and axial-coding process. We identified 14 types of admission triggers clustered under 4 overarching themes, and 11 types of repayment requisites under 3 overarching themes. Example SATD instances discussed below can be all found in full context (i.e., SATD comment, commit message, surrounding code chunks, diff snippets of co-changed files, etc...) in our publicly available dataset [49]. 5.3.1 Admission Triggers Admission Theme 1 – External Dependency Constraints. This cluster comprises 80 instances across 4 categories of SATD admission triggers that arise outside the developer’s direct control. Unstable / Untagged External Dependency. Package manifests and dependency configurations could include SemVer tags [56] to not yet stable versions. Therefore, developers have to delete lock-files, and use temporary/placeholder identifiers as workarounds in the Dockerfiles. For example, a package.json included direct GitHub references for lnd-engine and grpc-methods without proper version pins, and the Dockerfile was forced to delete packagelock.json so that its npm install command could re-resolve these packages

Title Suppressed Due to Excessive Length

23

Admission Triggers Distribution

40

35

30

33

26 15 7

Cross-Artifact Synchronisation Burden

Download Integrity / Security Gap

4

Incomplete / Deferred Feature

Multi-Environment CI/CD Migration

5

Broken / Dysfunctional Tooling

Security / Sandbox / Kernel Incompatibility

6

10

OS / Distro Version Mismatch

8

Hardcoded Path / Base-Image Constraint

Binary Artefact Committed Instead of Fetched Remotely

Upstream Release Lag / Unreleased Fix

4

Shell / Entrypoint Script Dependency

5

Missing Upstream Package Forcing Source Compilation

0

16

Delegated Install Script Pending Upstream Packaging

20

Unstable / Untagged External Dependency

Number of instances

50

10

54

External Dependency Constraints Compatibility & Environment Issues Incomplete Implementation Maintenance Overhead

Figure 7 Taxonomy of admission triggers for coupled Dockerfile SATD, clustered into four overarching themes.

dynamically 3 . admitted the technical debt: “hack for Ruby 2.7.3” in the Dockerfile 4 . Missing Upstream Package Forcing Source Compilation. When a new dependency is not yet available inside the base image, developers are forced to do multiple source-compilation as a workaround in the Dockerfile. For example, prometheus-client-c v0.1.3 was unavailable in Alpine’s package index. This forces the developers to add in a dedicated dist-libprom build stage to compile it from source 5 . Alongside the workaround, the developer stated in the SATD comment that it should be revisited “when Alpine packages the dependency”. Upstream Release Lag / Unreleased Fix. The upstream fix or file is available online, but not officially released yet. Therefore, the developer have to pin hard-code pre-release branch names or raw commit hashes in the Dockerfile. 3

row 4 rows 41, 44 5 rows 10, 73, 74 4

24

Wei Minn

et al.

For example, the offical release tag for the upstream valkey-search repository does not contain the required fix when packaged together with Alpine Linux. In this case, it is caused by the developer’s decision to add Alpine Linux support, but the Alpine Linux image’s pre-packaged valkey-search dependency does not contain the fix yet. Therefore, the developer had to clone the upstream at the specific commit that contains the nessary fix 6 , Binary Artifact Committed Instead of Fetched Remotely. When the developer copies a binary directly into the repository as a workaround rather than fetching it via curl, they are forced to admit a TODO comment inside the Dockerfile to switch to a proper remote download in the future 7 . Admission Theme 2 – Compatibility and Environment Issues. 78 instances arise from mismatches between the container build or runtime environment, and the assumptions in source code, or other configuration files. Shell / Entrypoint Script Dependency. When startup scripts adopt Bashspecific features, the developer must replace the default POSIX shell with Bash in the Dockerfile. Alongside the Bash macro, the developers also usually admit a “hack” to annotate this as necessary but a suboptimal configuration. For example, after a co-changed ros entrypoint.sh adopted #!/bin/bash and relied on the source builtin, the Dockerfile was forced to replace /bin/sh 8 . In another case, the developer added a new xrdp/start.sh startup script whose execution context depends on PATH variable, and thus was forced to do a redundant PATH export in the Dockerfile 9 . Hardcoded Path / Base Image Constraint. When the upstream base image assumes rigid path formats, the developer is forced to use a workaround in Dockerfile to match the expected filesystem layout. For example, the Hyperledger Fabric base image assumes the existence of /opt/gopath path. Thus, the developer inserted a symlink (ln -s $GOPATH /opt/gopath) as a workaround which is admitted as “hard-coded problem” 10 . In another instance, OpenRV’s custom PySide2 compilation was conflicting with system-installed Qt. This required the developer to reinstall Qt into the /tmp/qttemp path as a workaround 11 . Security / Sandbox / Kernel Incompatibility. When the Docker build environment comes with security constraints that impede building or running of the application, the developer is forced to use workarounds to circumvent the security constraints. For example, two independent commits describe FUSE installation as requiring manual .deb repackaging because Docker’s 6

rows 53-55, 60-63, 66 row 2 8 row 0 9 row 14 10 row 1 11 row 34 7

Title Suppressed Due to Excessive Length

25

overlay filesystem does not support mknod during build 12 . In another case, a virtiofsd Rust patch disables sandboxing and comments out capabilityenforcement errors, acknowledged as a “huge ugly hack that barely works” 13 . OS / Distro Version Mismatch. When there is OS or distribution version mismatches caused by base-image upgrades in co-changed build scripts, the developer have to resolve the version conflicts using workarounds in the Dockerfiles. For example, upgrading from Ubuntu 20.04 to 24.04 in a co-changed build openfoam.sh introduced apt-get temporary-file failures. This required the developer to add a manual directory cleanup workaround 14 . Broken / Dysfunctional Tooling. When a co-changed script or dependency introduces a bug in a tool that the Dockerfile relies upon, the developer admit the workaround and references the upstream issue. For example, a co-changed entrypoint.sh used tlmgr to install TeX Live package. However, the tool was not functional in the Alpine build context, thus forcing the developer to admit a work-in-progress SATD comment 15 . Likewise, a bug in the Transifex generation process prevented pulling nutmeg.1 translation strings, and forced the developer to add a workaround with a hardcoded open-release/nutmeg.master version in the Dockerfile 16 . Multi-Environment CI/CD Migration. When migrating the project to a new CI environment, the Dockerfiles in the project need to remain compatible with configuration value formats expected by both the new and old (legacy) CI environments. For example, ray-project/ray project migrated from old CI environment, civ1, to the new CI environment, civ2, which expects the requirements.txt files to be under python/ subdirectory unlike civ1. This could cause exception when deploying in legacy civ1 environment as the python/ path is non-existent. Thus, the developer had to ”workaround” this exception in civ1 by ignoring the missing sources 17 . Admission Theme 3 – Incomplete Implementation. There are 73 instances across 3 categories of admission triggers indicating the deferral of featureand security-related implementations, or packaging steps. Delegated Install Script Pending Upstream Packaging. When upstream binary packaging infrastructure is not yet available, developers introduce external shell scripts as placeholders and admit the debt explicitly. For example, four variants of the CNTK image introduced a install-cntkdocker.sh script as a temporary proxy to handle proper binary distribution mechanism for Anaconda setup, which the developer could not implement 12

rows 37, 39 row 6 14 rows 33, 38 15 row 5 16 row 36 17 row 7 13

26

Wei Minn

et al.

immediately yet. Thus, the developer admitted “TODO: Implement via modifying Binary Drop package” in the Dockerfile 18 . Incomplete / Deferred Feature. Some features implemented in the source code and configuration files are finalized with corresponding commands inside the Dockerfile. Hence, there are cases where those corresponding commands cannot be implemented inside the Dockerfiles by the developer yet due to a multitude of unforeseen reasons. For example, in tianon/dockerfiles project, the developer added a stable variant of a new feature to the configuration, but was unable to conduct verification with non-amd64 variant of dependencies. Thus, the developer had to hardcode amd64 parameter to the APT sources list when installing dependencies in the Dockerfile 19 . Thus, the developer notifies the maintainers about the technical debt Download Integrity / Security Gap. As the developer introduces new externally fetch binaries to the project, the developer might also admit a TODO for a deferred integrity check command for the binaries inside the Dockerfile. For example, when a co-changed update.sh script automated binary version tracking from GitHub releases, the developer added a TODO noting that .asc and .sha256sum verification were not yet implemented 20 . In another instance, a wiremock extension dependency was switched to a new Maven Central JAR without checksum validation 21 , and js-yaml downloads within a MongoDB 8.0 upgrade lacked GPG verification despite the rest of the image using rigorous PGP checks 22 . Admission Theme 4 – Maintenance Overhead. Cross-Artifact Synchronisation Burden. During maintenance processes that involve refactoring or upgrading of an artifact, the developer have to admit technical debt if they are not able to keep the Dockerfiles consistent with the design decisions inside the artifact. For example, installing supervisord for process management introduced complexities regarding zombie process issues requiring tini. Thus, the developer had to admit in the Dockerfile a TODO comment referencing a known GitHub issue about the interaction between the two tools 23 . In another case, during the migration golangci-lint from v1.46 to v1.49, a //nolint directive in cluster.go could not be removed until the linter was updated again 24 .

18

rows 3, 11, 13, 40 rows 21 20 row 68 21 row 69 22 row 70 23 row 30 24 row 42 19

Title Suppressed Due to Excessive Length

27

Repayment Requisites Distribution 40 30 24 21

20

21 15

4

Security / Integrity Verification Added

Feature Branch / Temporary Artefact Replaced

5

Multi-Architecture Support Added

4

Missing Feature Implemented

4

Build-System Modernisation

Base Image / OS Upgrade

Application-Side Architectural Refactor

CI/CD Pipeline Refactoring

10

Deprecated or Removed Dependency / Tool

0

11

Upstream Bug / Patch Fixed

10

Upstream Version / Tag Released

Number of instances

46

Upstream Progression Internal Refactoring Feature Completion

Figure 8 Taxonomy of repayment requisites for coupled Dockerfile SATD, clustered into 3 overarching themes.

5.3.2 Repayment Requisites Repayment Theme 1 – Upstream Progression. 55 repayment events are enabled by events outside the project such as upstream version releases, upstream bug fixes, or the outright removal of a deprecated dependency. Upstream Version / Tag Released. When the SATD comment contains an explicit version condition, it can only be satisfied by upstream version releases that are reflected by a version bump in a co-changed versions.json, or manifest.yml. For example, an SATD comment regarding Perl 5.33.7 compatibility patch was repaid when a co-changed build file bumped VERSION from 0.9999 to 1.0.0 25 . In another case, an Imagick PECL-incompatibility workaround in the Dockerfile was repaid after the release of imagick-3.8.0 which was reflected in co-changed versions.json and update.sh in the same commit 26 . 25 26

row 0 rows 4, 14

28

Wei Minn

et al.

Upstream Bug / Patch Fixed. When the bug identified inside the SATD comment has been fixed in the upstream dependency, it is reflected in the changes in test files that where the developer can remove source code-side workarounds such as skip guards, and deferred assertions. For example, in dotcloud/docker project, a workaround in Dockerfile where the developer used iptables-legacy instead of nf tables which was not supported by both the CI hosts and application code. Only when the test file, libnetwork/firewall linux test.go, was updated with a new runtime detection logic for nf tables, it indicates that the application code has been patched to support nf tables, thus allowing the workaround in the Dockerfile to be removed as well 27 . Deprecated or Removed Dependency / Tool. The developers remove upstream tools (that may be deprecated) thus, enabling the repayments of the technical debt that exists due to workaround required by the feature or tool that no longer exists in the codebase. For example, the ksonnet workaround was repaid by the complete removal of ksonnet support: installer scripts, documentation, and hack/tool-versions.sh were all deleted in the same commit 28 . Also, three separate instances of an FPM-based Debian packaging workaround (“TODO: replace FPM with minimal debhelper stuff ”) were repaid when hack/release.sh removed the entire release ubuntu() function and RELEASE-CHECKLIST.md was updated to use hack/make.sh build-deb 29 . Repayment Theme 2 – Internal Refactoring. There are 80 repayment events across 5 categories that we found to be enabled by internal factors such as: CI pipeline refactor, base image change, build system modernisation, or replacing a temporary artifact with a stable one. CI/CD Pipeline Refactoring. The developer repays the SATD inside the Dockerfile by moving the associated workaround out of the Dockerfile, and into a dedicated build infrastructure. This is enabled by refactoring the pipeline into a multi-stage or multi-container build process. For example, in StefanScherer/dockerfiles-windows, a PowerShell bug causing a specific MSI installation failure forced the developer into a workaround involving the installation of a full Windows SDK which is considered to be heavy. To repay this hefty workaround, the developer used an intermediate Dockerfile solely for installing the SDK, and then extracted only the necessary library files into a temporary directory before building the main Dockerfile 30 . Application-Side Architectural Refactor. The developer performs the various application-side architectural refactoring such as modularisation, dependency restructuring, process-manager changes, and build-system consolidation, and consequently removes the corresponding workaround in the Dock27

row 7 row 5 29 rows 33, 38, 43 30 row 9 28

Title Suppressed Due to Excessive Length

29

erfile. For example, the developer split the monolithic install-binaries.sh into per-binary *.installer files that allowed the Dockerfile to remove a version synchronisation-related SATD that explicitly referenced the old script 31 . In another instance, the developer migrated from Hive-on-Hadoop to building Spark from source, and rendered an entire Guava-jar conflict workaround obsolete 32 . Base Image / OS Upgrade. The developer upgrades base image or OS to resolve version-specific workarounds caused by missing packages or runtime capabilities in previous distributions. For example, both the plpython3 Debian Sid hack and the Coturn mongo-c-driver source-compilation workarounds were repaid by upgrading the base image from Debian Buster to Bullseye, which made the required packages available in official repositories 33 . Moreover, the co-changed CHANGELOG file explicitly notes the Debian version upgrade as the enabling factor in each of the cases. In another case, upgrading from tomcat:8.5-jre8 to an s6-overlay-compatible base image enabled the introduction of proper service management (rootfs/etc/services.d/tomcat/run), resolving a long-standing TODO about rebasing 34 . Build-System Modernisation. Developers upgrade to a more modern buildsystem so that they can abstract the complex manual implementations away using a now capable framework. For example, BuildKit’s native --platform or TARGETPLATFORM via docker-bake.hcl supports the cleaning of testing-only binaries from the main stage. Thus, the manual hacks using hack/make/cross script and the associated DOCKER CROSSPLATFORMS variable inside the Dockerfile were now obsolete, and its associated SATD comments could now be removed 35 . Feature Branch / Temporary Artefact Replaced. The developer replaces a feature branch-specific temporary image with the stable official Docker Hub image once the branch condition check inside the CI configuration file was removed. For instance, in baserow/baserow project, the Dockerfile had been temporarily pinned to a GitLab CI registry image indicating a development branch. The repayment of this SATD was enabled by the co-changed in .gitlab-ci.yml configuration file which removed the branch restriction check, and enabled the switch to the official baserow/baserow:1.10.1 image 36 . Repayment Theme 3 – Feature Completion. There are 30 instances across 3 categories of SATD repayment events corresponding to the explicit implementation of features or security practices such as implementation of missing features, adding multi-architectural support, and adding security/integrity verification. 31

rows 44, 57, 59 row 2 33 rows 31, 37, 51, 52 34 row 48 35 rows 71, 72, 80, 81 36 row 53 32

30

Wei Minn

et al.

Missing Feature Implemented. The developer adds previously absent source code, configuration, or test cases for the Dockerfile to invoke. For example, in tianon/dockerfiles project, the # TODO copy/steal ‘‘browser.sh’’ stuff from slack SATD comment was repaid at the creation of zoom/browser.sh which implements the logic that uses Zenity library to prompt the user for URL input 37 . In another case, in mondoohq/installer project, workaround in Dockerfile regarding over infeasible non-root container support was repaid when the CI pipeline introduced dedicated rootless build targets that provided a clean separation between root and rootless variants 38 .

Multi-Architecture Support Added. The developer adds structured perarchitecture metadata such as URLs, checksums, dpkg mappings in versiontracking artifacts for the Dockerfile to reference.This enables the repayment of technical debt regarding hard-coded configuration values in Dockerfile. For example, in the containerd project, the developer extended versions.json with per-architecture entries for amd64, arm64, ppc64el, riscv64 and s390x, and added deb arch mapping function to lib.jq This enable the repayment of # TODO multiple architectures comment in the Dockerfile which now switches to dynamic case selection 39 . In another case, the developer added support for cross-compilation between linux/386 and linux/arm in the hack/release.sh via armel handling and added platform-agnostic build tags in pkg/netlink/netlink unsupported.go 40 .

Security / Integrity Verification Added. The developer added automated checksum or GPG infrastructure in co-changed version-tracking scripts or release tooling. This allows the repayment of download integrity-related SATD in the Dockerfile. For example, the # TODO .sha256sum for containerd was repaid when versions.sh gained logic to fetch .sha256sum files automatically, and versions.json was extended with per-architecture SHA256 hashes 41 . In another instance, a GPG fingerprint TODO in an Apache Geode Dockerfile was resolved by converting the static fingerprint to a $$PLACEHOLDER$$ that promote rc.sh fills via sed during release promotion 42 .

37

row 26 rows 39, 41 39 rows 19, 28, 77, 78 40 rows 20, 24, 25, 27 41 rows 77, 78 42 row 76 38

Title Suppressed Due to Excessive Length

31

Summary of RQ3 We present 14 types of admission triggers with 4 overarching themes (external dependency constraints, compatibility and environment issues, incomplete implementation, maintenance overhead) where external dependency constraints is the most common theme of admission triggers. We also present 10 types of repayment requisites with 3 overarching themes (upstream progression, internal refactoring, feature completion) where internal refactoring is the most common theme of repayment requisites.

6 Implications 6.1 Implications for Researchers Extend automated SATD tools to consider cross-artifact relationships. Building on the preceding unit-of-analysis argument, existing automated SATD detection and repair approaches predominantly operate on individual files [46, 23, 24]. Our results indicate that such tools systematically miss the external preconditions for repayment. In the SATD lifecycle example depicted by Figure 1, the version-related workaround SATD in the Dockerfile is caused by a Glide-related script somewhere else in the project. From automated SATD annotation perspective, existing tool would not be able to detect the source code-side workaround that implemented Glide module, and thus, would not be able to reflect this workaround inside the Dockerfile as well. The repayment of this workaround also involves source code-side evolution that represents migration from Glide- to Go-based configuration files. Automated this repayment process would require the tool to factor in such source codeside evolution to synthesize code changes that encompasses the code chunks in the Dockerfile that is effected by migration that happened inside the source code. Therefore, researchers building the next generation of automated tools for SATD detection, annotation, tracking, or repair should incorporate such cross-artifact signals such as code artifact co-change graphs, and diff snippets of co-changed alongside SATD comments for inputs. Cross-artifact signals in other software engineering topics. Despite the prevalence of production-test co-evolution topic in software engineering [44, 68, 34, 69, 66, 16, 35, 65], multiple topics in software engineering such as Dockerfile smells detection and repair [14, 20, 61, 63], Code-Comment Inconsistency (CCI) resolution [59, 35] are still limited in terms of their single-artifact scope. Even though latest work in Dockerfile flakiness repair, FlakiDock [63], involves the inspection of exception messages during Docker image build process, they do not consider additional context from the source code-side artifacts that might be related to the exception, and posted modest performance improvement of

32

Wei Minn

et al.

only 0.58% over the state-of-the-art, Parfum [20]. Hence, integrating crossartifact signals to improve contextual roadblocks is a promising direction for researchers in other software engineering topics to investigate.

6.2 Implications for Developers Annotate SATD with explicit cross-artifact context at admission time. The admission trigger taxonomy presented in RQ3 (Section 5) shows that most Dockerfile SATD originates from external artifacts/projects such as incomplete implementation, upstream release lag, and broken toolings. Therefore, developers include explicit cross-artifact context in the SATD comment. For example, including the link to the GitHub issue shows the status of technical debt caused by defects in the upstream dependency. The paths to the related source or manifest files that caused the workaround allows maintainers to readily access the related files during the SATD repayment. Such additional context also reduce the risk of persistent SATD that causes blockages to resolving issues and other technical debt [45, 67, 57]. Extend upstream release monitoring tools to automate Dockerfile maintenance. In the admission trigger category of upstream release lag described in RQ3 (Section 5), developers usually pin commit hashes or pre-release tags when the upstream dependency has not released the feature or bug fix. Thus, this technical debt is simply waiting for the release of that feature or bug fix. This means that linking the automated upstream dependency monitoring tools such as Dependabot [2] and Renovate [3] can be extended to track dependency-related SATD in the project, and apply pre-written modifications to the Dockerfile to automatically repay SATD.

7 Threats to Validity 7.1 Internal validity. Keyword-based SATD candidate extraction. The first threat to internal validity is the use of keywords such as TODO, FIXME, HACK, and WORKAROUND to extract SATD candidate comments that can miss out actual SATD comments that do not contain those keywords. However, this approach is following prior works in empirical studies about SATD both in Dockerfile domain [9] and outside of it [26]. Moreover, the completeness of this keyword-based approach has already been statistically validated by Azuma et al. [9] that only 1.83% of comments that do not contain SATD keywords are SATD. Inter-rater disagreement during manual annotation tasks. We mitigate this risk with the three-phase protocol described in Section 2.3: a pilot phase for codebook refinement, a reliability phase on a shared subset of 100 instances

Title Suppressed Due to Excessive Length

33

per task, and a production phase with adjudication for conflicting cases. In the reliability phase, the two annotators achieved Cohen’s κ values of 0.66 (SATD identification), 0.63 (subtype classification), and 0.62 (event coupling classification), all indicating substantial agreement [33]. This proves that the codebook is reliable, and the annotators can move on to label the rest of the dataset in the respective tasks. Production phase shows similar levels of agreement as the reliability phase, and all the disagreements are manually resolved during a adjudication meeting between the two labellers. Low statistical power for survival analysis. As shown in Table 5 of RQ2 (Section 4), survival analysis dataset contain only a few instances for several SATD subtypes, and limits the statistical power of log-rank tests. This is in spite of our dataset construction via stratified prefix sampling which involves scrapping of Docker Hub by query the DockerHub API for all the projects that starts with all combination of 3-character prefixes. However, this quantitative aspect of our study is only one half of the equation; we complement the quantitative analyses with the qualitative taxonomy study in RQ3 (Section 5), and presented concrete examples of source code-side co-evolution that trigger admissions or enable repayments of SATD in Dockerfiles. This is in line with existing empirical studies in self-admitted technical debt repayments [50, 76, 12] that strengthen limited quantitative time-to-event results with qualitative analyses.

7.2 External validity. Our dataset comprises Docker Hub-GitHub linked open-source projects with at least one star, and our qualitative taxonomy is based on 411 coupled SATD events from these projects. Therefore, our qualitative findings are most relevant to these actively maintained open-source containerized projects. We require extension to this work to validate our findings on closed-source images, other container ecosystems (e.g., Podman [6], Buildah [1]), or to non-Docker IaC artifacts (e.g., Kubernetes manifests [53], Terraform configurations [7]). However, our work follows the already-established research topic of Dockerfiles [61, 14, 20, 60, 21, 71], and focuses on adding co-evolution perspective to provide more context to the study of SATD in Dockerfiles.

8 Related Works 8.1 SATD Identification and Classification Early approaches for SATD detection relied on keyword and pattern matching in source-code comments [26]. Subsequent work uses NLP-based classifiers that could outperform such keyword-based heuristics for identifying design and requirement debt [43]. Text-mining approaches with composite cross-project

34

Wei Minn

et al.

classifiers [28] and CNN-based models [58] further improved detection accuracy and cross-project generalizability. More recently works apply fine-tuned large language models for better identification performance [64]. Finally, multi-task learning approaches leverage information from various artifacts such as code comments, issue trackers, pull requests, and commit messages [37, 25, 36], and jointly model SATD alongside other topics such as code vulnerabilities [62]. All of these detection and classification approaches have the limited scope of considering only the comment text and its immediately surrounding code. Our work builds on top of the keyword-based approach [26] for SATD candidate extraction, and adds a cross-artifact dimension that existing SATD detection approaches do not consider.

8.2 Production-Test Co-evolution Early works in production-test co-evolution established the notion that production and test code should ideally evolve synchronously [74, 75, 40]. Subsequent studies mined fine-grained co-change patterns via association rule mining to identify source file type-specific relationships between production and test co-modification [44, 68]. Levin and Yehudai [34] showed that even though developers frequently fix production code without updating the test cases, when test maintenance does occur, it correlates with semantic change in production code. More recently, Wang et al. [69] built predictive models to detect outdated tests to identify when co-evolution is needed while Sun et al. [66] investigated the assumption underlying co-evolution sample construction to remove noise, and proposed a more reliable identification technique. Lastly, approaches leveraging LLMs to automate co-evolution [16, 35] use structural similarity metrics to generate co-evolved test cases [65]. Our work applies this co-evolution premise from the production-test relationship to the Dockerfile-source code relationship, and investigates not only the prevalence, but also what reasons behind the co-evolutions.

8.3 Code-Comment Inconsistency Fluri et al. [22] empirically studied comment-code co-evolution across eight software systems, and found that even though code and comments co-evolve in roughly 90% of cases, those changes are re-documented only in later revisions rather than in the commits where those co-evolution happens. Such cases of deferred updates motivate the topic of code-comment inconsistency (CCI) that studies comments that do not faithfully describe their corresponding pieces of code. Rong et al. [59] extended CCI research from detection towards automated rectification by fine-tuning a large language model to both identify and correct inconsistent comments. They reported that automated CCI resolution requires leveraging the semantic relationship between a comment and its surrounding code context. While CCI research study code comments

Title Suppressed Due to Excessive Length

35

within the files they are contained in, our study puts Dockerfile SATD into context of the commit-level view involving co-changed artifacts, shifting the paradigm from intra-file to cross-artifact.

8.4 IaC-Source Co-evolution Jiang and Adams [29] showed that IaC specification files (Puppet/Chef) are large, churn frequently, and are tightly coupled with test files across OpenStack projects. Wu et al. [72] characterized Dockerfile change patterns across 4,110 GitHub projects and reported how Dockerfiles co-change with other project files, although without examining the rationale behind such co-changes. These studies focus only on structural co-change (whether files change together, and to what extend), and does not investigate the rationale behind the co-changes. For example, they do not ask whether a change in an infrastructure file was triggered by a technical limitation acknowledged in the co-changed file Our work fills this rationale gap by using investigating co-change or co-evolution patterns as the rationale behind Dockerfile SATD admissions and repayments, thereby connecting the IaC co-evolution literature with the SATD lifecycle literature for the first time within our knowledge.

9 Conclusion and Future Work We studied self-admitted technical debt (SATD) in Dockerfiles through the lens of co-evolution. We conducted a empirical study on a Docker Hub-GitHub dataset, by manually annotated SATD instances in Dockerfile and their coupling with other source files. We used the annotated dataset to answer three research questions on the prevalence, coupling rates, survival rates, and characteristics source code-side changes that trigger or repay SATD in Dockerfiles. We found that Dockerfile-only view is an incomplete unit of observation as approximately 27% of admissions and 40% of repayments events involve coevolution with source code. We also found that coupled SATD is repaid faster overall (p = 0.0201) although Code/MissingFunctionality coupled instances persist longer. In future work, we plan to generalize this SATD-source code co-evolution paradigm to other IaC technologies such as Kubernetes and Terraform to investigate relationship between the prevalence of SATD and security vulnerabilities in IaC artifacts, and their automated remediations. Moreover, researchers in existing software engineering topics such as automated SATD repayment, code smell repair, and code-comment inconsistency rectification can integrate the co-evolutionary perspective to overcome source code-related roadblocks discussed in this work to achieve breakthroughs in their respective areas.

36

Wei Minn

et al.

Data Availability The dataset constructed and analyzed for this study is publicly availably online at: https://osf.io/sh5xd/overview?view_only=e06572d75ee54348807f 3925c14b0371 [49].

References 1. buildah.io. URL https://buildah.io 2. Dependabot quickstart guide. URL https://docs-internal.github.com/en/code-sec urity/tutorials/secure-your-dependencies/dependabot-quickstart-guide 3. Dependency Dashboard - Renovate Docs. URL https://docs.renovatebot.com/key-c oncepts/dashboard/ 4. Docker: Accelerated Container Application Development. URL https://www.docker.c om/ 5. Docker Hub API reference | Docker Docs. URL https://docs.docker.com/referenc e/api/hub/latest/ 6. Podman. URL https://podman.io/ 7. Terraform | HashiCorp Developer. URL https://developer.hashicorp.com/terraform 8. What Is Containerization? | IBM (2024). URL https://www.ibm.com/think/topics/c ontainerization 9. Azuma, H., Matsumoto, S., Kamei, Y., Kusumoto, S.: An empirical study on selfadmitted technical debt in Dockerfiles. Empirical Software Engineering 27(2), 49 (2022). DOI 10.1007/s10664-021-10081-7. URL https://doi.org/10.1007/s10664-021-100 81-7. TLDR: A manual classification for SATDs in Dockerfile was conducted, finding that about 3.0% of the comments in Docker file are SATD, and SATDs were related to lowering maintainability, testing, and defects. 10. Bavota, G., Russo, B.: A large-scale empirical study on self-admitted technical debt. In: Proceedings of the 13th International Conference on Mining Software Repositories, pp. 315–326. ACM, Austin Texas (2016). DOI 10.1145/2901739.2901742. URL https: //dl.acm.org/doi/10.1145/2901739.2901742 11. Benjamini, Y., Hochberg, Y.: Controlling the False Discovery Rate: A Practical and Powerful Approach to Multiple Testing. Journal of the Royal Statistical Society: Series B (Methodological) 57(1), 289–300 (1995). DOI 10.1111/j.2517-6161.1995.tb02031.x. URL https://doi.org/10.1111/j.2517-6161.1995.tb02031.x. Remark: BenjaminiHochberg 12. Bernardo, J.H., da Costa, D.A., Kulesza, U., Treude, C.: The impact of a continuous integration service on the delivery time of merged pull requests. Empirical Software Engineering 28(4), 97 (2023). DOI 10.1007/s10664-023-10327-6. URL https://doi. org/10.1007/s10664-023-10327-6 13. Bhatia, A., https://orcid.org/0000-0002-3552-9460, View Profile, Khomh, F., https://orcid.org/0000-0002-5704-4173, View Profile, Adams, B., https://orcid.org/0000-0001-7213-4006, View Profile, Hassan, A.E., https://orcid.org/0000-0001-7749-5513, View Profile: An Empirical Study of SelfAdmitted Technical Debt in Machine Learning Software. ACM Transactions on Software Engineering and Methodology 0(ja). DOI 1 0 . 1 1 4 5 / 3 7 8 5 0 0 1. URL https://dl.acm.org/doi/10.1145/3785001 14. Bui, Q.C., Laukötter, M., Scandariato, R.: DockerCleaner: Automatic Repair of Security Smells in Dockerfiles. In: 2023 IEEE International Conference on Software Maintenance and Evolution (ICSME), pp. 160–170. IEEE, Bogotá, Colombia (2023). DOI 10.1109/ ICSME58846.2023.00026. URL https://ieeexplore.ieee.org/document/10336292/ 15. Cai, X., Liu, J., Liu, C., Bao, L., Yu, Y., Jiang, L.: Fortifying the Seams Between C/C++ and Rust: Characterizing Bugs in Interop Tools. ACM Trans. Softw. Eng. Methodol. (2026). DOI 10.1145/3795532. URL https://dl.acm.org/doi/10.1145/3795532. Just Accepted

Title Suppressed Due to Excessive Length

37

16. Chi, J., Wang, X., Huang, Y., Yu, L., Cui, D., Sun, J., Sun, J.: REACCEPT: Automated Co-evolution of Production and Test Code Based on Dynamic Validation and Large Language Models. Proc. ACM Softw. Eng. 2(ISSTA), ISSTA055:1234–ISSTA055:1256 (2025). DOI 10.1145/3728930. URL https://dl.acm.org/doi/10.1145/3728930 17. Cohen, J.: A Coefficient of Agreement for Nominal Scales. Educational and Psychological Measurement 20(1), 37–46 (1960). DOI 10.1177/001316446002000104. URL https://doi.org/10.1177/001316446002000104 18. Conroy, R.M.: What Hypotheses do “Nonparametric” Two-Group Tests Actually Test? The Stata Journal 12(2), 182–190 (2012). DOI 10.1177/1536867X1201200202. URL https://doi.org/10.1177/1536867X1201200202. Remark: Mann-Whitney 19. Cramér, H.: Mathematical Methods of Statistics. Princeton University Press (1946). Remark: Phi Coefficient Google-Books-ID: db1jwEACAAJ 20. Durieux, T.: Parfum: Detection and Automatic Repair of Dockerfile Smells (2023). DOI 10.48550/arXiv.2302.01707. URL http://arxiv.org/abs/2302.01707. ArXiv:2302.01707 [cs] 21. Durieux, T.: Empirical Study of the Docker Smells Impact on the Image Size. In: Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, ICSE ’24, pp. 1–12. Association for Computing Machinery, New York, NY, USA (2024). DOI 10.1145/3597503.3639143. URL https://dl.acm.org/doi/10.1145/3597503.363 9143 22. Fluri, B., Würsch, M., Giger, E., Gall, H.C.: Analyzing the co-evolution of comments and source code. Software Quality Journal 17(4), 367–394 (2009). DOI 10.1007/s1 1219-009-9075-x. URL http://link.springer.com/10.1007/s11219-009-9075-x. TLDR: An approach to associate comments with source code entities to track their co-evolution over multiple versions is presented and enables a quantitative assessment of the commenting process in a software system. 23. Gao, Z., Su, Y., Hu, X., Xia, X.: Automating TODO-missed Methods Detection and Patching (2024). DOI 10.1145/3652152. URL http://arxiv.org/abs/2405.06225. ArXiv:2405.06225 [cs] 24. Gao, Z., Xia, X., Lo, D., Grundy, J., Zimmermann, T.: Automating the removal of obsolete TODO comments. In: Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE 2021, pp. 218–229. Association for Computing Machinery, New York, NY, USA (2021). DOI 10.1145/3468264.3468553. URL https://dl.acm.org/doi/10.1145/3468264.3468553 25. Gu, H., Zhang, S., Huang, Q., Liao, Z., Liu, J., Lo, D.: Self-Admitted Technical Debts Identification: How Far Are We? In: 2024 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), pp. 804–815. IEEE, Rovaniemi, Finland (2024). DOI 10.1109/SANER60148.2024.00087. URL https: //ieeexplore.ieee.org/document/10589830/ 26. Guo, Z., Liu, S., Liu, J., Li, Y., Chen, L., Lu, H., Zhou, Y.: How Far Have We Progressed in Identifying Self-admitted Technical Debts? A Comprehensive Empirical Study. ACM Trans. Softw. Eng. Methodol. 30(4), 45:1–45:56 (2021). DOI 10.1145/3447247. URL https://dl.acm.org/doi/10.1145/3447247 27. Henkel, J., Bird, C., Lahiri, S.K., Reps, T.: Learning from, understanding, and supporting DevOps artifacts for docker. In: Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering, ICSE ’20, pp. 38–49. Association for Computing Machinery, New York, NY, USA (2020). DOI 10.1145/3377811.3380406. URL https://dl.acm.org/doi/10.1145/3377811.3380406 28. Huang, Q., Shihab, E., Xia, X., Lo, D., Li, S.: Identifying self-admitted technical debt in open source projects using text mining. Empirical Software Engineering 23(1), 418–451 (2018). DOI 10.1007/s10664-017-9522-4. URL http://link.springer.com/10.1007/ s10664-017-9522-4 29. Jiang, Y., Adams, B.: Co-evolution of Infrastructure and Source Code - An Empirical Study. In: 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories, pp. 45–55. IEEE, Florence, Italy (2015). DOI 10.1109/MSR.2015.12. URL http: //ieeexplore.ieee.org/document/7180066/ 30. Kalbfleisch, J.D., Prentice, R.L.: The Statistical Analysis of Failure Time Data. John Wiley & Sons (2002). Remark: Time-to Google-Books-ID: 38C DwAAQBAJ

38

Wei Minn

et al.

31. Kaplan, E.L., Meier, P.: Nonparametric Estimation from Incomplete Observations. Journal of the American Statistical Association 53(282), 457–481 (1958). DOI 10.1080/01621459.1958.10501452. URL https://www.tandfonline.com/doi/full /10.1080/01621459.1958.10501452. Remark: Kaplan-Meier 32. Ksontini, E., Abid, A., Khalsi, R., Kessentini, M.: DRMiner: A Tool For Identifying And Analyzing Refactorings In Dockerfile. In: Proceedings of the 21st International Conference on Mining Software Repositories, MSR ’24, pp. 584–594. Association for Computing Machinery, New York, NY, USA (2024). DOI 10.1145/3643991.3644921. URL https://dl.acm.org/doi/10.1145/3643991.3644921 33. Landis, J.R., Koch, G.G.: The Measurement of Observer Agreement for Categorical Data. Biometrics 33(1), 159–174 (1977). DOI 10.2307/2529310. URL https://www.js tor.org/stable/2529310 34. Levin, S., Yehudai, A.: The Co-Evolution of Test Maintenance and Code Maintenance through the lens of Fine-Grained Semantic Changes (2017). DOI 10.48550/arXiv.1709. 09029. URL http://arxiv.org/abs/1709.09029. Remark: ICSME’17 arXiv:1709.09029 [cs] 35. Li, K., Yuan, Y., Yu, H., Guo, T., Cao, S.: CoCoEvo: Co-Evolution of Programs and Test Cases to Enhance Code Generation (2025). DOI 10.48550/arXiv.2502.10802. URL http: //arxiv.org/abs/2502.10802. ArXiv:2502.10802 [cs] TLDR: CoEvo is introduced, a novel LLM-based co-evolution framework that simultaneously evolves programs and test cases and proposes optimization strategies such as a crossover rate scheduler to balance exploration and convergence, and a multi-objective optimization method for test case selection. 36. Li, Q., Yin, Z., Yang, Y., Li, C., Shen, Z., Ge, J., Zhong, W., Luo, B., Ng, V.: IMPACT: Identifying and Classifying Multiple Sourced and Categorized Self-Admitted Technical Debts. ACM Trans. Softw. Eng. Methodol. (2025). DOI 10.1145/3747180. URL https://dl.acm.org/doi/10.1145/3747180. Just Accepted 37. Li, Y., Soliman, M., Avgeriou, P.: Automatic identification of self-admitted technical debt from four different sources. Empirical Software Engineering 28(3), 65 (2023). DOI 10.1007/s10664-023-10297-9. URL https://doi.org/10.1007/s10664-023-10297-9 38. Liu, J., Huang, Q., Xia, X., Shihab, E., Lo, D., Li, S.: Is using deep learning frameworks free?: characterizing technical debt in deep learning frameworks. In: Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Software Engineering in Society, pp. 1–10. ACM, Seoul South Korea (2020). DOI 10.1145/3377815.3381377. URL https://dl.acm.org/doi/10.1145/3377815.3381377 39. Liu, J., Huang, Q., Xia, X., Shihab, E., Lo, D., Li, S.: An exploratory study on the introduction and removal of different types of technical debt in deep learning frameworks. Empirical Software Engineering 26(2), 16 (2021). DOI 10.1007/s10664-020-09917-5. URL http://link.springer.com/10.1007/s10664-020-09917-5 40. Lubsen, Z., Zaidman, A., Pinzger, M.: Using association rules to study the co-evolution of production &#x00026; test code. In: 2009 6th IEEE International Working Conference on Mining Software Repositories, pp. 151–154. IEEE, Vancouver, BC, Canada (2009). DOI 10.1109/MSR.2009.5069493. URL http://ieeexplore.ieee.org/docume nt/5069493/ 41. Maipradit, R., Treude, C., Hata, H., Matsumoto, K.: Wait for it: identifying “On-Hold” self-admitted technical debt. Empirical Software Engineering 25(5), 3770–3798 (2020). DOI 10.1007/s10664-020-09854-3. URL https://doi.org/10.1007/s10664-020-09854 -3 42. Maldonado, E.D.S., Abdalkareem, R., Shihab, E., Serebrenik, A.: An Empirical Study on the Removal of Self-Admitted Technical Debt. In: 2017 IEEE International Conference on Software Maintenance and Evolution (ICSME), pp. 238–248 (2017). DOI 10.1109/ ICSME.2017.8. URL https://ieeexplore.ieee.org/document/8094425 43. Maldonado, E.D.S., Shihab, E., Tsantalis, N.: Using Natural Language Processing to Automatically Detect Self-Admitted Technical Debt. IEEE Transactions on Software Engineering 43(11), 1044–1062 (2017). DOI 10.1109/TSE.2017.2654244. URL http: //ieeexplore.ieee.org/document/7820211/ 44. Marsavina, C., Romano, D., Zaidman, A.: Studying Fine-Grained Co-evolution Patterns of Production and Test Code. In: 2014 IEEE 14th International Working Conference

Title Suppressed Due to Excessive Length

39

on Source Code Analysis and Manipulation, pp. 195–204. IEEE, Victoria, BC, Canada (2014). DOI 10.1109/SCAM.2014.28. URL http://ieeexplore.ieee.org/document/6 975653/ 45. Martini, A., Bosch, J.: The Danger of Architectural Technical Debt: Contagious Debt and Vicious Circles. 2015 12th Working IEEE/IFIP Conference on Software Architecture pp. 1–10 (2015). DOI 10.1109/WICSA.2015.31. URL http://ieeexplore.ieee. org/document/7158498/. Conference Name: 2015 12th Working IEEE/IFIP Conference on Software Architecture (WICSA) ISBN: 9781479919222 46. Mastropaolo, A., Di Penta, M., Bavota, G.: Towards Automatically Addressing SelfAdmitted Technical Debt: How Far Are We? In: Proceedings of the 38th IEEE/ACM International Conference on Automated Software Engineering, ASE ’23, pp. 585–597. IEEE Press, Echternach, Luxembourg (2024). DOI 10.1109/ASE56229.2023.00103. URL https://dl.acm.org/doi/10.1109/ASE56229.2023.00103 47. Mcintosh, S., Adams, B., Nagappan, M., Hassan, A.E.: Mining Co-change Information to Understand When Build Changes Are Necessary. In: 2014 IEEE International Conference on Software Maintenance and Evolution, pp. 241–250. IEEE, Victoria, BC, Canada (2014). DOI 10.1109/ICSME.2014.46. URL http://ieeexplore.ieee.org/do cument/6976090/ 48. McIntosh, S., Adams, B., Nguyen, T.H., Kamei, Y., Hassan, A.E.: An empirical study of build maintenance effort. In: Proceedings of the 33rd International Conference on Software Engineering, pp. 141–150. ACM, Waikiki, Honolulu HI USA (2011). DOI 10.1145/1985793.1985813. URL https://dl.acm.org/doi/10.1145/1985793.1985813 49. Minn, W.: Dockerfile SATD-source co-evolution dataset. URL https://osf.io/sh5xd /overview?view_only=e06572d75ee54348807f3925c14b0371 50. Muse, B.A., Nagy, C., Cleve, A., Khomh, F., Antoniol, G.: FIXME: synchronize with database! An empirical study of data access self-admitted technical debt. Empirical Software Engineering 27(6), 130 (2022). DOI 10.1007/s10664- 022- 10119-4. URL https://doi.org/10.1007/s10664-022-10119-4 51. Openja, M., Khomh, F., Foundjem, A., Jiang, Z.M.J., Abidi, M., Hassan, A.E.: An Empirical Study of Testing Machine Learning in the Wild. ACM Trans. Softw. Eng. Methodol. 34(1), 7:1–7:63 (2024). DOI 10.1145/3680463. URL https://dl.acm.org/d oi/10.1145/3680463 52. Pearson, K.: VII. Note on regression and inheritance in the case of two parents. Proceedings of the Royal Society of London 58(347-352), 240–242 (1895). DOI 10.1098/rspl.1895.0041. URL https://royalsocietypublishing.org/rspl/articl e/58/347-352/240/43470/VII-Note-on-regression-and-inheritance-in-the-case. Remark: Pearson Correlation 53. Penfound, K., Dagger, Nickerson, C., Kubeshop: Production-Grade Container Orchestration. URL https://kubernetes.io/ 54. Peto, R., Peto, J.: Asymptotically Efficient Rank Invariant Test Procedures. Journal of the Royal Statistical Society. Series A (General) 135(2), 185 (1972). DOI 10.2307/ 2344317. URL https://www.jstor.org/stable/10.2307/2344317?origin=crossref. Remark: Log-Rank 55. Potdar, A., Shihab, E.: An Exploratory Study on Self-Admitted Technical Debt. In: 2014 IEEE International Conference on Software Maintenance and Evolution, pp. 91– 100. IEEE, Victoria, BC, Canada (2014). DOI 10.1109/ICSME.2014.31. URL http: //ieeexplore.ieee.org/document/6976075/ 56. Preston-Werner, T.: Semantic Versioning 2.0.0. URL https://semver.org/ 57. Ren, H., Li, Y., Chen, L.: An Empirical Study on Critical Blocking Bugs. In: Proceedings of the 28th International Conference on Program Comprehension, pp. 72–82. ACM, Seoul Republic of Korea (2020). DOI 10.1145/3387904.3389267. URL https://dl.acm .org/doi/10.1145/3387904.3389267 58. Ren, X., Xing, Z., Xia, X., Lo, D., Wang, X., Grundy, J.: Neural Network-based Detection of Self-Admitted Technical Debt: From Performance to Explainability. ACM Trans. Softw. Eng. Methodol. 28(3), 15:1–15:45 (2019). DOI 10.1145/3324916. URL https://dl.acm.org/doi/10.1145/3324916 59. Rong, G., Yu, Y., Liu, S., Tan, X., Zhang, T., Shen, H., Hu, J.: Code Comment Inconsistency Detection and Rectification Using a Large Language Model. In: Proceedings of

40

Wei Minn

et al.

the IEEE/ACM 47th International Conference on Software Engineering, ICSE ’25, pp. 1832–1843. IEEE Press, Ottawa, Ontario, Canada (2025). DOI 10.1109/ICSE55347.20 25.00035. URL https://dl.acm.org/doi/10.1109/ICSE55347.2025.00035 60. Rosa, G., Scalabrino, S., Robles, G., Oliveto, R.: Not all Dockerfile Smells are the Same: An Empirical Evaluation of Hadolint Writing Practices by Experts. In: Proceedings of the 21st International Conference on Mining Software Repositories, pp. 231–241. ACM, Lisbon Portugal (2024). DOI 10.1145/3643991.3644905. URL https://dl.acm.org/d oi/10.1145/3643991.3644905 61. Rosa, G., Zappone, F., Scalabrino, S., Oliveto, R.: Fixing Dockerfile smells: an empirical study. Empirical Software Engineering 29(5), 108 (2024). DOI 10.1007/s10664-024-1 0471-7. URL https://doi.org/10.1007/s10664-024-10471-7 62. Russo, B., Melegati, J., Mock, M.: Leveraging multi-task learning to improve the detection of SATD and vulnerability. In: 2025 IEEE/ACM 33rd International Conference on Program Comprehension (ICPC), pp. 01–12 (2025). DOI 10.1109/ICPC66645.2025 .00017. URL http://arxiv.org/abs/2501.15934. ArXiv:2501.15934 [cs] 63. Shabani, T., Nashid, N., Alian, P., Mesbah, A.: Dockerfile Flakiness: Characterization and Repair (2025). DOI 10.48550/arXiv.2408.05379. URL http://arxiv.org/abs/24 08.05379. ArXiv:2408.05379 [cs] 64. Sheikhaei, M.S., Tian, Y., Wang, S., Xu, B.: An Empirical Study on the Effectiveness of Large Language Models for SATD Identification and Classification (2024). DOI 10 .48550/arXiv.2405.06806. URL http://arxiv.org/abs/2405.06806. ArXiv:2405.06806 [cs] 65. Shimmi, S., Rahimi, M.: Leveraging code-test co-evolution patterns for automated test case recommendation. In: Proceedings of the 3rd ACM/IEEE International Conference on Automation of Software Test, AST ’22, pp. 65–76. Association for Computing Machinery, New York, NY, USA (2022). DOI 10.1145/3524481.3527222. URL https://dl.acm.org/doi/10.1145/3524481.3527222 66. Sun, W., Yan, M., Liu, Z., Xia, X., Lei, Y., Lo, D.: Revisiting the Identification of the Co-evolution of Production and Test Code. ACM Trans. Softw. Eng. Methodol. 32(6), 152:1–152:37 (2023). DOI 10.1145/3607183. URL https://dl.acm.org/doi/10.1145 /3607183. TLDR: An empirical study investigating the reasons for test code updates occurring after the associated production code changes, and revealing the pervasive existence of noise in the production-test co-evolution samples identified based on the aforementioned assumption by existing works are presented. 67. Valdivia Garcia, H., Shihab, E.: Characterizing and predicting blocking bugs in open source projects. In: Proceedings of the 11th Working Conference on Mining Software Repositories, pp. 72–81. ACM, Hyderabad India (2014). DOI 10.1145/2597073.2597099. URL https://dl.acm.org/doi/10.1145/2597073.2597099 68. Vidacs, L., Pinzger, M.: Co-evolution analysis of production and test code by learning association rules of changes. In: 2018 IEEE Workshop on Machine Learning Techniques for Software Quality Evaluation (MaLTeSQuE), pp. 31–36. IEEE, Campobasso (2018). DOI 10.1109/MALTESQUE.2018.8368456. URL https://ieeexplore.ieee.org/docu ment/8368456/ 69. Wang, S., Wen, M., Liu, Y., Wang, Y., Wu, R.: Understanding and Facilitating the Co-Evolution of Production and Test Code. In: 2021 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), pp. 272–283. IEEE, Honolulu, HI, USA (2021). DOI 10.1109/SANER50967.2021.00033. URL https://ieeexplore.ieee.org/document/9425945/ 70. Watanabe, M., Li, H., Kashiwa, Y., Reid, B., Iida, H., Hassan, A.E.: On the Use of Agentic Coding: An Empirical Study of Pull Requests on GitHub. ACM Trans. Softw. Eng. Methodol. (2026). DOI 10.1145/3798166. URL https://dl.acm.org/doi/10.11 45/3798166. Just Accepted 71. Wu, Y., Zhang, Y., Wang, T., Wang, H.: Characterizing the Occurrence of Dockerfile Smells in Open-Source Software: An Empirical Study. IEEE Access 8, 34127–34139 (2020). DOI 10.1109/ACCESS.2020.2973750. URL https://ieeexplore.ieee.org/do cument/8998208/ 72. Wu, Y., Zhang, Y., Wang, T., Wang, H.: Dockerfile Changes in Practice: A Large-Scale Empirical Study of 4,110 Projects on GitHub. In: 2020 27th Asia-Pacific Software

Title Suppressed Due to Excessive Length

41

Engineering Conference (APSEC), pp. 247–256 (2020). DOI 10.1109/APSEC51365.2 020.00033. URL https://ieeexplore.ieee.org/document/9359307. ISSN: 2640-0715 73. Xiao, T., Wang, D., McIntosh, S., Hata, H., Kula, R.G., Ishio, T., Matsumoto, K.: Characterizing and Mitigating Self-Admitted Technical Debt in Build Systems. IEEE Transactions on Software Engineering 48(10), 4214–4228 (2022). DOI 10.1109/TSE. 2021.3115772. URL https://ieeexplore.ieee.org/document/9551792/. TLDR: A qualitative analysis of 500 SATD comments in the Maven build system of 291 projects, which characterized SATD by location and rationale (reason and purpose), shows that limitations in tools and libraries and complexities of dependency management are the most frequent causes. 74. Zaidman, A., Van Rompaey, B., Demeyer, S., Van Deursen, A.: Mining Software Repositories to Study Co-Evolution of Production & Test Code. In: 2008 1st International Conference on Software Testing, Verification, and Validation, pp. 220–229. IEEE, Lillehammer (2008). DOI 10.1109/ICST.2008.47. URL https://ieeexplore.ieee.org/do cument/4539549/ 75. Zaidman, A., Van Rompaey, B., van Deursen, A., Demeyer, S.: Studying the co-evolution of production and test code in open source and industrial developer test processes through repository mining. Empirical Software Engineering 16(3), 325–364 (2011). DOI 10.1007/s10664-010-9143-7. URL https://doi.org/10.1007/s10664-010-9143-7. TLDR: This paper proposes three views (realized by a tool called TeMo) that combine information from a software project’s versioning system, the size of the various artifacts and the test coverage reports that could recognize different co-evolution scenarios and make relevant observations for both developers as well as test engineers. 76. Zampetti, F., Serebrenik, A., Di Penta, M.: Was self-admitted technical debt removal a real removal?: an in-depth perspective. In: Proceedings of the 15th International Conference on Mining Software Repositories, pp. 526–536. ACM, Gothenburg Sweden (2018). DOI 10.1145/3196398.3196423. URL https://dl.acm.org/doi/10.1145/31963 98.3196423 77. Zhou, Y., Zhan, W., Li, Z., Han, T., Chen, T., Gall, H.: DRIVE: Dockerfile Rule Mining and Violation Detection. ACM Trans. Softw. Eng. Methodol. 33(2), 30:1–30:23 (2023). DOI 10.1145/3617173. URL https://dl.acm.org/doi/10.1145/3617173

Related documents

• The Complexity Kink: A Prompt-Side Structural Complexity Index for Code-Generation Reliability#978496
• Semantic Layer Induction from Raw Telemetry via Hierarchical LLM and RAG Abstraction#978497
• The Output-Space Hypothesis: Enumerative Equivalence Checking for Tensor Programs#978498
• DeltaSelect: Affordable A/B Testing for Coding Agents#978499
• Code-as-Auditor: Executable Compliance Reasoning via Regulation-to-Code#978500