BUG: WinGet release uploads with the wrong hash
See original GitHub issueChecks
-
I have checked that this issue has not already been reported.
-
I am using the latest version of Flow Launcher.
Problem Description
WinGet release uploads with the wrong hash, most likely due to dual release steps in the appveyor.yml on merge to master.
https://github.com/microsoft/winget-pkgs/pull/103060#discussion_r1173218090
To Reproduce
- …
- …
- …
Screenshots
No response
Flow Launcher Version
0
Windows Build Number
0
Error Log
Replace this line with the important log contents.
Issue Analytics
- State:
- Created 5 months ago
- Comments:12 (10 by maintainers)
Top Results From Across the Web
Cannot override installer hash as admin. Even if ...
Yes, when I use --force I get the following error still: "Installer hash does not match; this cannot be overridden when running as...
Read more >Winget upgrade -- bad hash
I just tried to update XnViewMP via winget (Windows 11) and got the error message "Installer hash does not match.
Read more >Submit your manifest to the repository
Go to https://github.com/microsoft/winget-pkgs in your browser and select Fork. ... Error-Hash-Mismatch, The submitted manifest could not be ...
Read more >My app receives "Installer hash does not match"
My application gives the error "Installer hash does not match." c:> winget install --accept-source-agreements --id IDHERE. Where can I update ...
Read more >Windows package manager installation error - Support
the windows package manager offers a mp3tag installation but that is not working quite right C:\Users\typ_xxi\Downloads>winget install ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yes this would be the goal.
I suppose setting it to
APPVEYOR_REPO_TAG: false
makes sense if the previous steps do not create a tag, but if a tag is created when a draft release is created, I do not think this entire step is necessary. I do not know if this is the case that the tag is created before this step, so please test when working on this issue.This issue was closed because it has been stale for 7 days with no activity. If you feel this issue still needs attention please feel free to reopen.