Provide a mechanism to add arbitrary fields to the Honeycomb event

[kvrhdn]

buildevents allows you to provide arbitrary key-value data using the BUILDEVENT_FILE environment variable. gha-buildevents uses this to send metadata about the GitHub Actions workflow.

We should provide a mechanism to allow users to provide additional fields.

This syntax would be great:

- uses: kvrhdn/gha-buildevents@master
  with:
    apikey: ${{ secrets.APIKEY }}
    dataset: my-dataset
    additional-fields:
      buildVersion: BUILD_VERSION
      project: my-project
      ...

[kvrhdn]

It could be interesting to allow steps to add to this file as well. I.e. in case we make a gha-buildevents-step:

- uses: kvrhdn/gha-buildevents-step@master
  with:
    name: My step
    additional-fields:
      buildResult: success

[DavidS]

That would be great! As it stands, even trying to used the buildevent file is not really reliable as some spans don't pick up the values.

[kvrhdn]

I currently don't have any bandwidth to work on this, but I'll leave some notes here for anyone that wants to pick this up.

This issue can be divided into two problems:

1. we need a mechanism to pass arbitrary fieds to the action
2. we need a mechanism to pass these fields to the buildevents binary

For 2) we already have some infrastructure in place: buildevents already reads a file buildevents.txt that contains values in the logfmt format.
This file is created here:

• https://github.com/kvrhdn/gha-buildevents/blob/5be4636b81803713c94d7cb7e3a4b85d759df112/src/index.ts#L54-L72
• https://github.com/kvrhdn/gha-buildevents/blob/5be4636b81803713c94d7cb7e3a4b85d759df112/src/buildevents.ts#L30-L33

For 1) there is currently no solution. Additionally, I think the action inputs are currently limited to strings only. So the following is not possible:

- uses: kvrhdn/gha-buildevents
  with:
    # snip
    additional-fields:
      - app: my-app
      - version: 0.0.1

Instead, we'll have to pass a text block I think:

- uses: kvrhdn/gha-buildevents
  with:
    # snip
    additional-fields: |
      app=my-app
      version=0.0.1

But... can we validate this? (Do we have to validate this?)

I did something similar in my tfe-run action to pass a list of variables to Terraform:

• https://github.com/kvrhdn/tfe-run/blob/b4d4b27940dcd146b357724817ea8e3ffd01fee7/action.yaml#L54-L57
• https://github.com/kvrhdn/tfe-run/blob/b4d4b27940dcd146b357724817ea8e3ffd01fee7/.github/workflows/integration.yaml#L33-L34

[DavidS]

I was thinking about a simpler alternative: #18 changes the addFields method to not unconditionally overwrite the BUILDEVENT_FILE. That way folks can add to that without issues.

[kvrhdn]

I was thinking about a simpler alternative: #18 changes the addFields method to not unconditionally overwrite the BUILDEVENT_FILE. That way folks can add to that without issues.

Yeah, I think this will work well. gha-buildevents will only create a buildevents.txt file in the post section. So you are free to create your own file and override the env var BUILDEVENT_FILE until then.
I can envision there might be an issue if we create a file at the start of the build and a user later sets a different value in BUILDEVENT_FILE.

[DavidS]

I can envision there might be an issue if we create a file at the start of the build and a user later sets a different value in BUILDEVENT_FILE.

Oh, that's a good point, I didn't consider this case. It might be worthwhile pointing that out in documentation that it's recommended to "set and forget" the value for BUILDEVENT_FILE at the very top-level to avoid any weird interactions. Given that I'd expect most folks to use a top-level env: key to set this, I'm not too worried.