Fix artefact hash discrepancy for WinGet release

[jjw24]

Context:
Currently project is rebuilt and output artefacts re-uploaded after marking a draft release as latest. This creates a discrepancy for WinGet publish process. #2086

Solution:
Tag is created after marking a draft release as prerelease or latest. No need to upload the artefacts again on tag.

If changes need to occurr during release process, delete draft then merge new changes in.

Related #2185

[github-actions]

@check-spelling-bot Report

🔴 Please review

See the 📂 files view or the 📜action log for details.

Unrecognized words (1)

occurr

To accept ✔️ these unrecognized words as correct and remove the previously acknowledged and now absent words, run the following commands

... in a clone of the git@github.com:Flow-Launcher/Flow.Launcher.git repository
on the fix_release_dup_hash branch (ℹ️ how do I use this?):

curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/main/apply.pl' |
perl - 'https://github.com/Flow-Launcher/Flow.Launcher/actions/runs/5450537806/attempts/1'

To have the bot do this for you, reply quoting the following line:
@check-spelling-bot apply updates.

If the flagged items are 🤯 false positives

If items relate to a ...

• binary file (or some other file you wouldn't want to check at all).

  Please add a file path to the excludes.txt file matching the containing file.

  File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.

  ^ refers to the file's path from the root of the repository, so ^README\.md$ would exclude README.md (on whichever branch you're using).

• well-formed pattern.

  If you can write a pattern that would match it,
  try adding it to the patterns.txt file.

  Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines.

  Note that patterns can't match multiline strings.

[JohnTheGr8]

I'm quite sure the first Github deployment job will still run on tag CI builds and update the artifacts of the release. Therefore this does not solve the Winget issue...

See for example this CI job for tag v1.15.0

If you see the very end of the log, it is updating the existing v1.15.0 release artifacts on github, twice.

[JohnTheGr8]

Perhaps a simpler temporary solution would be to switch the winget release action to manual only? And trigger it manually when both appveyor jobs have finished...

[jjw24]

Ah yes, does look like the case.

Yes lets change the WinGet action to manual temporarily.