Automatic update of Ubisoft.Connect from 135.0.0.10753 to 135.1.0.10758
Automation detected that manifest Ubisoft.Connect needs to be updated Reason:
- Installer(s) found with hash mismatch.
Microsoft Reviewers: Open in CodeFlow
/AzurePipelines run
Azure Pipelines successfully started running 1 pipeline(s).
Hello @wingetbot!
Because this pull request has the Validation-Completed label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.
p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.
wingetbot,
The check-in policies require a moderator to approve PRs from the community.
Our moderators are community volunteers, please be patient and allow them sufficient time to review your submission.
Template: msftbot/requiresApproval/moderator
Hello @wingetbot,
The package manager bot determined changes have been requested to your PR.
Template: msftbot/changesRequested
@trenly, as winbot that created the PR, I don't think it can review your changes, Right @denelon? What happen in those cases?
@Trenly, as winbot that created the PR, I don't think it can review your changes, Right @mdanish-kh? What happen in those cases?
You're correct. I put them there just as a note for whoever happens to be dealing with this. What needs to happen is that a new PR needs to be created with the correct values that will close this one
@Trenly problem is, what caused this difference? winbot could do again in the next update. Need to fix the root cause
@Trenly problem is, what caused this difference? winbot could do again in the next update. Need to fix the root cause
Wingetbot uses the version written in the ProductVersion field of the installer -
PS D:\Git\winget-pkgs> $f = New-TemporaryFile
PS D:\Git\winget-pkgs> iwr 'https://ubistatic3-a.akamaihd.net/orbit/launcher_installer/UbisoftConnectInstaller.exe' -OutFile $f
PS D:\Git\winget-pkgs> (Get-Item $f).VersionInfo
ProductVersion FileVersion FileName
-------------- ----------- --------
135.1.0.10758 135.1.0.10758 C:\Users\Trenly\AppData\Local\Temp\tmp50AC.tmp
The issue is that not all publishers set this correctly, where they set it to something other than the version that is written to control panel. It's an issue for more than just this package. As of right now, Wingetbot has no way to get the value that is actually written to control panel for exe installers, as it requires running the installer, capturing the registry changes, and trying to match which registry entry is actually the one for the package since some packages install sub-components
I'll see if @stephengillie has thoughts on this.
I'll see if @stephengillie has thoughts on this.
A full solution to having these versions match the Control Panel, such as modifying or standardizing version number handling across development and install, might be beyond the current scope of this team. For this application, if the 3rd version number is always a zero which is omitted from the Control Panel version, a regex replacement (or something similar) could be a fix here but may be inelegant. Another solution could be capturing registry changes during validation, but as @Trenly said this is complicated by sub-component install. Depending on the frequency of this issue, a mid-level solution could be maintaining a version regex table, showing how to modify a given application's version number to match the Control Panel.
@stephengillie - I would say this is mildly frequent. There is https://github.com/microsoft/winget-pkgs/issues/34421 which is related, but probably bigger than the scope of a regex table. If there are any plans to bring github automation like Vedant's to a MSFT hosted service, though, a regex table or similar mapping will certainly be needed
All the above are just within the past week. Looking over the course of multiple weeks, it does tend to be a bit of a pain point
I'm new to this, so thank both of you
So let's take a step back. This PR was made from wingebot. How the bot, or who else, can approve these changes @Trenly did? How come we can make this work with the code we have now @stephengillie?
I'm new to this, so thank both of you
So let's take a step back. This PR was made from wingebot. How the bot, or who else, can approve these changes @Trenly did? How come we can make this work with the code we have now @stephengillie?
Take a look at https://github.com/microsoft/winget-pkgs/issues/35373; It provides some additional background on what has already been considered, as this isn’t exactly a new problem
Publish pipeline succeeded for this Pull Request. Once you refresh your index, this change should be present.