feat: add new emit-metrics action

[ianbotsf]

Issue #, if available:

(none)

Description of changes:

Creating the emit-metrics action to invoke kat metrics emit ... in workflows.

I've created a test-emit-metrics workflow which I'll delete before merging the PR. It shows how the action can be invoked as a step:

steps:
  - ...
  - ...
  - name: Emit some test metrics
    uses: ./.github/actions/emit-metrics
    with:
      namespace: Test Namespace (ignore me)
      dimensions: |
        Artifact=foo-artifact
        Platform=Kotlin/JVM
        Variant=External
      metrics: |
        BuildTime:4.532:Seconds
        BuildSucceeded:1:Count

Example output from succeeding run:

Executing command "kat metrics emit --namespace "Test Namespace (ignore me)" --dimension "Artifact=foo-artifact" --dimension "Platform=Kotlin/JVM" --dimension "Variant=External" --metric "BuildTime:4.532:Seconds" --metric "BuildSucceeded:1:Count""

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[lauzadis]

nit: "from another workflow/action" is implied, could be "Emit metrics using that kat tool"

[lauzadis]

Should dimensions be required? They are not marked as .required() in our kat tool's clikt configuration

[ianbotsf]

Oh whoops. Yes, they should be required. I cannot think of any instance in which we would not contextualize our metrics with at least one dimension. I'll update the kat tool accordingly.

[lauzadis]

Can this script also support space-delimited dimensions? I don't see a reason to require delimiting with newlines

[ianbotsf]

I think the challenge in using spaces for delimiting is that dimension names/values can include spaces too. Parsing could then become ambiguous in situations like this:

Foo=Bar Operating System=Microsoft Windows Baz=Qux

It's not possible to determine whether Foo=Bar or Foo=Bar Operating, etc.

Do you foresee problems with newline delimited dimensions/metrics?

[lauzadis]

No I think this should be fine, it just stood out to me on the initial review

[lauzadis]

This task should first check if the kat tool has been properly set up, and return an error if it's not available

[lauzadis]

Is there a way we can idempotently invoke the setup-kat action? Then we can invoke it everywhere we use kat to ensure it's set up correctly

[ianbotsf]

I looked but didn't find an way to run an action (e.g., setup-kat) only when it hasn't already been run. I suppose we could modify setup-kat to be idempotent by seeing if kat is present already in the path. But setup-kat itself requires aws-actions/configure-aws-credentials to have been run as well, for which we cannot so easily control idempotency.

Let me play with some options and see if we can do better.

[ianbotsf]

OK I was able to add kat verification to the action. I could probably cheese credentials verifications too but I've filed a feature request to add idempotency to configure-aws-credentials and I think that'll be the better approach long-term.

[lauzadis]

I'm curious to see how these metrics strings will be formed in our real CI, particularly the values. Maybe using environment variables?

[ianbotsf]

I think in practice, the specific metrics names/types and dimension names will be static. The metric/dimension values will likely be dynamic based on available context. Env variables are an interesting idea. Are you suggesting we could accumulate metrics and dimensions in env vars or other context during a workflow and then emit them all in a final step without explicitly re-enumerating them?

[lauzadis]

Yes the metric values will need to be dynamic, so I was imagining you would set an env var while executing the build-related portions of CI, then read them back in the subsequent emit-metrics step