Eco CI Runner inside GMT

This repo allows for GitHub Actions runs that are placed on self-hosted runners to be run inside of the Green Metrics Tool (GMT)

It does so by:

• Using the actions runner in a crafted Docker image with some needed dependencies installed
  • This PoC does not install all packages present in the actual GitHub Actions Runner Image ... but could so in the future
• Starting the actions runner with a usage_scenario.yml that will get the Runner Token fed in as Usage Scenario Variable
• Instrumenting the actions runner by redirecting it's ephemeral log output from the _diag folder to a temporary location, parsing the steps and timestamps and then using the Micro Phases feature of GMT to expand them to actual phases.

Problems with the solution

• It can happen that the log files get chunked. The process_logs.py currently cannot handle this and currently only expects one file. This is a solvable bug
• The tail.sh which watches the _diag directory for new files has currently a sampling rate of 0.1 s. This is usually enough but in rare instances a debug log file might be missed. This is a timing problem which is currently only solvable through increasing the overhead
• Sometimes the timings in the log are not accurate as separate steps log do not include the end timestamp. Example for sleep:

2025-08-20T11:44:33.5333492Z ##[group]Run sleep 3
2025-08-20T11:44:33.5333680Z �[36;1msleep 3�[0m
2025-08-20T11:44:33.5336924Z shell: /usr/bin/bash -e {0}
2025-08-20T11:44:33.5337072Z ##[endgroup]

Although a sleep 3 was issued here the group ends without having a timestamp with a 3 second increase. If we look into the cumulated file where all groups and also some noisy debug is stored we see that the next line is correctly 3 seconds later.

2025-08-20T11:44:03.2675295Z ##[group]Run sleep 30
2025-08-20T11:44:03.2675473Z �[36;1msleep 30�[0m
2025-08-20T11:44:03.2678114Z shell: /usr/bin/bash -e {0}
2025-08-20T11:44:03.2678254Z ##[endgroup]
2025-08-20T11:44:33.2817125Z Prepare all required actions

The cumulated file can however not be used directly as the understanding which steps have which names comes from a JSON object in the Workers_***.log file and then maps with an id to a filename.

What now could be done is map the corresponding lines from the separate file back to the cumulated file and then taking the timestamp for the next line as the end-timestamp. This approach was so far not taken, as the solution already feels very flaky.

Possbile next steps

Probably the least patchy and most stable step would be to patch the actions runner by introducing two print statements:

• One when a new step starts with name and UNIX timestamp
• One when a step ends with a name and UNIX timestamp

The just the output of the /run.sh could be used.

However this means we would have to setup a Windows build chain for the runner (See Windows Build Instructions only). This step is currently not taken.