Provide library version in analytics

[defagos]

As an SRG analytics team member I want media player version information to be obtained from analytics.

Acceptance criteria

• Media player name and version are provided to comScore.
• Media player name and version are provided to Commanders Act.

Tasks

• [x] Extract version number associated with tag (or commit) using git describe --tags in an SPM plugin.
• [x] Ensure plugin files are linted as well.
• [x] Provide information to comScore.
• [x] ~Provide information to Commanders Act.~

[defagos]

I made a proposal on the 333-provide-library-version-in-analytics-alternative branch. It is based on the idea linked above, but with several improvements.

Here are the main implementation ideas:

• The plugin executes a pre-build command, which is the recommended way for code generation according to the WWDC talk. I suspect that doing too much work in the plugin itself might be an issue in the future, as the plugin is supposed to bridge to executable commands. Doing less work in the plugin is therefore likely more robust in the long term (we don't want the mechanism to break with later Xcode updates).
• This pre-build command executes a binary target which extracts version information from the git history and generates a Swift source file containing it. Several options were investigated since a binary is not strictly required:
  • A Swift compiled binary, which is not really practical as it requires pre-building binaries first.
  • A Swift script which calls git with a shell process. Sadly the result depends on the shell used and might contain a newline which needs to be trimmed. Moreover calling a shell command this way feels unnecessarily complicated IMHO.
  • A shell script which is easy to write. This is the solution that works best and the one retained by the linked repository above. It is also easy to use further commands to enhance metadata delivered in the generated Swift file.
• The shell script is provided using an artifact bundle. Unlike zipped targets we can therefore clearly see the source code and avoid a zip step which would be annoying to implement. The shell can also be updated directly.
• The shell script requires two arguments, the repository to extract the information from as well as the output directory, which is provided by the plugin for source file generation directly. We therefore follow the sandboxing limitations by only using current target context information and the writable location for generated source files.

Note that a Swift executableTarget was also investigated (since this is the approach mentioned in the WWDC talks) but compiled executables are currently not supported. Information extraction would also have been more verbose since calling a shell command with Swift involves more code than direct shell execution.