ReportUploadTask - revision variable with multiple git repositories

If a azure devops pipeline uses multiple git repositories the content of the Build.SourceVersion variable is set to different values depending what triggers the pipeline.

For example in a typical setup:

• an infrastructure repository which contains the .yaml file of the pipeline definition
• another repository containing the 'main' source code

Triggers and the values of Build.SourceVersion:

• If the pipeline is triggered manually -> SourceVersion is set to the commitId of the head of the infrastructure repository
• If the pipeline is triggered by a code change in the infastructure repository -> SourceVersion is set to the commitId of the change in the infrastructure repository
• If the pipeline is triggered by a code change in the 'main' repository -> SourceVersion is set to the commitId of the change in the main repository

Result:
If a pipeline is triggered manually or by a change of the pipeline itself the reportUploadTask uses the 'wrong' commitId and the task will fail.
curl: (22) The requested URL returned error: 400 Bad Request ##[error]Task failed. Please check the log for further details. Error: The process 'TeamscaleReportUploader_xxx\1.2.5\curl\windows\curl.exe' failed with exit code 22

Possible solutions:

• If the revision variable would be exposed as an input field of the task pipelines could set the correct revision themselves
• Identify the revision by getting the checked out commit with git tooling

Start at the ReportUploadTask entry point and trace how Build.SourceVersion is selected for manual, infrastructure-repository, and main-repository triggers. Compare that value with the checked-out commit and the task's revision input handling. Done means the upload uses the correct commit for each trigger scenario without producing the reported 400 error.