build-git-installers: Ubuntu bugfix, Windows features

[vdye]

Changes

• Set explicit version (18.04) for Ubuntu artifact build
  • ubuntu-latest was version 21.04 - caused errors when installing the package on older OS versions
  • Now matches the version built in the Azure DevOps pipeline
• Forward-ported features from the Windows build in the Azure DevOps pipeline (all done by modifying the install.iss file used to build the installers)
  • Re-target auto-update to microsoft/git
  • Set the app publisher to "The Git Fundamentals Team at GitHub"
  • Let the installer configure Visual Studio to use it
  • Enable scalar in the auto-updater by default

Testing

• Ran pipeline, artifacts found here: https://github.com/vdye/git/actions/runs/1148450866
• Verified app publisher update:
  
• Verified Visual Studio registry values were set on install and removed on uninstall (manual checks in Registry Editor)

[dscho]

Set explicit version (18.04) for Ubuntu artifact build

* `ubuntu-latest` was version 21.04 - caused errors when installing the package on older OS versions

* Now matches the version built in the Azure DevOps pipeline

Maybe we could include that information in the fixup! commit message? And while at it, enhance on it by saying that it allows the artifacts to be used both on Ubuntu 18.04 and 21.04?

[dscho]

This looks good.

At some stage, we might want to move bits and pieces from the build-git-installers workflow to shell scripts in ci/, but we don't really have to.

[vdye]

Unrelated to the changes in this PR, but this is now the second time I've noticed it - when I force-push an update that contains no code changes since the last push, the merge checks on the pull request get stuck waiting for "expected" checks that never happen because the trigger for them is skipped.

What's the right way to handle this? I could delete the previous builds for these changes then re-trigger this pipeline (which will force re-running all checks), but that seems like an inefficient workaround.

[derrickstolee]

Unrelated to the changes in this PR, but this is now the second time I've noticed it - when I force-push an update that contains no code changes since the last push, the merge checks on the pull request get stuck waiting for "expected" checks that never happen because the trigger for them is skipped.

What's the right way to handle this? I could delete the previous builds for these changes then re-trigger this pipeline (which will force re-running all checks), but that seems like an inefficient workaround.

In these cases, we can just merge with admin privileges. We need a way to have "skipped because known good" mean "passed".

[dscho]

The fault is mine: there is a step in the workflow that tries to figure out whether a previous build with the same commit (or a tree-same commit) passed. If it finds such a build, it skips the entire build.

GitHub's UI does not allow us to accommodate for this: naturally, the jobs will have been skipped, and therefore the "required!" flags will prevent the PRs from being merged just like that.