# Evaluating the Energy Profile of Tasks Managed by Build Automation Tools in Continuous Integration Workflows: The Case of Apache Maven and Gradle

Sérgio Queiroz de Medeiros, Romain Lefeuvre, Benoit Combemale, Quentin Perez

► To cite this version:

Sérgio Queiroz de Medeiros, Romain Lefeuvre, Benoit Combemale, Quentin Perez. Evaluating the Energy Profile of Tasks Managed by Build Automation Tools in Continuous Integration Workflows: The Case of Apache Maven and Gradle. ICT4S 2025 - International Conference on Information and Communications Technology for Sustainability, Jun 2025, Dublin, Ireland. pp.1-11, 10.1109/ICT4S68164.2025.00011. hal-05090865v2

HAL Id: hal-05090865

https://hal.science/hal-05090865v2

Submitted on 16 Jun 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Evaluating the Energy Profile of Tasks Managed by Build Automation Tools in Continuous Integration Workflows: The Case of Apache Maven and Gradle

Sérgio Queiroz de Medeiros

Federal University of Rio Grande do Norte

Natal, Brazil

sergio.medeiros@ufrn.br

Romain Lefeuvre*,

Benoît Combemale†

Univ. Rennes, IRISA, Inria

Rennes, France

romain.lefeuvre@irisa.fr*

benoit.combemale@irisa.fr†

Quentin Perez

INSA Rennes, Univ. Rennes, IRISA, Inria

Rennes, France

quentin.perez@irisa.fr

**Abstract**—There is a growing interest in the energy impact of computing-related activities, which is expected to increase in the coming years. Modern software development usually relies on Continuous Integration (CI) to support short iterations, where code changes are integrated on a daily basis. The implementation of CI workflows usually relies on build automation tools, (e.g. Apache Maven or Gradle), to automate several activities such as testing or compiling. The large adoption of CI practices raises concerns about the impact of such tasks usually run on cloud environments, where the underlying hardware and its associated energy consumption remain intangible to developers. To better understand the energy footprint related to modern software development, it is essential to investigate the energy profile of the tasks managed by Apache Maven and Gradle. To achieve such goal, we performed a large-scale study with 1167 CI workflows implemented through GitHub Actions and mined from popular Java projects hosted on GitHub. After executing them locally, in a controlled environment, we analyzed in depth the energy profile of 183 355 tasks managed by Apache Maven and Gradle. These tasks represent a quarter of the total energy consumption associated with the CI workflows. We found that tasks from workflows of small-sized projects do not necessarily consume less energy than tasks from workflows of medium-sized and large-sized projects. We also found that testing-related tasks consume the most energy, and that the larger the project, the higher the percentage of energy consumption related to testing. Moreover, tasks of different categories have a different profile regarding energy consumption per task and per unit of time.

**Index Terms**—build automation tools, energy profile, workflow, apache maven, gradle, continuous integration, java

## I. INTRODUCTION

Currently, there is a greater interest in the energy consumption of computer-related activities [1]–[4]. In 2015, the Information and Communication Technology (ICT) sector was responsible for around 4–6% of the global energy demand, and this amount can be higher than 20% by 2030 according to some projections [5], [6]. In Ireland, for example, the energy consumption associated with data centers increased from 5% in 2015 to 21% in 2023, which is more than the total energy consumption of urban households [7].

Modern software life-cycles are usually based on short iterations, where new codes are integrated into a shared

code base by diverse actors on a daily basis, reducing the time between development and deployment. These gains have been made possible by the adoption of continuous integration practices [8], [9], to ensure the reliability of frequent code integration through the automation of different activities of the software lifecycle. A Continuous Integration (CI) workflow is an automated process, composed of jobs and steps, describing the tasks that will be executed. For example, tasks related to static analysis, build, or test can be automatically triggered by CI tools before integrating code changes into a remote repository. In this way, a modification in the codebase that fails during build or test might be rejected before integration into the mainline. CI workflows commonly trigger build automation tools like Apache Maven and Gradle that execute such kinds of tasks. In the remainder of the paper, we will use the term *task* to refer to the build automation tool task.

Usually, CI workflows, such as those implemented through GitHub Actions, run in data centers and therefore contribute to the energy impact associated with them. The increasing accessibility and adoption of these practices raise concerns about the associated impacts in terms of energy consumption [10], especially since such tools rely on remote resources that remain intangible to users. Given this scenario, to better understand the energy consumption related to software development, it is essential to investigate the energy consumption of tasks managed by build automation tools. Moreover, studying the energy consumption of CI workflows composed of jobs related to build automation tools is also particularly relevant for developers who routinely execute such tasks locally, on their workstation. We then carried out such an investigation by conducting a large-scale analysis of the energy consumption profile of tasks managed by Apache Maven and Gradle in popular Java repositories hosted on GitHub. As usual, we considered that a project is popular based on its number of stars [11].

We used a controlled and reproducible environment, where we executed a continuous integration workflow, also known as workflow, locally on a regular server to measure its en-
ergy consumption. 3170 workflows had been executed from 1168 Java repositories with at least 100 stars, and measured their energy consumption by instrumenting our measurement machine with SmartWatts [12], a software power meter. Our analysis then focused on 1167 workflows that used Apache Maven or Gradle to manage 183 355 tasks (e.g., run unit tests, generate documentation). We categorized workflows according to the size of their respective Java project and the types of tasks executed by Gradle or Maven, such as Unit Testing, Documentation, Linting, etc. Our goal was to investigate the following research questions (RQs):

*   **RQ1. How is the overall energy consumption associated with Maven/Gradle tasks?** A quarter of the energy consumption of a workflow is due to tasks managed by Maven and Gradle. Tasks in small-sized projects tend to consume more energy than tasks from workflows of large-sized projects, although this difference is negligible.

*   **RQ2. How is the energy consumption profile by category of Maven/Gradle task?** Testing-related tasks are the ones that consume more energy. They represent 47% of the overall energy consumption associated with Maven tasks, and 36% of the energy consumed by Gradle tasks. The larger the project, the higher the percentage of energy consumption related to testing. Moreover, tasks of different categories have a different profile regarding energy consumption per task and per unit of time.

This study contributes to a better understanding of the energy consumption in a CI workflow and it may help developers to adjust the tasks executed in a workflow in order to diminish their corresponding energy impact.

**Paper organization.** In the next section, we detail our research methodology, then in Section III we present our results and discuss them. Section IV addresses the threats to validity, while Section V discusses the related work. Finally, in Section VI we present our conclusions.

## II. RESEARCH METHODOLOGY

In this section, we discuss our research methodology. Section II-A talks about our approach to measure the energy consumption of several activities in a CI workflow, while Section II-B explains the selection of popular Java projects from GitHub and the identification and classification of Maven and Gradle tasks. A reproduction package, containing the analysis of workflows executions, is available online<fnref n="1" />.

### A. *Measuring Energy Consumption in a CI Pipeline*

Monitoring energy consumption was challenging for obtaining reliable and interpretable measurements at the correct level for software engineering researchers. One of the ways is to use the Running Average Power Limit (RAPL) integrated in Intel CPUs since 2012 [13], [14]. RAPL consists of a set of counters integrated directly into the CPU, offering a high sampling rate with energy values measured every 1 ms (1000 Hz) [15],

[16]. It gives detailed information on energy consumption and allows for the restriction of power usage across various levels named power domains including: the entire CPU socket, all CPU cores, the integrated graphics processing unit, dynamic random-access memory, and the entire System on Chip. While RAPL offers a solution for monitoring energy consumption at the CPU level, isolating the power consumption of a specific process or program remains challenging due to the global nature of CPU energy measurement.

To address the limitations of RAPL, in 2019 Fieni et al. [12] developed the PowerAPI toolkit and the tool named SmartWatts. SmartWatts is a part of the PowerAPI toolkit<fnref n="2" />, which enables the deployment of software power meters. SmartWatts is a software power meter that allows for the isolation of energy consumption in Docker containers and processes through Control Groups (CGroups) [17]. Control groups enable the limitation, monitoring, and isolation of processes running on Linux servers. A specific sensor (HWPC-Sensor) within PowerAPI collects RAPL and performance values (such as CPU usage and last-level cache miss) from the RAPL interface and CGroups. Subsequently, the SmartWatts power meter uses regression based on these values to calculate power in watts at a given time t. As demonstrated by Fieni et al. [12] and Jay et al. [15] SmartWatts offers a reliable sampling frequency of 2 Hz (500ms). Despite the advanced features offered by SmartWatts, tracking the energy consumption of a CI workflow is still a complex task. CI workflows operate through a specialized program known as a runner, which orchestrates the execution of the workflow. The runner parses the workflow descriptor file and manages the execution of each step, which may involve multiple tools. Consequently, to accurately monitor energy consumption, it is essential to track not only the runner but also all the processes it initiates. Furthermore, the workflow process often includes the execution of containers for build steps, making it crucial for monitoring tools to capture the energy consumption of all subprocesses and containers activated by the runner.

In our experimentation, we measure only the CPU energy consumed by a CI run as an indicator of the impact of a CI run. The use of SmartWatts, which is a software power meter, aims to make our methodology easily reusable in industrial contexts requiring non-invasive measurement. Focusing only on CPU energy is due to practical reasons: SmartWatts does not support assessing RAM energy consumption on all devices, including our own. Measuring disk consumption at a fine-grained level requires high-quality hardware sensors, and this method is unable to distinguish the consumption linked to a specific workflow subprocess. We use software-based solutions to assess energy consumption, with the aim of making our methodology easily reusable in industrial contexts that require non-invasive measurement. GitHub provides its own cloud-based Continuous Integration service: GitHub Actions. This service allows the execution of workflows through a runner in the cloud. However, GitHub Actions also offers the option to

<footnote n="1">¹https://archive.softwareheritage.org/browse/revision/17b995c36af45da00e1ad5bc48f3ad460ef7abc6/?origin_url=https://github.com/RomainLefeuvre/ICT4S_2025</footnote>

<footnote n="2">²https://powerapi.org/</footnote>
run a runner locally on a dedicated machine, thus providing
the possibility to monitor its energy consumption.

Fig. 1 provides an overview of the process for extracting energy consumption using GitHub, GitHub Actions runner, and SmartWatts. The process is composed of five phases described below.

**Phase ①:** This phase entails forking the targeted GitHub project. We realize a fork to obtain the rights to modify and execute workflow files. The modification concerns the introduction of *repositoryDispatch*<fnref n="3" /> trigger. We are adding this trigger because GitHub doesn't natively offer an option for triggering a workflow via the GitHub REST API<fnref n="4" />. This trigger enables workflow activation via GitHub's API and schedules the execution to our local runner machine rather than GitHub's cloud. These modifications allow us to automatically run and monitor the workflows of our dataset.

**Phase ②:** Secondarily, the workflow is triggered using the GitHub REST API to run it locally on a dedicated measurement machine. Our measurement machine, a Dell Precision Tower 5810, is equipped with an Intel Xeon E5-1603v4 at 2.8 GHz, 8 GB of DDR4 at 2400 MHz, and Xubuntu 22.04.2 LTS with kernel version 6.2.0-35-generic. This machine used a specific software sensor from PowerAPI (HWPC-Sensor) that collects metrics used by SmartWatts. The local runner is added to a Control Group, enabling the capture of metrics by the sensor. The runner is added to the Control Group with a “sticky” option, ensuring that each subprocess launched by the runner stays within the Control Group. Each workflow is executed sequentially to maintain consistency in measurements. Since each measurement is time-stamped, it would be impossible to maintain temporal consistency with a parallel execution. This setup allows gathering metrics specific to the GitHub runner and associated tools.

**Phase ③:** In the third phase, the runner created for the workflow is deleted and formatted logs from GitHub Actions are retrieved using the GitHub REST API<fnref n="5" />. The deletion of GitHub Actions runner prevents the creation of multiple local runners and avoids confusion during power measurement.

**Phase ④:** In the fourth phase, SmartWatts computes the power values from the raw metrics collected by the sensor, resulting in a CSV file that includes timestamps and their associated power values. By crossing the timestamped log files with this CSV file, it is possible to link power values to their respective logs. This alignment is necessary to identify the energy measurements related to the execution of a workflow. The workflow log records both the start and end times of workflow jobs and steps, while measurement values are captured every 500 ms. The alignment process involves matching measurement values to the workflow's execution duration

using timestamps. The final output is a file that includes
 workflow extraction logs, paired with their corresponding
 energy consumption values.

**Phase ⑤:** In Section II-B3 we discuss the fifth phase, where we process the log generated during the execution of the workflows. We filter the workflows containing at least one job related to Maven or Gradle. For those workflows, the energy consumption associated with the execution of Maven or Gradle tasks is then extracted by analyzing the log. Finally, a statistical analysis is presented in Section III.

## B. Data Acquisition and Classification

1) *Selecting Popular Java Projects:* The target population for this study is composed of open source Java projects publicly accessible, that use a CI workflow as well as a build automation tool. Since studying the entire population is not feasible, we extracted a sample of repositories from GitHub, a hosting platform with one of the most used CI workflow systems called GitHub Actions [18]. Using the GitHub API we selected repositories based on their popularity, where we considered as popular a project with at least 100 stars. We therefore collected projects written in Java, with a minimum of 100 stars, having at least one GitHub Actions workflow. Afterward, in phase 5 (1) we filtered workflows using Maven or Gradle as their build automation tool. We target Java projects because it is one of the most popular languages⁶⁷. Moreover, we have an expertise in Java programming and in the build automation tool (Maven/Gradle) used in the Java environment. This allows us to conduct in-depth energy consumption analyses of this ecosystem.

This resulted in 1168 Java repositories containing 3170 workflows.

2) *Classifying Projects According to the Size of Project:* To investigate the effect of project size on the energy consumption of a workflow, we computed the Lines of Code (LoC) of the corresponding project and assigned a project size (small, medium, or large) according to this metric.

We used CLOC<fnref n="8" /> to count the lines of code associated with each file in each project. When calculating the total LoC associated with a project, we did not consider the LoC reported by CLOC in the case of the following file types: XML, JSON, Text, CSV, HTML, Markdown, Properties, SVG, CSS, XSD and AsciiDoc.

Given the total LoC of a project, we classified its size as *small*, *medium* or *large* following the same approach used by other works [19], [20]. This method categorizes projects as follows: small projects contain up to 10 000 lines of code (LoC), medium projects range from over 10 000 to 100 000 LoC, and large projects exceed 100 000 LoC. Due to the inability to gather LoC data for one project, we discarded 5 workflows. This reduced our set of workflows from 3170 to 3165.

<footnote n="3">³https://docs.github.com/fr/webhooks/webhook-events-and-payloads#repositoryDispatch</footnote>

<footnote n="4">⁴https://docs.github.com/en/rest/actions/workflows?apiVersion=2022-11-28#create-a-workflow-dispatch-event</footnote>

<footnote n="5">⁵https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2022-11-28#download-workflow-run-logs</footnote>

<footnote n="6">⁶https://www.tiobe.com/tiobe-index/</footnote>

<footnote n="7">⁷https://spectrum.ieee.org/top-programming-languages-2024</footnote>

<footnote n="8">⁸https://github.com/AIDanial/cloc</footnote>
<figure><img src="image_2.png" /><figcaption>Fig. 1: Process for extracting, measuring and saving the energy consumption of CI workflows.</figcaption></figure>

3) *Identifying Workflows with Maven/Gradle Tasks:* After executing our initial data set of 3165 workflows, we checked the logs to identify the workflows that used Maven or Gradle to handle tasks (Phase V in Fig. 1). During this process, we also discarded 457 workflows whose associated energy measurements had some issue, for example, a null energy consumption associated with a task, not necessarily a Maven or Gradle one, that ran for several seconds. Some workflows have null energy consumption due to measurement issues with our setup.

In the case of Maven, we checked the execution of some Maven plugin (e.g., Surefire, Javadoc), and in the case of Gradle we checked the execution of some task (e.g., compileJava, install). As mentioned previously, we instrumented the code that executes the workflows in order to log these events. We also log information about errors during the execution of tasks.

In general, we identified 1167 workflows associated to 184 535 Maven or Gradle tasks, where 183 355 were successfully executed, and 1180 had some errors during execution. There were several causes for these errors, such as configuration issues (e.g., an invalid path), and failed tests. In our analysis, we considered only the 183 355 Maven/Gradle tasks that executed without errors. From this number of tasks, 137 333 are Maven-related tasks and 46 022 are Gradle-related ones. We could then identify 740 workflows with tasks managed by Maven and 428 with tasks managed by Gradle.

There was only one workflow, with tasks managed by both Maven and Gradle. In the following discussion, we assume that these two sets are disjoint when performing our computations and our further analysis.

4) *Classifying Maven/Gradle Tasks:* After matching a log entry corresponding to a Maven or Gradle task, we need to determine what kind of task it is. In the following, we discuss the classification strategy that we used for each build automation tool.

In the case of Maven, as the log entry associated with the task has the information about the associated Maven plugin, we can match each task with its associated plugin (e.g. failsafe, license), or even with a specific

goal of a plugin (e.g., the goal *testCompile* from the *compiler* plugin). Based on this approach, it was possible to match more than 95% of Maven tasks with a specific plugin from our list with about 70 options.

In the case of Gradle, it is harder to classify tasks because the log entries only have task names, which are not standard and may vary a lot. These names may be informative and give a good clue about the task's purpose (e.g. *compileTestScala*), or may not be so informative (e.g., *randomizationInfo*). Taking our list of Maven plugins as a starting point, we try to identify the corresponding Gradle tasks. As there is no standard nomenclature (e.g., a task related to the *checkstyle* plugin may have names such as *Checkstyle*, *checkstyleMain* and *checkstyleRoot*), we needed to craft several regular expression patterns to match the Gradle tasks that seem associated with a plugin. Some tasks such as *checkstyleTest* and *findbugsIntegrationTest* could be associated with more than one plugin. In such cases, we did not classify these tasks as testing-related tasks. Following this approach, task *checkstyleTest* is associated with the plugin *checkstyle* and task *findbugsIntegrationTest* with the plugin *findbugs*. We tried to be as conservative as possible to avoid misclassifying a task. Following this approach, we were able to associate around 70% of Gradle tasks with a more precise class.

5) *Grouping Tasks by Category:* As we have more than 70 different types of Maven or Gradle tasks, to better understand the energy profile of workflows that use these build manager tools, we decided to group tasks by category. We created categories to represent groups of tasks that together consume around 5% of the energy consumption related to Maven/Gradle in the case of a given project size (e.g. small, medium, or large). Table I shows such categories and a list of some associated plugins in the case of Maven. For some categories, we also show their abbreviated name in parentheses. We used the same categories to classify both Maven and Gradle tasks, since most of the Gradle tasks were associated with a corresponding Maven plugin. In the following, we discuss a few categories.
<table><caption>TABLE I: Categories of Maven Tasks</caption><thead><tr><td>Category</td><td>Associated Maven Plugins</td></tr></thead><tbody><tr><td>Integration Testing (Int Test)</td><td>archetype, failsafe</td></tr><tr><td>Unit Testing (Unit Test)</td><td>junit, surefire, ...</td></tr><tr><td>Compile</td><td>compiler, kotlin, scala, ...</td></tr><tr><td>Documentation (Doc)</td><td>asciidoc, javadoc, site</td></tr><tr><td>Install</td><td>archetype, install</td></tr><tr><td>Linter</td><td>checkstyle, jacoco, spotless, ...</td></tr><tr><td>Packaging (Pack)</td><td>assembly, jar, source, ...</td></tr><tr><td>Others</td><td>clean, quarkus, xml, ...</td></tr><tr><td>Unclassified (Unclass)</td><td>Tasks not associated with a specific plugin.</td></tr></tbody></table>

<table><caption>TABLE II: Cliff's Delta Comparing the Energy Consumption of Maven or Gradle Tasks from Projects of Different Sizes</caption><thead><tr><td>Tool</td><td>Comparison</td><td>p-value</td><td>Delta</td><td>Interpretation</td></tr></thead><tbody><tr><td>Maven</td><td>Small × Medium</td><td>&lt; .001</td><td>0.037</td><td>negligible</td></tr><tr><td>Maven</td><td>Small × Large</td><td>&lt; .001</td><td>0.045</td><td>negligible</td></tr><tr><td>Maven</td><td>Medium × Large</td><td>&lt; .001</td><td>0.012</td><td>negligible</td></tr><tr><td>Gradle</td><td>Small × Medium</td><td>.001</td><td>-0.057</td><td>negligible</td></tr><tr><td>Gradle</td><td>Small × Large</td><td>&lt; .001</td><td>0.102</td><td>negligible</td></tr><tr><td>Gradle</td><td>Medium × Large</td><td>&lt; .001</td><td>0.150</td><td>small</td></tr></tbody></table>

The category Others has plugins not associated with the previous categories, and the category Unclassified encompasses the tasks that were not associated with a specific plugin. We consider tasks from all categories listed in Table I, including the unclassified tasks, when conducting our analyses.

One Gradle category that may not correspond precisely to its corresponding Maven category is the Compile one. For Gradle, we put under this category tasks with names such as `build` or `buildSrc`, which, besides compiling source files, may also run some tests.

In Table I, the plugin `archetype` is associated with the categories Integration Testing and Install. The reason for this is that we associate the goal `integration-test` of this plugin with the Integration Testing category and the goal `update-local-catalog` with the Install one.

### III. RESULTS

In this section, we present the results and the corresponding analysis associated with our research questions. The next section discusses the overall energy consumption of Maven or Gradle tasks, while Section III-B focuses on the energy consumption according to the Maven or Gradle task category and discusses the differences in energy consumption between categories.

#### A. RQ1. How is the overall energy consumption associated with Maven/Gradle tasks?

Initially, our investigation aims to better understand the energy footprint in a CI workflow that is related to tasks managed by Maven or Gradle. Moreover, we would like to know the impact of the project size in the energy consumption of Maven/Gradle tasks.

To understand the energy impact of tasks managed by Maven or Gradle, we computed the energy consumption of all tasks in a workflow (e.g., Fetching the repository), then we calculated the percentage related to tasks managed by build automation tools (e.g., Compilation, Testing).

As shown in Fig. 2a, Maven-managed tasks account for 24% of total energy consumption within workflows. This figure can reach 38% in medium-sized projects managed by Maven.

In the case of Gradle managed workflows, Fig. 2a indicates that Gradle-related tasks consume 28% of the energy consumption of the workflow, an amount that reaches 40% in the case of small projects. Based on this, we can conclude

that the tasks managed by these build automation tools have a significant impact on the energy consumption of a workflow and, consequently, on the CI workflow. Next, we are going to analyze more deeply the energy consumption related to tasks managed by Maven or Gradle.

Fig. 2b presents the percentage, according to the associated project size, of Maven workflows, Maven-managed tasks, and their total energy consumption and execution time. Similarly, Fig. 2c shows the corresponding information in the case of workflows that use Gradle. In both figures, we can see that more than half of the workflows are from medium-sized projects, and around one third come from large projects. Only about 10% of the workflows are from small projects. When analyzing the energy consumption of tasks managed by Maven or Gradle, we can notice that tasks associated with small projects consume a tiny fraction of it: 3% in the case of Maven and only 2.6% in the case of Gradle.

Figs. 3 and 4 show the boxplots with the energy consumption by the size of the project for Maven and Gradle, respectively. In a boxplot, the line that divides the box signifies the median, with 50% of the data above and 50% below this line. The bottom edge of the box indicates the lower quartile, whereas the top edge marks the upper quartile. The whiskers extend to show the minimum and maximum data values.

For Maven, it appears that tasks from small and large projects consume more energy compared to those from medium-sized projects. In the case of Gradle, tasks from small and medium projects consume more energy than tasks from large-sized projects.

To further investigate the impact of the project size on the energy consumption of Maven/Gradle tasks, we perform statistical tests. We used the Mann-Whitney-Wilcoxon (MWW) test [21], [22] followed by the Cliff delta effect size measure [23]. The MWW test is a nonparametric test, and its null hypothesis assumes that two distributions come from the same population ($α = 0.05$). When two distributions come from different populations according to the MWW test, i.e., its null hypothesis is rejected, we used Cliff's delta, a nonparametric effect-size metric, to quantify the magnitude of this difference.

The difference between distributions is greater when the corresponding Cliff's delta is larger. We used the following thresholds, suggested by Romano et al. [24], to interpret Cliff's delta: $delta < 0.147$ (negligible); $delta < 0.33$ (small); $delta < 0.474$ (medium); and $delta >= 0.474$ (large). A positive Cliff's delta value indicates how much larger the
<figure><img src="image_3.png" /><figcaption>(a) Workflows Tasks Managed by Maven or Gradle: Energy Share of Tasks Managed by Maven or Gradle Over Total Workflow Energy.</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>(b) Percentage of Maven Workflows, Tasks, Energy Consumption and Execution Time by Project Size.</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>(c) Percentage of Gradle Workflows, Tasks, Energy Consumption and Execution Time by Project Size.</figcaption></figure>

Fig. 2: Energy Share of Tasks Managed by Maven or Gradle Over Total Workflow Energy (a) and Percentages of Gradle/Maven Workflows, Tasks, Energy Consumption and Execution Time by Project Size (b,c).

<figure><img src="image_6.png" /><figcaption>Fig. 3: Energy Consumption of Maven Tasks by Project Size.</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>Fig. 4: Energy Consumption of Gradle Tasks by Project Size.</figcaption></figure>

values of the first distribution are, while a negative value indicates the opposite.

Table II shows the results of the statistical tests. For both tools, Maven and Gradle, the MWW tests indicate a statistical difference between all pairs (e.g., Small, Medium, Small × Large, Medium × Large). The Cliff's delta is negligible except for the comparison between medium-sized and large-sized Gradle projects, where it is small. Nonetheless, it is

interesting to see that tasks from small Maven or Gradle projects consume more energy than tasks from large Maven or Gradle projects, as the positive delta in the comparison Small × Large indicates.

The tasks managed by Maven and Gradle constitute approximately 25% of the total energy within a Continuous Integration (CI) workflow. It is observed that tasks coming from larger projects typically do not result in higher energy consumption compared to those from smaller projects.

## B. RQ2. How is the energy consumption profile by category of Maven/Gradle task?

We examined the energy consumption characteristics of Maven and Gradle workflows by categorizing the tasks of these build automation tools, as detailed in Section II-B5. Next, we will discuss the overall energy consumption associated with each category, then we will talk about the energy consumption profile of each category per task and per unit of time.

**Overall Energy Consumption by Category.** In Figs. 5 and 6 we show the percentage of energy consumption and the amount of tasks associated with each category for, respectively, the Maven and Gradle workflows.

These figures present the data considering all workflows, and they also allow us to see the energy consumption by category according to the size of the project associated with a workflow.

In the case of Maven, almost half (47%) of the energy consumption associated with a workflow is due to testing. According to Fig. 5, the larger the project, the more energy is spent on testing. The percentage of energy consumption related to tests is lower (26%) in the case of workflows from small-sized projects, where the energy consumption related to integration tests was negligible, and is higher (58%) in the case of large-sized projects. In contrast, the proportion of tasks
<figure><img src="image_8.png" /><figcaption>Fig. 5: Energy Consumption of Maven Tasks by Category (a) and Proportion of Maven Tasks by Category (b).</figcaption></figure>

<figure><img src="image_9.png" /><figcaption>Fig. 6: Energy Consumption of Gradle Tasks by Category (a) and Proportion of Gradle Tasks by Category (b).</figcaption></figure>

related to testing decreases as the size of the project increases. These types of tasks represent 10% of tasks in the case of small projects, but only 5% in the case of large projects.

Besides Unit and Integration Testing, only the Install category accounts for at least 10% of the total energy consumption of the workflows. However, most of the energy consumption in this category is due to the usage of `archetype: update-local-catalog` in a single medium-sized project, the Java Microbenchmark Harness (JMH) project. This usage accounts for 77.5% of the overall energy consumption of the Install category.

Contrarily to the categories related to testing, the percentage of the workflows' tasks related to the Compiler and the Linter categories increases when the size of the project increases. The Linter-related tasks represent 9% of the tasks in the case of small and medium projects and 16% of them in the case of large projects. Compiler-related tasks are 24% tasks in small projects, an amount that increases to 28% and 27% in the case of, respectively, medium and large projects. More than a quarter (27%) of all tasks in a Maven workflow are related to compilation.

Finally, we should note that 26% of the energy consumption of small-sized Maven projects is due to documentation, but this amount decreases to only 2% and 3% in the case of, respectively, medium and large projects.

In the case of Gradle workflows, Fig. 6 shows that once more, testing-related tasks are the ones that consume more energy. Together, the energy consumption of the categories Unit Testing and Integration Testing represents more than a third (36%) of the total energy consumption of the workflows.

For Gradle, the energy consumption related to testing also increases considerably when project size increases from small to medium.

In the case of small Gradle projects, more than half (60%) of the energy consumption is associated with tasks from the Others category. A closer look reveals that around 95% of this consumption is due to the task `runPluginVerifier`, which is executed by two workflows from IntelIJ-related projects: `IntelIJ Platform SDK Documentation<fnref n="9" />` and `Key Promoter X<fnref n="10" />`. Although both workflows have a task with this name, it may be defined differently in each.

Compared to Maven, Gradle shows a greater amount of energy consumption related to the Compile category. As discussed in Section II-B5, due to the difficulty in classifying Gradle tasks, some test-related tasks may have been classified under the Compiler category. This misclassification could explain the significant energy impact of this category for Gradle.

We can also see that for Gradle workflows the energy consumption related to the Packaging category (9%) is more relevant compared to Maven workflows (4%), and that a quarter of the tasks in Gradle workflow are related to Packaging.

> Testing-related tasks are those that consume more energy. The larger the project, the higher the percentage of energy consumption related to the testing.

<footnote n="9">⁹https://github.com/JetBrains/intelli-jdk-docs</footnote>

<footnote n="10">¹⁰https://github.com/halirutan/IntelliJ-Key-Promoter-X</footnote>
<figure><img src="image_10.png" /><figcaption>Fig. 7: Energy Consumption of Maven Tasks by Category.</figcaption></figure>

<figure><img src="image_11.png" /><figcaption>Fig. 8: Power Dissipation of Maven Tasks by Category.</figcaption></figure>

**Energy Consumption Profile Per Task and Per Unit of Time.** Now we discuss the energy consumption of tasks from different categories per task and per unit of time (power dissipation). We first present an analysis in the context of Maven and then in the context of Gradle.

1) *Maven*: We can see in Figs. 7 and 8 the boxplots show, respectively, the energy consumption and the power dissipation by category of all Maven tasks. We used again a logarithmic scale on the Y axis to properly show the data.

Fig. 7 shows that Maven tasks in the Unit Testing category seem to consume much more energy than tasks from other categories. Besides that, tasks related to Documentation also tend to consume more energy. In turn, Fig. 8 shows different profiles of power dissipation, where tasks from categories Install, Packaging and Others seem to consume more energy per unit of time.

To check whether there are categories with a different energy and power profile, we used the Kruskal-Wallis test by ranks [25]. It is a nonparametric statistical test that extends the Mann-Whitney-Wilcoxon test, which is designed to compare only two groups. When applying the Kruskal-Wallis test, the null hypothesis is that the medians of all groups are equal. The alternative hypothesis is that at least one group has a population median different from that of at least one other group. When Kruskal-Wallis' null hypothesis is rejected, then we say that there are categories with a different energy consumption, or power dissipation, profile. In this case, for each pair of categories $C_1$ and $C_2$, we need to apply the MWW test to know if the energy profile of $C_1$ is different from $C_2$. Similarly, as we did previously in Section III-A, in the case there is a statistical difference between two categories, we will also apply the associated Cliff's delta.

In the case of Maven, the Kruskal-Wallis test indicates that we have different energy and power profiles among the categories. In the following, we discuss the results. In examining the disparities pertinent to a specific category, our analysis will concentrate on contrasting these differences with those of other categories that have not been previously addressed in the text.

The MWW test confirms that the energy consumption of Unit Testing category is greater in comparison with the other categories. The Cliff delta indicates that this difference is small compared to category Documentation, medium compared to categories Integration Testing and Compilation, and large compared to the remaining categories.

The energy consumption of the Documentation category also has a large difference compared to categories Install, Packaging and Others, and a difference at least small compared to other categories.

There is no statistical difference between the energy consumption of tasks from categories Integration Testing and Compile, Packaging and Others, Linter and Unclassified.

Regarding the power dissipation, the difference between categories is at most small, except for categories Packaging and Unit Testing, which have a medium Cliff's delta. According to the MWW test, tasks from the Integration Testing category do not have a different power dissipation when compared to Compile, Documentation, and Linter tasks.

> Unit Testing and Documentation tasks from Maven projects consume more energy per task, while tasks from Packaging dissipate a bit more power.

2) *Gradle*: The box plots in Fig. 9 and Fig. 10 show by category the energy consumption and power dissipation, respectively, considering all Gradle tasks.

Once again, the Kruskal-Wallis test indicates that we have different energy profiles among the categories. Following the same approach that we used for Maven, in the following we discuss our findings.

Regarding energy consumption, the MWW test says that the categories Integration Testing and Unit Testing are not different and that their tasks have a higher energy consumption in comparison with tasks from other categories. The Unit Testing category has a Cliff's delta at least small for all other categories. This difference is large compared to the Unclassified category and medium compared to the Documentation and Others categories. Categories Linter, Install and Compile
<figure><img src="image_12.png" /><figcaption>Fig. 9: Energy Consumption of Gradle Tasks by Category.</figcaption></figure>

<figure><img src="image_13.png" /><figcaption>Fig. 10: Power Dissipation of Gradle Tasks by Category.</figcaption></figure>

are considered equal, while tasks from category Unclassified present a lower energy consumption.

Regarding the power dissipation, similarly to Maven, there is a statistical difference between categories, although such difference is more modest. The MWW test states that the Documentation category is not different from the Linter and the Others categories. Their Cliff's delta is positive when compared to all other categories, a difference that is medium to category Install, and at most small to the remained ones. The MWW test also says that the Integration Testing category is not different from the Install and the Unclassified categories.

> Testing-related tasks from Gradle projects consume more energy per task, while tasks from Install dissipate less power.

# IV. THREATS TO VALIDITY

## A. *Conclusion validity*:

The findings of our study are limited to the sample we extracted and analyzed: a set of popular Java repositories (each with at least 100 stars) and hosted on a specific platform

(GitHub), using a dedicated CI system (GitHub Actions) and a Java build automation tool (Maven and Gradle). Therefore, the conclusions of our study may not be generalizable to other build automation tools or programming languages.

## B. *Internal validity:*

Concerning energy measurement, we used a 2 Hz (500 ms) sampling rate as recommended by Fieni et al. [12]. However, in a work published after our experiments, Jay et al. explores the usage of SmartWatts at a higher sampling rate and showed that reliable measures can be performed with a sampling rate of 10 Hz [15]. Relying on a higher sampling rate could increase the accuracy of our energy measurements, better capturing the energy consumption of short-running tasks. We capture exclusively the energy consumption of the CPU and we do not consider other aspects like hard-drive disk, network, etc. Our decision is motivated by previous research that indicates that CPU consumption is typically the primary source of energy usage in servers. For example, Malladi et al. [26] discovered that, in a similar hardware context, the CPU energy represented 60-69% and RAM was responsible for 6-19% of the total energy consumption. Furthermore, quantifying network energy costs presents significant challenges, as it requires detailed knowledge of network infrastructure and geographical boundaries [27]

Both Maven and Gradle build systems offer caching mechanisms for dependencies ensuring that only updated dependencies are downloaded between builds. In our experimental setup, the environment is cleaned between each workflow execution. Although this is not the default behavior on self-hosted runners, it is more representative of workflows executed on GitHub-hosted runners. GitHub offers a cache action that saves dependencies folder, between workflow execution, on GitHub servers. This caching feature is not utilized in our experimental design. Consequently, some workflows may consume less energy in practice. The impact of caching mechanisms will be explored in future work.

## C. *Construct validity:*

Some Gradle tasks (e.g., `checkstyleTest`, `findbugsIntegrationTest`, `buildSrc`) could be associated with more than one category. A different association between Gradle tasks and categories might increase the energy consumption associated with testing. In addition, our task classification is based on rules designed manually (more than 70 for Maven and 53 for Gradle). Due to time constraints, we did not design rules to classify all tasks, resulting in some unclassified tasks, which might impact the final result. However, to mitigate this risk, we ensure that the cumulative energy consumption of unclassified tasks is negligible, as shown in Figures 5 and 6, where unclassified tasks represent only 2% for Maven and 10% for Gradle.

Another potential threat to our methodology is the filtering of failed tasks. Maven or Gradle tasks resulting in errors during execution were filtered out to avoid biasing the analysis with short or low-energy tasks failing due to the experimental
setup (for instance, an error due to the lack of credentials to
publish artifacts on Maven Central). However, this also means
filtering out tasks that genuinely fail, like test tasks where
tests do not pass. Thus, our analysis conservatively provides
an upper bound on the energy consumption of build tasks.
To mitigate this threat, we also ensured that our conclusions
would remain unchanged even if filtering of failed tasks was
not applied. Thus, we provide, on the replication package, the
same analysis on non-filtered data.

D. *External validity:*

Data centers often use hardware optimized for running
such intensive workflows and can be more energy efficient,
on a scale, than regular machines [28]. Different energy
efficiency optimizations are implemented in distributed large-
scale systems at different levels [29], such as thermal man-
agement or resource scheduling. Since our experiments were
conducted in a controlled environment, our findings might
not be representative of the energy consumption of these
workflows in real-world settings. However, we designed our
experimental protocol to be as close as possible to a real-
world setup. We do not use special configuration at the OS
level or on the hardware. Our machine has ordinary hardware,
as detailed in II-A, and our measurements are performed using
a state-of-the-art software power meter. This setup allows us
to distinguish the energy consumption associated with the
execution of workflows from the rest of the machine's program
executions.

V. RELATED WORK

According to [2], there is a “lack of knowledge about how
to write, maintain, and evolve energy-efficient software appli-
cations”. Their study also mentions the difficulty in measuring
specific events while a software is running. Our measurement
approach based on SmartWatts could circumvent this issue,
enabling us to measure the energy consumption of individual
Maven or Gradle tasks and to present an energy profile of
these tasks. This knowledge can help developers identify and
improve tasks that typically consume more energy.

Eco CI [30] is a project that aims to estimate energy
consumption in CI workflows. It allows calculating the energy
consumption of CI tasks based on the power consumption
features of the underlying hardware. Unlike Eco CI, which
makes an estimate, our approach actually measures the energy
consumption of CI tasks, which should lead to more precise
results [15]. Furthermore, even though Eco CI is accessible, it
has not been employed in a study of similar scale to ours.

Scaphandre [31] is another RAPL-based power meter solu-
tion that estimates the power at a specific time. However, the
maximum sampling frequency of Scaphandre is 0.5 Hz [15],
which is lower than that of SmartWatts.

There are testing approaches that focus on minimizing the
test suit to improve energy efficiency [32], [33]. Since our
study indicates that testing-related tasks consume most of the
energy, using such approaches could significantly reduce the
energy consumption of a CI workflow.

Kruglov et al. [34], try to estimate changes in the energy
consumption of a software based on software metrics (e.g.,
number of new classes and methods) and the amount of energy
consumed while performing a successful user acceptance
testing. Similarly, some tasks from a CI workflow could be
used as a proxy to estimate the energy consumption of the
associated software.

VI. CONCLUSION

As the energy impact of the ICT sector increases, interest in
the energy footprint associated with software development is
also following the trend. To better understand it, we conducted
a large-scale study with 1167 CI workflows extracted from
popular Java projects hosted on GitHub. After executing them
locally, in a controlled environment, we analyze the energy
consumption of 183 355 tasks managed by Apache Maven
and Gradle. We find that tests-related tasks represent 47% and
36% of the total energy consumed by, respectively, Maven and
Gradle tasks. Moreover, the amount of energy associated with
testing tends to increase with the size of the project. We also
found that tasks of different categories have a different profile
regarding energy consumption per task and per unit of time.

Our study contributes to a better understanding of the energy
consumption in a CI workflow and it may help developers to
adjust the tasks executed in the workflows of their projects
in order to diminish their corresponding energy impact. For
example, practitioners might leverage this study to prioritize
the optimization of testing-related tasks, as they are the ones
that consume more energy.

To further explore the energy consumption of tasks in a
CI workflow, it would be valuable to conduct similar studies
involving different programming languages and build automa-
tion tools. Concerning our Gradle/Maven classification, it
would be interesting to cross-check with another classification
made with a Large Language Model to identify any missing
categories and enhance our manual classification. As part
of future work, we aim to analyze the energy consumption
associated to disk usage and network usage. In addition,
incremental build, originally intended to enhance performance
[35], [36], could be explored to reduce energy consumption of
CI workflows. For example, automatically skipping unaffected
build steps has proven to be effective in improving perfor-
mance [37], particularly by avoiding redundant test executions.
Finally, optimization patterns targeting performance [38] could
also be evaluated in terms of energy consumption impact.

ACKNOWLEDGMENT

This study was financed in part by the Coordenação
de Aperfeiçoamento de Pessoal de Nível Superior – Brasil
(CAPES) – Finance Code 001.

REFERENCES

[1] Irene Manotas, Christian Bird, Rui Zhang, David C. Shepherd, Ciera Jas-
pan, Caitlin Sadowski, Lori L. Pollock, and James Clause. An empirical
study of practitioners' perspectives on green software engineering. In
*38th International Conference on Software Engineering (ICSE)*, pages
237–248, Austin, USA, May 2016. ACM.
[2] Gustavo Pinto and Fernando Castor. Energy efficiency: a new concern for application software developers. *Communications of the ACM*, 60(12):68–75, 2017.

[3] Rui Pereira, Marco Couto, Francisco Ribeiro, Rui Rua, Jácome Cunha, João Paulo Fernandes, and João Saraiva. Ranking programming languages by energy efficiency. *Science of Computer Programming*, 205:102609, 2021.

[4] Liuzixuan Lin and Andrew A. Chien. Adapting datacenter capacity for greener datacenters and grid. In *14th ACM International Conference on Future Energy Systems, e-Energy*, pages 200–213, Orlando, USA, June 2023. ACM.

[5] Anders S. G. Andrae and Tomas Edler. On global electricity usage of communication technology: Trends to 2030. *Challenges*, 6(1):117–157, 2015.

[6] Erol Gelenbe and Yves Caseau. The impact of information technology on energy consumption and carbon emissions. *Ubiquity*, 2015(June):1:1–1:15, 2015.

[7] Center Statistics Office. Data centres metered electricity consumption 2023. https://www.cso.ie/en/releasesandpublications/ep/p-dmcec/datacentresmeteredelectricityconsumption2023/, 2024. Accessed: 25-04-2025.

[8] Martin Fowler. Continuous integration. https://www.martinfowler.com/articles/continuousIntegration.html, 2006. Accessed: 25-04-2025.

[9] Paul M Duvall, Steve Matyas, and Andrew Glover. *Continuous integration: improving software quality and reducing risk*. Pearson Education, 2007.

[10] Quentin Perez, Romain Lefeuvre, Thomas Degueule, Olivier Barais, and Benoit Combemale. Software frugality in an accelerating world: the case of continuous integration. https://arxiv.org/abs/2410.15816, 2024. Accessed: 25-04-2025.

[11] Hudson Borges, André C. Hora, and Marco Túlio Valente. Understanding the factors that impact the popularity of github repositories. In *32nd IEEE International Conference on Software Maintenance and Evolution, (ICSME) 2016, Raleigh, NC, USA, October 2-7, 2016*, pages 334–344, Raleigh, USA, october 2016. IEEE Computer Society.

[12] Guillaume Fieni, Romain Rouvoy, and Lionel Seinturier. Smartwatts: Self-calibrating software-defined power meter for containers. In *20th IEEE/ACM International Symposium on Cluster, Cloud and Internet Computing, (CCGrid)*, pages 479–488, Melbourne, Australia, May 2020. IEEE.

[13] Howard David, Eugene Gorbatov, Ulf R. Hanebutte, Rahul Khanna, and Christian Le. RAPL: memory power estimation and capping. In *16th ACM/IEEE International Symposium on Low Power Electronics and Design*, pages 189–194, Austin, Texas, USA, August 2010. ACM.

[14] Vincent M. Weaver, Matt Johnson, Kiran Kasichayanula, James Ralph, Piotr Luszczek, Daniel Terpstra, and Shirley Moore. Measuring energy and power with PAPI. In *41st International Conference on Parallel Processing Workshops (ICPPW)*, pages 262–268, Pittsburgh, USA, September 2012. IEEE Computer Society.

[15] Mathilde Jay, Vladimir Ostanenco, Laurent Lefèvre, Denis Trystram, Anne-Cécile Orgerie, and Benjamin Fichel. An experimental comparison of software-based power meters: focus on CPU and GPU. In *23rd IEEE/ACM International Symposium on Cluster, Cloud and Internet Computing (CCGrid)*, pages 106–118, Bangalore, India, May 2023. IEEE.

[16] Kashif Nizam Khan, Mikael Hirki, Tapio Niemi, Jukka K. Nurminen, and Zhonghong Ou. RAPL in action: Experiences in using RAPL for power measurements. *ACM Transactions on Modeling and Performance Evaluation of Computing Systems*, 3(2):9:1–9:26, 2018.

[17] Paul Menage. Control groups. https://docs.kernel.org/admin-guide/cgroup-v1/cgroups.html, 2006. Accessed: 25-04-2025.

[18] Mehdi Golzadeh, Alexandre Decan, and Tom Mens. On the rise and fall of CI services in github. In *IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER)*, pages 662–672, Honolulu, USA, March 2022. IEEE.

[19] Wagner Felidré, Leonardo B. Furtado, Daniel Alencar da Costa, Bruno Cartaxo, and Gustavo Pinto. Continuous integration theater. In *13th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)*, pages 1–10. IEEE, September 2019.

[20] João Helis Bernardo, Daniel Alencar da Costa, Sérgio Queiroz de Medeiros, and Uirá Kulesza. How do machine learning projects use continuous integration practices? an empirical study on github actions. In Diomidis Spinellis, Alberto Bacchelli, and Eleni Constantinou, editors,

21st IEEE/ACM International Conference on Mining Software Repositories (MSR), pages 665–676, Lisbon, Portugal, April 2024. ACM.

[21] Henry B Mann and Donald R Whitney. On a test of whether one of two random variables is stochastically larger than the other. *The annals of mathematical statistics*, pages 50–60, 1947.

[22] Frank Wilcoxon. Individual comparisons by ranking methods. *Biometrics Bulletin*, 1(6):80–83, 1945.

[23] Norman Cliff. Dominance statistics: Ordinal analyses to answer ordinal questions. *Psychological bulletin*, 114(3):494, 1993.

[24] Jeanine Romano, Jeffrey D Kromrey, Jesse Coraggio, and Jeff Skowronek. Appropriate statistics for ordinal level data: Should we really be using t-test and cohen'sd for evaluating group differences on the nsse and other surveys. In *Annual meeting of the Florida Association of Institutional Research*, volume 177, page 34, 2006.

[25] S. Siegel and N.J. Castellan. *Nonparametric Statistics for the Behavioral Sciences*. McGraw-Hill international editions statistics series. McGraw-Hill, 1988.

[26] Krishna T. Malladi, Frank A. Nothaft, Karthika Periyathambi, Benjamin C. Lee, Christos Kozyrakis, and Mark Horowitz. Towards energy-proportional datacenter memory with mobile DRAM. In *39th International Symposium on Computer Architecture (ISCA)*, pages 37–48, Portland, USA, June 2012. IEEE Computer Society.

[27] Gaël Guennebaud and Aurélie Bugeau. Energy consumption of data transfer: Intensity indicators versus absolute estimates. *Journal of Industrial Ecology*, June 2024.

[28] Beatriz Prieto, Juan José Escobar, Juan Carlos Gómez-López, Antonio F Díaz, and Thomas Lampert. Energy efficiency of personal computers: a comparative analysis. *Sustainability*, 14(19):12829, 2022.

[29] Anne-Cécile Orgerie, Marcos Dias de Assunção, and Laurent Lefèvre. A survey on techniques for improving the energy efficiency of large-scale distributed systems. *ACM Computing Surveys*, 46(4):471–476, 2013.

[30] Green Coding Solutions. Eco CI Energy estimation for Github Actions Runner VMs. https://github.com/green-coding-solutions/eco-ci-energy-estimation, 2023. Accessed: 25-04-2025.

[31] Benoit Petit. Scaphandre documentation. https://hubblo.org.github.io/scaphandre-documentation/, 2020. Accessed: 25-04-2025.

[32] Ding Li, Yuchen Jin, Cagri Sahin, James Clause, and William G. J. Halfond. Integrated energy-directed test suite optimization. In Corina S. Pasareanu and Darko Marinov, editors, *14th International Symposium on Software Testing and Analysis (ISSTA)*, pages 339–350, San Jose, USA, July 2014. ACM.

[33] Reyhaneh Jabbarvand Behrouz, Alireza Sadeghi, Hamid Bagheri, and Sam Malek. Energy-aware test-suite minimization for android apps. In *25th International Symposium on Software Testing and Analysis (ISSTA)*, pages 425–436, Saarbrücken, Germany, July 2016. ACM.

[34] Artem V. Kruglov, Giancarlo Succi, and Xavier Zelada Vasquez. Incorporating energy efficiency measurement into C\!CD pipeline. In *2nd European Symposium on Software Engineering (ESSE)*, pages 14–20, Larissa, Greece, November 2021. ACM.

[35] Gabriël Konat, Sebastian Erdweg, and Eelco Visser. Scalable incremental building with dynamic task dependencies. In *33rd ACM/IEEE International Conference on Automated Software Engineering, (ASE)*, pages 76–86. ACM, September 2018.

[36] Georges Aaron Randrianaina, Xhevahire Tërnava, Djamel Eddine Kheladi, and Mathieu Acher. On the benefits and limits of incremental build of software configurations: An exploratory study. In *44th IEEE/ACM International Conference on Software Engineering (ICSE)*, pages 1584–1596, Pittsburgh, USA, May 2022. ACM.

[37] Keheliya Gallaba, John Ewart, Yves Junqueira, and Shane McIntosh. Accelerating continuous integration by caching environments and inferring dependencies. *IEEE Transactions on Software Engineering*, 48(6):2040–2052, 2022.

[38] Mingyang Yin, Yutaro Kashiwa, Keheliya Gallaba, Mahmoud Alfadel, Yasutaka Kamei, and Shane McIntosh. Developer-applied accelerations in continuous integration: A detection approach and catalog of patterns. In *39th IEEE/ACM International Conference on Automated Software Engineering, (ASE) 2024, Sacramento*, pages 1655–1666, Sacramento, USA, October 2024. ACM.