Implement workflow to create GitHub release with attached git installers

[vdye]

Changes

• Create a new tag-triggered workflow for building Windows/Mac OSX/Ubuntu installers/packages & creating a draft release with those installers/packages
  • By creating a draft release, release notes can still be written manually & release can be published on-demand
  • Generates unsigned artifacts in repositories without appropriate secrets, but will sign when secrets are present

Testing

• Actions execution (unsigned workflow): https://github.com/vdye/git/actions/runs/1045722272
• Generated (then manually published) release: https://github.com/vdye/git/releases/tag/v2.32.0.vfs.test.2

References

• Prior draft pull request: odb--daemon: implement get-parent and get-ancestor commands vdye/git#2

[ghost]

All CLA requirements met.

[dscho]

This looks good!

I have a couple suggestions for the next steps:

• Please tag the tip of your branch using a tag name that matches the pattern (e.g. v2.32.0.vfs.0.123) and push to this repository (you should have write permissions). That will give us a test run with a draft release as something we can look at.
• Since we will be forward-porting these patches with every rebase to every new Git for Windows version, I think it would make sense to prefix the commit messages with some sort of catchy "area" (and then continue in lower-case as is upstream Git's custom), e.g. "release: create initial Windows installer build".
• The first five commits are structured really well, I think. The commits starting with ab7655f look a bit like fixups to me. Would you mind squashing those changes into the appropriate commits?
• Regarding the secrets, I wonder whether we want to create a new workflow environment and install them there, then protect the environment by adding our team as require reviewer. That way, it is not enough to simply push the tag, but a member of our team has to approve the run, reducing the likelihood of those secrets being leaked inadvertently. In preparation for that, I created the build-git-installers environment (but if we decided that we don't want it, we can always delete that environment later). As far as I understand, all that needs to be done is to add environment: build-git-installers to the jobs (unfortunately, it has to be done individually for every job that requires access to those secrets and cannot be configured on the workflow level, on the upside, this would allow us for finer-grained control where e.g. the ubuntu jobs have no access to the code-signing certificate, but it is probably not worth the effort in our context).

[derrickstolee]

Looks good. I mostly pointed out things that caught my eye, but don't actually need to change.

[derrickstolee]

This is a clever way to quickly check the tag matches the compiled Git version.

[derrickstolee]

Put this on the list of something we could update in our fork of git_osx_installer, but this is a good workaround for now.

[derrickstolee]

Action item for later: we have also been including the PDB files with our releases, on the off chance that we need to do a perf investigation with PerfView.

[vdye]

The PDB files included in microsoft/git releases (example) differ from those included in git-for-windows/git releases (example) - it looks like git-for-windows/git includes PDBs for external dependencies as well. Which set should be included here?

[derrickstolee]

I'll defer to @dscho here. I've only needed the PDBs for Git and not the rest. Further, our Azure Pipelines build only generated those PDBs. We should also be able to leverage the PDBs from git-for-windows/git if we ever need to go into those dependencies.

[vdye]

If it's alright with you, I'll open a separate issue for this - minor changes are needed in git-for-windows/build-extra to include the PDBs in the installer (since this is built slightly differently than in the existing Azure DevOps pipeline) .

[derrickstolee]

That works for me. Incremental progress is important.

[vdye]

@dscho since I can't reply directly to your comment:

Please tag the tip of your branch using a tag name that matches the pattern (e.g. v2.32.0.vfs.0.123) and push to this repository (you should have write permissions). That will give us a test run with a draft release as something we can look at.

Tagged v2.32.0.vfs.0.123 - triggered successful execution of build-git-installers, which created a draft release with the relevant artifacts.

• Since we will be forward-porting these patches with every rebase to every new Git for Windows version, I think it would make sense to prefix the commit messages with some sort of catchy "area" (and then continue in lower-case as is upstream Git's custom), e.g. "release: create initial Windows installer build".
• The first five commits are structured really well, I think. The commits starting with ab7655f look a bit like fixups to me. Would you mind squashing those changes into the appropriate commits?

Both of these items are done/addressed

Regarding the secrets, I wonder whether we want to create a new workflow environment and install them there, then protect the environment by adding our team as require reviewer. That way, it is not enough to simply push the tag, but a member of our team has to approve the run, reducing the likelihood of those secrets being leaked inadvertently. In preparation for that, I created the build-git-installers environment (but if we decided that we don't want it, we can always delete that environment later). As far as I understand, all that needs to be done is to add environment: build-git-installers to the jobs (unfortunately, it has to be done individually for every job that requires access to those secrets and cannot be configured on the workflow level, on the upside, this would allow us for finer-grained control where e.g. the ubuntu jobs have no access to the code-signing certificate, but it is probably not worth the effort in our context).

The secrets used in this job were all pre-existing at the repository level and are used in other workflows (git-artifacts.yml & release-apt-get.yml). If we do move the secrets to workflow environments, all of the workflows should probably be changed at once to make it easier to move the credentials - I'll open an issue for it (if you're not opposed to that change being part of a separate pull request).