Adding an option to track the build's branch

[schlagelk]

Hi!

I would love the ability to know if a build is associated with a specific git branch, as this would help me analyze improvements or regressions in build times which may be coming in on new PRs. Happy to propose an implementation if this is a welcomed addition.

Thanks!

[frandelarosa]

+1 for this improvement!

[BalestraPatrick]

This is a good suggestion, fully agreed. We built XCMetrics with a plugin system so that you would be able to attach custom metadata to the information sent. But we also realize that there's a set of metrics that would be useful for people not to reimplement over and over again in separate plugins. There are a couple of ways to address this:

• Include the git branch (and maybe other basic info about the git status) in a new field inside XCMetrics. This would probably cause the backend to have to migrate all existing tables due to the fact that a new field was added. We would need to evaluate this properly before making a decision to go down this route.
• A second approach could be to provide standard implementations for common plugins directly in this repo. This would maybe look like a new package called XCMetricsPlugins that would containd default implementation for common plugins that people may want to use. You could then create your own custom version of XCMetrics (as described here).

I like the second option because this avoids adding all kind of configuration flags to the main XCMetrics tool such as --git_dir because some people may or may not want to provide/collect those information.

Maybe the rest of the team (@ecamacho @polac24 @aleksandergrzyb) have more opinions on the best way to approach this.

[BalestraPatrick]

To add some more details, we are internally tracking a few information other than just the git branch name, which should be possible to do if we go with the second approach:

• user_email (this would be fully redacted or semi-redacted via hashing)
• branch
• branch_created_at
• dirty
• sha
• describe

[ecamacho]

I think it makes sense to go with the second approach. We will need new package to have the plugins sooner or later. And this is the perfect case to start with. And also the thermal throttling one that we provide in the documentation.

[BalestraPatrick]

Fixed by #15 so I'll close this. Thanks @schlagelk!