Currently a hosted version of the CarbonAwareSDK is being used however this isnt owned by us, only returns test data, is an old version of the API and could be taken down at any minute.

This is going to require acess to the pro teir of either WattTime or ElectrcityMaps or a free month if they give it or some test data returned by one of the data providers (watttime does this if you give it a a specific region).

• lets keep the existing method of using the hosted SDK in place so we can reference it if we find the CLI no good.

TODO

create new delayCalculator.yml workflow

• clone carbon-aware-sdk repo to get the CLI source code
• add configuration values (username & pasword) for data source (WattTime or ElectricityMaps) which must be kept in this repo's secrets or as input to the github action using a secret
• Install/build or whatever is needed to use the CLI version
• use CLI to get same output as Hosted version gives

Notes

• check format of response in CLI version, it may be different.

• WattTime - i think it can return sample data for testing if you use a specific region:
  https://www.watttime.org/api-documentation/?Python3#emissions-forecast

• For configuration of the SDK data sources see:
  https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/ff355f3a8b0f6411507f9eb644ca6d1194547ec1/docs/configuration.md

• For general CLI stuff see:
  https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/ff355f3a8b0f6411507f9eb644ca6d1194547ec1/docs/carbon-aware-cli.md

To make this reusable we want to turn this repoisotry into a github action that other repositories can then reference.

it would be used to schedule an existing workflow in the repository to run at the time of forecasted lowest carbon intensity.

it would:

1. use inputs to calculate optimal time and region using CarbonAwareSDK.
2. copy and modify the template the workflow into the correct directory and add the necessary parts to the template workflow
   • replace schedule placeholder with correct time ${SCHEDULE}
   • replace region string placeholder ${REGION} (optional for now as currently it can only cater for 1 region)
   • add git config step
   • add self-deletion step to end

Possible Inputs:

• regions String[] (first iteration should just handle 1 element array, or just a plain string, but want future capability of handling multiple regions)
• job length in minutes Int
• max waiting time in minutes Int
• template workflow tocopy and modify

Github hosted runners do not currnetly give their exact location. Github uses the following azure regions (https://github.com/orgs/community/discussions/24969):

East US (eastus)
East US 2 (eastus2)
West US 2 (westus2)
Central US (centralus)
South Central US (southcentralus)

can we estiamte the most likely best time?

ideas:

1. sum up each region's forecasted carbon intensity for each timestamp, select lowest total (my current favourite)
2. look at optimalDataPoints array for each region and select highest count, they could all be 1 if all arre different though

Open to ideas here on what could be the best method

Once this is completed we can then add a new input inot the action that is a boolean for github hosted, if true use this new method and will ignore the existing regions input, false use exisiting method

required completion of #17 first

for forecast data only WattTime gives this info out for free. the other data source ElectricityMaps doesn't give this out for free and you would need to use a paid tier.

instead of cloning and installing CarbonAwareSDK every workflow which isnt ideal should we not just directly call the WattTime API?

Do we want to be able to connect to the other data sources provided by CarbonAwareSDK?

You can only set up one data source at a time so using multiple is not that useful.

current the simple bash scrip handles only 1 region. THis is because ti retreives the first regions optimalDataPoints object but each region generates this.

we ideally want to be able to put in an array of regions and then have the most optimal region and time outputted.

THis will require changing from using bash scripts to using something more sophisticated that uses json object parsing. (wait for #18 to be compelted)

There are different possibilities for us to use this action for the blog publishing including:

• SDK hosting - we host the SDK vs. clone and build CLI in the workflow.
• runner hosting - Self vs. github (worse estimation for github as there are 5 possible places and they are not great for us (US based))
• skip the SDK and build our own predicitve AI model to circumvent the paid-for endpoints of the data sources

I think we need to come up with some proposals that explain the work and effort required.

currently all logic are commands contained in workflow files. However for better JSON parsing using an alternative language will be the best moving forward.