Heads Up: New feature in Bonsai for asset developers

Sensu Go
1

What?
We’ve introduced a build/ Bonsai api endpoint that you can use in a GitHub action and are deprecating the the automatic Bonsai webhook that Bonsai adds to a repository when you register an asset for the first time.

Why?
Bonsai was originally developed to use a GitHub webhook, but we discovered the the webhook approach is racy with the GitHub release process. The GitHub event we were relying on happens before all the asset binaries are uploaded into a GitHub release… and we never found a way to have a webhook event fire after release build upload was completed. We would have preferred to stick with the webhook approach…but after investigation it just doesn’t seem possible to have a webhook event fire after all the release binaries are added to a release. If someone can figure out how to have a GitHub Action trigger a webhook event at the end of the build upload process, I want to talk to you. I’d love to see the webhook feature come back as the primary means of firing off Bonsai version recompiles as its a much more automated process when it works.

The webhook process is still alive, but its deprecated. We are planning on disabling automatic webhook configuration for newly registered assets at some point once we feel the new build api process is working well (Or we find a way to make the webhook no longer race…if someone can help with that)

You want to try it now?
To use the bonsai build api for a registered asset in your GitHub actions, you’ll need to do 3 things:

  1. Disable the bonsai webhook in your GitHub repository settings. You don’t need to delete it, just deactivate it.

  2. Add a personal access token for a GitHub user account that has collaborator status on the repository, someone with commit or admin access to the repo.

  3. Add a new workflow that calls the new bonsai build api and uses the personal access token

Here’s an example GitHub Actions that works for golang based plugins that use the goreleaser workflow to populate the a GitHub release with asset builds using a personal access token saved as a repository BONSAI_GITHUB_TOKEN secret.

name: Bonsai Request Rebuild

on:
  workflow_run:
    workflows:
      - goreleaser
    types:
      - completed

jobs:
  bonsai-build:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - name: request bonsai rebuild
        run: >
          curl -v -XPOST
          -H "X-GitHub-Token: ${{ secrets.BONSAI_GITHUB_TOKEN }}"
          --url "https://bonsai.sensu.io/assets/${{ github.repository }}/build"

Note: We can’t use the GitHub Actions generated token, because the generated token doesn’t map back to a user that we can ask has collaborator status on the repository. We want to continue to limit build requests to collaborators (or automation). I’m still looking for a way to discover if a GitHub token is issued by GitHub Actions token for a specific repository via a GitHub API call, but so far I haven’t found a good way to programmatically test if a token is a GitHub Actions token and I don’t want random access tokens with read ability for a public repo to fire off Bonsai recompile requests, so I’m being more cautious about relaxing the collaborator auth logic in production Bonsai until I’ve done more tests with GitHub Application tokens that are not associated with a user.