-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KDE.Dolphin.Nightly #33717
KDE.Dolphin.Nightly #33717
Conversation
Rectification of the version of KDE.Dolphin.Nightly, and replacement of the URL for the installer with a version that is much more easy to maintain, but shall not cause submission of invalid installers.
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
Hello @BEEDELLROKEJULIANLOCKHART, Please verify the manifest file is compliant with the package manager 1.0 manifest specification. You could also try our Windows Package Manager Manifest Creator Preview. For details on the specific error, see the details link below in the build pipeline. |
@@ -2,15 +2,15 @@ | |||
# yaml-language-server: $schema=https://aka.ms/winget-manifest.installer.1.0.0.schema.json | |||
|
|||
PackageIdentifier: KDE.Dolphin.Nightly | |||
PackageVersion: master-b6ec4b1c9 | |||
PackageVersion: master-271 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be the same as the version in the ARP entries, which in this case is master-b6ec4b1c9
, so the original manifest is correct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@KaranKad you beat me by mere seconds 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please do observe http://github.com/microsoft/winget-pkgs/pull/33717#issuecomment-959212573.
Scope: machine | ||
InstallModes: | ||
- interactive | ||
- silent | ||
Installers: | ||
- Architecture: x64 | ||
InstallerType: nullsoft | ||
InstallerUrl: https://binary-factory.kde.org/job/Dolphin_Nightly_win64/271/artifact/dolphin-master-271-windows-msvc2019_64-cl.exe | ||
InstallerUrl: https://binary-factory.kde.org/view/Windows%2064-bit/job/Dolphin_Nightly_win64/lastSuccessfulBuild/artifact/dolphin-master-271-windows-msvc2019_64-cl.exe |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are previous versions of nightly builds removed? If they are, then using the last successful build is good. If they are not, then we should keep using the specific build numbers to maintain the version history and keep previous versions available through winget
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason that I have specified "/lastSuccessfulBuild/" is because if "/lastSuccessfulBuild/" is used, the logic that is required for automatic replacement by new versions is much more simple, because the name of the version is part of the filename, so also switching directories is quite silly. This should not prevent operation any current functionality of winget.
If this explanation is sufficient, please do resolve it or instruct me to resolve it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are for KDE projects. These are hard to maintain because the file name changes too.
It's the value they are putting in the Add and Remove Programs table, which is how winget knows to upgrade something (given that it's text and not a number I don't know if the comparison algorithm will work correctly here, but that's how it works). We need to use that value for |
Scope: machine | ||
InstallModes: | ||
- interactive | ||
- silent | ||
Installers: | ||
- Architecture: x64 | ||
InstallerType: nullsoft | ||
InstallerUrl: https://binary-factory.kde.org/job/Dolphin_Nightly_win64/271/artifact/dolphin-master-271-windows-msvc2019_64-cl.exe | ||
InstallerUrl: https://binary-factory.kde.org/view/Windows%2064-bit/job/Dolphin_Nightly_win64/lastSuccessfulBuild/artifact/dolphin-master-271-windows-msvc2019_64-cl.exe |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
InstallerUrl: https://binary-factory.kde.org/view/Windows%2064-bit/job/Dolphin_Nightly_win64/lastSuccessfulBuild/artifact/dolphin-master-271-windows-msvc2019_64-cl.exe | |
InstallerUrl: https://binary-factory.kde.org/view/Windows%2064-bit/job/Dolphin_Nightly_win64/271/artifact/dolphin-master-271-windows-msvc2019_64-cl.exe |
Why was this changed? lastSuccessfulBuild
in the URL is only valid for 1 day (24 hours), compared to having the build number in the URL which would last for about 4 or 5 days or a slightly bit more, before needing to be replaced.
If someone doesn't regularly update this like KDE Connect, people will be unable to download due to the expired URL. There will also likely be issue spam from @wingetbot when the URLs are unavailable if it's not updated in a timely matter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do observe "http://github.com/microsoft/winget-pkgs/pull/33718#discussion_r742010117" for explanation of why I am believing that this modification is advantageous.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please do observe "http://github.com/microsoft/winget-pkgs/pull/33717#issuecomment-959718502".
manifests/k/KDE/Dolphin/Nightly/master-b6ec4b1c9/KDE.Dolphin.Nightly.installer.yaml
Outdated
Show resolved
Hide resolved
…ightly.installer.yaml Co-authored-by: Levvie - she/her <[email protected]>
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
Scope: machine | ||
InstallModes: | ||
- interactive | ||
- silent | ||
Installers: | ||
- Architecture: x64 | ||
InstallerType: nullsoft | ||
InstallerUrl: https://binary-factory.kde.org/job/Dolphin_Nightly_win64/271/artifact/dolphin-master-271-windows-msvc2019_64-cl.exe | ||
InstallerUrl: https://binary-factory.kde.org/view/Windows%2064-bit/job/Dolphin_Nightly_win64/lastSuccessfulBuild/artifact/dolphin-master-271-windows-msvc2019_64-cl.exe |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HTTP?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HTTPS is always preferred over HTTP.
If the URL doesn't work with HTTPS (i.e. server isn't configured to be used for HTTPS), then you can use HTTP.
But this domain supports HTTPS.
Scope: machine | ||
InstallModes: | ||
- interactive | ||
- silent | ||
Installers: | ||
- Architecture: x64 | ||
InstallerType: nullsoft | ||
InstallerUrl: https://binary-factory.kde.org/job/Dolphin_Nightly_win64/271/artifact/dolphin-master-271-windows-msvc2019_64-cl.exe | ||
InstallerUrl: https://binary-factory.kde.org/view/Windows%2064-bit/job/Dolphin_Nightly_win64/lastSuccessfulBuild/artifact/dolphin-master-271-windows-msvc2019_64-cl.exe |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason that I have specified "/lastSuccessfulBuild/" is because if "/lastSuccessfulBuild/" is used, the logic that is required for automatic replacement by new versions is much more simple, because the name of the version is part of the filename, so also switching directories is quite silly. This should not prevent operation any current functionality of winget.
If this explanation is sufficient, please do resolve it or instruct me to resolve it.
@@ -2,15 +2,15 @@ | |||
# yaml-language-server: $schema=https://aka.ms/winget-manifest.installer.1.0.0.schema.json | |||
|
|||
PackageIdentifier: KDE.Dolphin.Nightly | |||
PackageVersion: master-b6ec4b1c9 | |||
PackageVersion: master-271 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -2,15 +2,15 @@ | |||
# yaml-language-server: $schema=https://aka.ms/winget-manifest.installer.1.0.0.schema.json | |||
|
|||
PackageIdentifier: KDE.Dolphin.Nightly | |||
PackageVersion: master-b6ec4b1c9 | |||
PackageVersion: master-271 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please do observe http://github.com/microsoft/winget-pkgs/pull/33717#issuecomment-959212573.
ARP == Add and Remove Programs table. It's winget's source of truth for all of the non-MSIX apps installed on the machine, and how it determines whether or not an upgrade is necessary. We need the version number to be whatever is in that table (until schema 1.1).
Using lastSuccessfulBuild breaks the links, and a find and replace on the link will fix all instances of the number anyway, so I don't know why having it in two places in the string is worse than having it in one place. |
Scope: machine | ||
InstallModes: | ||
- interactive | ||
- silent | ||
Installers: | ||
- Architecture: x64 | ||
InstallerType: nullsoft | ||
InstallerUrl: https://binary-factory.kde.org/job/Dolphin_Nightly_win64/271/artifact/dolphin-master-271-windows-msvc2019_64-cl.exe | ||
InstallerUrl: https://binary-factory.kde.org/view/Windows%2064-bit/job/Dolphin_Nightly_win64/lastSuccessfulBuild/artifact/dolphin-master-271-windows-msvc2019_64-cl.exe |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HTTPS is always preferred over HTTP.
If the URL doesn't work with HTTPS (i.e. server isn't configured to be used for HTTPS), then you can use HTTP.
But this domain supports HTTPS.
for anyone who cares: Jenkins has a pretty good API, I just wrote a little Python and can get all of the latest versioned nightly links. Shouldn't be too bad to automate this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the nightly builds released inconsistently? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the nightly builds released inconsistently?
If you're talking about all KDE apps included (Nightly + Release), then yes.
One release every day at 5 AM for KDE Kate - Release
One release every day at 10 PM for KDE Dolphin - Release
One release every day at 8 PM for KDE Connect - Release
One release every day at 2 AM for KDE Kate - Nightly
One release every day at 1 PM for KDE Dolphin - Nightly
One release every day at 10 AM for KDE Connect - Nightly
The timings of these are different for every single KDE app, this becomes difficult to use lastSuccessfulBuild
because the URL will no longer work when there's a new release of a KDE app.
So, what happens if the automation (either @wingetbot or vedant's automation) runs at, say 6 PM, and there's a new KDE release for say, Connect or Dolphin, packages that use lastSuccessfulBuild
will break easily and people will be unable to download until the automation catches up.
I have had to fix people's PR when they used lastSuccessfulBuild
, because the next day when I validated the PR - I got 404 Not Found and then some people will have to update the URL and Hash.
ResponseThis comment is response to "http://github.com/microsoft/winget-pkgs/pull/33717#pullrequestreview-796879170". Ideally, KDE should remediate this problem so that automatic replacement is less burdensome for the maintainers of package-managers that are similar to winget, and so that manual replacement shall be less frequent. Consequently, how best might this be remediated: should invalid request for packages that were, but not anymore, within "/lastsuccessfulbuild/" be resolved correctly automatically by "http://jenkins.io" or "http://binary-factory.kde.org"? This is worth remediating now, so that before more of KDE's software has been added to winget, this problem shall have become non-existent. |
One way to have the automatic update functionality that you're looking for would be to have a vanity url which always stays the same. That way the URL never needs to be changed, only the version does. What I mean by a vanity url is something like However, this is most definitely something that would need to be changed on KDE's end |
This comment is response to "http://github.com/microsoft/winget-pkgs/pull/33717#issuecomment-959828079". @Trenly, I have reported some of this problemage via "http://bugs.kde.org/show_bug.cgi?id=444894#c0". |
Hello @BEEDELLROKEJULIANLOCKHART, |
Close with reason: Merge Conflict + Package URLs change daily, and builds are not retained; |
Yeah, the currently present manifests are all 404. We'll just have to wait until a solution of provided, I suppose, or use different URLs (if any are available). |
Rectification of the version of KDE.Dolphin.Nightly, and replacement of the URL for the installer with a version that is much more easy to maintain, but shall not cause submission of invalid installers.
This should allow the improvements that have been submitted to http://github.com/microsoft/winget-pkgs/issues/30233 to be merged.
winget validate --manifest <path>
?winget install --manifest <path>
?Note:
<path>
is the name of the directory containing the manifest you're submitting.Microsoft Reviewers: Open in CodeFlow