CI: add git commit hash to file description of uploaded SITL log

[JohannesBrand]

This pull request adds the hash of the current git commit to the description field of the log file uploaded to PX4 flight review during CI.

Why?
better traceability of PX4 SITL logs uploaded to flight review.

This pull request makes use of the GIT_COMMIT environment variable described in the Jenkins wiki. According to the wiki all the GIT_* variables require the git plugin. Hence, this pull request might not work, if the git plugin is not available.

[dagar]

Doesn't seem to be working?

[dagar]

Not working?
https://logs.px4.io/plot_app?log=70c1660c-5499-442a-badb-a7d0c47a48e0

[JohannesBrand]

@dagar do we have the git plugin installed in jenkins? I think the GIT_COMMIT environment variable is probably not set and according to the jenkins documentation it is only set if the plugin is installed. Here is a guide to install the plugin: git plugin

But, if this is a lot of effort I'll look for another way to track the git commits.

[lamping7]

@JohannesBrand We have git plugin 3.10.0 installed and this env var was made available in 3.2.3 according to the issue in Jenkins Jira.

That said, this doesn't work the way you would expect it to (Jenkins is a tricky beast to wrap your head around). The way this works is: as one stage, a slave (ec2 machine) fetches the firmware from git, builds it and packages it (it gets archived and pushed over to the Jenkins master machine). Then, different (most likely) slaves grab that package and run the simulation. Because there is no checkout step in the SITL stages, there are no scm env variables available and the SITL slaves have no knowledge of what happened with git.

So, there are a couple different ways to tackle this if we want it. I have a good handle on possibilities if help is needed.

[JohannesBrand]

@lamping7 cool, thanks. I thought I'd just use some simple command line scripting but this sounds more complicated. what are the options you're thinking about?

[lamping7]

Because this pipeline is scripted, you could define a global groovy variable up top, set the variable from the agent that does the checkout operation in the build stage, then the subsequent stages should have access to it. I'm not sure if that's clear. If not, let me know and I can PR this.

In a declarative pipeline I think you'd need to perform a checkout step in each stage, which is mostly a waste of time, but would give you the info you need.

As a side note, the ASan and coverage run the same tests, but with different purposes. I'm not sure if we need this for those. Additionally, I'm not sure why we push those runs to flight review. Essentially we're pushing the same test 3 times. But, changing this is out of scope here and more of a question for @dagar.

[JohannesBrand]

@dagar @lamping7 actually, I noticed the git hash is stored in the log and the software version is exposed by flight review -> hence this pr is not necessary. Thank you for your help anyways. I'll close this pr now.