introduce posthog

[zreigz]

Summary

Introduce posthog for plural bundle install, build, and deploy commands.

client.Enqueue(posthog.Capture{
  DistinctId: "someID",
  Event:      "cli_deploy",
  Properties: map[string]interface{}{
        "clusterName":        "test-cluster",
        "applicationName":    "bootstrap",
        "applicationID":      "123456-abcdef"
        "packageType":         "Helm",
        "packageName":         "bootstrap",
        "packageId":           "123456-abcdef",
        "packageVersion":      "0.1.0",
        "provider":           "AWS",
        "error":              "some error about the helm install failing",
    }
})

Labels

Test Plan

Checklist

• If required, I have updated the Plural documentation accordingly.
• I have added tests to cover my changes.
• I have added a meaningful title and summary to convey the impact of this PR to a user.
• I have added relevant labels to this PR to help with categorization for release notes.

[michaeljguarino]

We should send this info from the server if we want it in posthog, having the cli send it is error prone and could potentially cause failed installs

[davidspek]

We can't track the actual commands users execute server side since it doesn't know when somebody runs plural deploy. Having it in the CLI allows us to have a better metric of which commands people run, how often they run, and if they encountered an error when running the command. This can give us a metric of how many successful deploys have happened versus how many errors have occurred. It can also give us a timeline of a user's actions. For example, user deploys but runs into an error for app X, user then runs install to change a config and build for app X to fix that config, user then runs deploy again and it runs successfully.

Each command that a user executes and if it passes or fails is very important data so we can have a better idea of how many command executions pass versus fail and where they fail exactly.

[michaeljguarino]

Similarly, this is better to send server-side

[michaeljguarino]

should we just add this to our existing error logging wrapper?

[zreigz]

done

[zreigz]

I have moved error handling to tracked validator