Add an option to get the data as json output

[rajbos]

I would like to be able to group the data over time or across a team (maybe for an entire PR?). To be able to calculate things, I'd need to be able to get the data out as json first

• Add an input to get the data out as json in an output

I'd be happy to send in a PR for this!

[ArneTR]

I commented on this in #3 (comment) please see my reasoning for not providing this atm there.

As said: We are happy to take a PR though :)

[rajbos]

Happy to provide that PR! I also want to use that output to group the data for all jobs in a workflow, so that means I would need to export it as JSON and then consolidate, which could be a next step. Let's first focus on getting that out as JSON then 😄.

[jreimone]

Proposed a solution for the total data in this PR. Can be replicated to making the data of the labelled step measurements (with task get-measurement) available, too.

[rajbos]

Looks good! I've left a review comment on the PR.

[jreimone]

@ArneTR @rajbos do you think something is missing in my PR? Would you be up for merging it?

[dan-mm]

Hi @jreimone

I will take a look at your PR and test it out, but one thing would be nice would be a flag for this functionality (I would have it off by default). Its a good functionality to have, but I think it should only export the json if the user requests it

[jreimone]

Thank you @dan-mm for testing. A flag can do but I also think that you just don't need to consume the output from the step. The json is only accessible if you add an extra step that explicitly consumes the output. You can see it in action in my provided example workflow.

[rajbos]

I agree that there is no need for a flag, it is just an output. If the user does not consume it, they will not see any difference at all.

I would like to include the new output in the readme though, the Usage section would be a good fit.

[jreimone]

@rajbos good point regarding the documentation 👍 I added it accordingly.

[dan-mm]

Hi - I took a look at it today and it looks good! Also thank you for merging in my latest changes from main already :-D

In terms of the flag, I agree that to the user they won't see any difference, however my main reason for wanting a flag is simply to save on energy. The JSON is still being created even if the user has no need for it, and as this is an action meant to promote carbon awareness, I would prefer that functionality that is extra be opt-in to save on cpu cycles.

That being said, I do see the detriment of having a flag for every little thing in terms of usability, and as we already have our data-sending on by default (and one can make the argument that is also an extra functionality), I'm not sure where the line should be on this. So I will merge this in, and think more on if I want it hidden behind a flag, and can add that in myself later.

[dan-mm]

just a small note that escaped my original testing:

The call to the scripts have to use ${{github.action_path}}/.github/scripts instead of ./.github/scripts -> otherwise the script won't be found when used in other repositories. I fixed that on the main branch

[jreimone]

Hi @dan-mm, thank you for merging and adjusting the call of the script paths 🙏 I tried it out in my private repo and it works like a charm 🤗 From my end this ticket can be closed. Since @rajbos created the ticket the author should close it.

[rajbos]

Awesome!