Docker-based software containerization has recently emerged as the de facto standard for delivering reusable software artifacts. With a plethora of publicly available Docker images, developers can easily build and deploy their applications, resulting in an industry-wide shift toward containerized solutions. Container-based projects, on the other hand, include several components, such as the Docker and Docker-compose files, as well as several dependencies in the source code, combining different containers and simplifying interactions with them. Like any other complex system, Container-based projects are prone to multiple quality and technical debt issues relating to several artifacts, namely, Docker and Docker-compose files. In a previous work, we conducted the first foundational study on refactorings, i.e., structural changes, while preserving the behavior applied in open-source Docker projects and the technical debt issues they alleviate. The findings suggest that developers refactor these Docker projects for a variety of reasons specific to the configuration, combination, and execution of containers. We defined different best practices and introduced 24 new Dockerspecific refactorings and 7 technical debt categories. In this paper, we extend our prior study by expanding the dataset nearly sixfold, from 68 to 443 projects, and refining our selection methodology. These changes reveal 17 additional Docker-specific refactorings, bringing our catalog to 41 distinct mechanisms, and introduce two new technical-debt categories, for a total of nine. We also derive 48 role-aware (Dev vs. Ops) recommendations and quantify the operational impact of refactorings on release-image size and build time, analyzing size–time trade-offs.These extensions not only expand the known landscape of Docker-specific quality issues but also provide deeper insights into how practitioners manage and alleviate technical debt in container environments.

In modern software engineering, build systems play the crucial role of facilitating the conversion of source code into software artifacts. Recent research has explored high-level causes of build failures, but has largely overlooked the structural properties of build files. Akin to source code, build systems face technical debt challenges that hinder maintenance and optimization. While refactoring is often seen as a key tool for addressing technical debt in source code, there is a significant research gap regarding the specific refactoring changes developers apply to build code and whether these refactorings effectively address technical debt.In this paper, we address this gap by examining refactorings applied to build scripts in open-source projects, covering the widely used build systems of Gradle, Ant, and Maven. Additionally, we investigate whether these refactorings are used to tackle technical debts in build systems. Our analysis was conducted on 725 examined build-file-related commits. We identified 24 build-related refactorings, which we divided into 6 main categories. These refactorings are organized into the first empirically derived taxonomy of build system refactorings. Furthermore, we investigate how developers employ these refactoring types to address technical debts via a manual commitanalysis and a developer survey. In this context, we identified 5 technical debts addressed by these refactorings and discussed their correlation with the different refactorings. Finally, we introduce BuildRefMiner, an LLM-powered tool leveraging GPT40 to automate the detection of refactorings within build systems. We evaluated its performance and found that it achieves an F1 score of 0.76 across all build systems.This study will serve as a foundational building block for guiding future research and practice in the maintenance and optimization of build systems. BuildRefMiner and the replication package for this study are available at [1]

Docker, the industry standard for packaging and deploying applications, leverages Infrastructure as Code (IaC) principles to facilitate the creation of images through Dockerfiles. However, maintaining Dockerfiles presents significant challenges. Refactoring, in particular, is often a manual and complex process. This paper explores the utility and practicality of automating Dockerfile refactoring using 600 Dockerfiles from 358 opensource projects. Our study reveals that Dockerfile image size and build duration tend to increase as projects evolve, with developers often postponing refactoring efforts until later stages in the development cycle. This trend motivates the automation of refactoring. To achieve this, we leverage In Context Learning (ICL) along with a score-based demonstration selection strategy. Our approach leads to an average reduction of 32% in image size and a 6% decrease in build duration, with improvements in understandability and maintainability observed in 77% and 91% of cases, respectively. Additionally, our analysis shows that automated refactoring reduces Dockerfile image size by 2x compared to manual refactoring and 10x compared to smellfixing tools like PARFUM. This work establishes a foundation for automating Dockerfile refactoring, indicating that such automation could become a standard practice within CI/CD pipelines to enhance Dockerfile quality throughout every step of the software development lifecycle.

Software containerization using Docker has recently become the de facto standard for delivering reusable software artifacts. Integral to Docker's functionality are Dockerfiles, which serve as scripts that define the layers and components to be incorporated within a container. Although these files serve as the bedrock of container creation, their maintenance presents intricate challenges. Specifically, the task of Dockerfile refactoring is compounded by its inherent complexity. Although the importance of refactoring inside Docker ecosystems is apparent, detecting it remains challenging. Developers usually avoid documenting their refactoring efforts, often combining them with other changes.

Containerization technology, such as Docker, is gaining in popularity in newly established software-defined vehicle architectures (SDVA). However, executing those containers can quickly become computationally expensive in constrained environments, given the limited CPU, memory, and energy resources in the Electric Control Units (ECU) of SDVA. Consequently, the efficient management of these containers is crucial for enabling the on-demand usage of the applications in the vehicle based on the available resources while considering several constraints and priorities, including failure tolerance, security, safety, and comfort. In this article, we propose a dynamic software container management approach for constrained environments such as embedded devices/ECUs in SDVA within smart cars. To address the conflicting objectives and constraints within the vehicle, we design a novel search-based approach based on multi-objective optimization. This approach facilitates the allocation, movement, or suspension of containers between ECUs in the cluster. Collaborating with our industry partner, Ford Motor Company, we evaluate our approach using different real-world software-defined scenarios. These scenarios involve using heterogeneous clusters of ECU devices in vehicles based on real-world software containers and use-case studies from the automotive industry. The experimental results demonstrate that our scheduler outperforms existing scheduling algorithms, including the default Docker scheduler -Spread- commonly used in automotive applications. Our proposed scheduler exhibits superior performance in terms of energy and resource cost efficiency. Specifically, it achieves a 35% reduction in energy consumption in power-saving mode compared to the scheduler employed by Ford Motor Company. Additionally, our scheduler effectively distributes workload among the ECUs in the cluster, minimizing resource usage, and dynamically adjusts to the real-time requirements and constraints of the car environment. This work will serve as a fundamental building block in the automotive industry to efficiently manage software containers in smart vehicles, considering constraints and priorities in the real world.

The lack of interpretability, explainability and transparency makes deep learning models untrusted to perform reliably for making critical decisions. Despite their evaluation against disturbances including geometric transformations, occlusion and convolutional noises in the case of DNN-based image classifiers, the evaluation of contour classifiers has only been studied against rigid displacements (rotation and translation). In this paper, we introduce ContourCertif: a new system to certify deep contour classifiers against convolutional attacks. We use the abstract interpretation theory in order to formulate the Lower and Upper Bounds with abstract intervals to support other classes of advanced attacks including filtering.