Publish to package managers

[rollingmoai]

Describe the request Please add a Chocolatey and a Winget package where I can just set and forget this via parameters.

Checklist:

• [x] Chocolatey
• [x] Winget
• [x] Scoop

[rcmaehl]

I will likely need to complete #21 before I can add it but I'll look into it.

[SamHills]

Please do! I wrote a .bat file to install / update apps, and it uses Chocolatey wherever possible., I'll be adding MSEdgeRedirect to the list when #21 is done and I would sure like to use Chocolatey for it.

[ghost]

I would like to try out this tool But the winget support is still missing.

[Macleykun]

I saw this issue and if possible, i would like to give it a go.

I believe there's no CD for the releases page, so i suggest we build ontop of this workflow and we could trigger a release.

There's a few ways to go around this. I've made a CD that checks for a specific word in a commit message. So i could make it trigger only with the words: Bump Version .

Futhermore, i want to tackle winget as that seems the easiest. A way to do it for choco can be found here.

Lastly we can look at versioning. We could just make a stable/normal release with winget/choco, but we could make alongside it a beta/dev version that is updated each time a commit happens. I wouldn't be sure how to tag each version then however.

Let me know what you think.

Sources used: https://www.techwatching.dev/posts/wingetcreate https://github.com/dolthub/dolt/blob/main/.github/workflows/ci-bump-winget.yaml#L33 https://www.dolthub.com/blog/2021-10-13-how-to-publish-winget-chocolatey-packages-with-github-actions/ https://github.com/dolthub/chocolatey-packages https://github.com/dolthub/chocolatey-packages/blob/main/dolt/update.ps1

[rcmaehl]

I saw this issue and if possible, i would like to give it a go.

I believe there's no CD for the releases page, so i suggest we build ontop of this workflow and we could trigger a release.

There's a few ways to go around this. I've made a CD that checks for a specific word in a commit message. So i could make it trigger only with the words: Bump Version .

Futhermore, i want to tackle winget as that seems the easiest. A way to do it for choco can be found here.

Lastly we can look at versioning. We could just make a stable/normal release with winget/choco, but we could make alongside it a beta/dev version that is updated each time a commit happens. I wouldn't be sure how to tag each version then however.

Let me know what you think.

Sources used: https://www.techwatching.dev/posts/wingetcreate https://github.com/dolthub/dolt/blob/main/.github/workflows/ci-bump-winget.yaml#L33 https://www.dolthub.com/blog/2021-10-13-how-to-publish-winget-chocolatey-packages-with-github-actions/ https://github.com/dolthub/chocolatey-packages https://github.com/dolthub/chocolatey-packages/blob/main/dolt/update.ps1

Sure. Feel free to submit a PR for any changes :)

@micwoj92 is my go to for any CI issues so he may be able to help with versioning.

[Macleykun]

Sure. Feel free to submit a PR for any changes :)

Allright :) i'll make one this weekend. I'll make it trigger on the words Bump Version in the commit message to automatically make the releases tab and winget (and choco later, probs in same PR) I'll also keep it all in the same workflow.

[micwoj92]

@Macleykun persoannly I don't like that that workflow you used as example only specifies "latest" as tag.

Lastly we can look at versioning. We could just make a stable/normal release with winget/choco, but we could make alongside it a beta/dev version that is updated each time a commit happens. I wouldn't be sure how to tag each version then however.

Stable should stay the way it is (for example tag name 0.6.2.0 is version 0.6.2.0 etc.) for "dev" one could just use "latest" tag as in that future mc CI you linked.

I don't really know how you want to implement this so I probably can say a bit more once you do this.

[Macleykun]

Yeah I wasn’t to happy of it either, but it was because the artifacts on GitHub can only be downloaded by registered GitHub users. Tho, if the dev/I were still active with the project, I would revisit it and remove that and instead keep it simple (stupid).

So far I have the workflow but somehow I can’t fetch the version and url from GitHub. Aswell as triggering the second workflow (I kinda hope I can revert that, as I think it should be possible to do it if I get those last two variables).

Met vriendelijke groet,

Wesley de Vree

---

Van: micwoj92 @.> Verzonden: Friday, February 4, 2022 9:24:32 PM Aan: rcmaehl/MSEdgeRedirect @.> CC: Macley @.>; Mention @.> Onderwerp: Re: [rcmaehl/MSEdgeRedirect] Chocolatey and Winget package (Issue #28)

@Macleykunhttps://github.com/Macleykun persoannly I don't like that that workflow you used as example only specifies "latest" as tag.

Lastly we can look at versioning. We could just make a stable/normal release with winget/choco, but we could make alongside it a beta/dev version that is updated each time a commit happens. I wouldn't be sure how to tag each version then however.

Stable should stay the way it is (for example tag name 0.6.2.0 is version 0.6.2.0 etc.) for "dev" one could just use "latest" tag as in that future mc CI you linked.

I don't really know how you want to implement this so I probably can say a bit more once you do this.

— Reply to this email directly, view it on GitHubhttps://github.com/rcmaehl/MSEdgeRedirect/issues/28#issuecomment-1030323274, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGJIY46TINBYJY7SB4HWQXLUZQYYBANCNFSM5J3BYB5A. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>

[Macleykun]

I believe here: https://github.com/Macleykun/MSEdgeRedirect/blob/e86dc98dddd19f0bca68a6c0052b0009376e2371/.github/workflows/winget-submission.yml#L17

[Macleykun]

@TechWatching Thank you for your response in: https://github.com/nushell/nushell/issues/4275 I was never able to test it out, but we did merge it into main see: https://github.com/rcmaehl/MSEdgeRedirect/blob/main/.github/workflows/winget-submission.yml

But, for whateve reason, when i create a tag locally in git bash, and push the commit and then the tag (also in different order) I never seem to be able to trigger the publish + not being able to send the url and version into the winget part.

I assumed it was just me who just didn't knew how to push correctly, as the logic seems to check out and all.

Could you perhaps fork and test the pipeline to see if it indeed works like it should? Then i can learn from this and make the chocolate variant aswell).

[Macleykun]

i also just read your article about the GITHUB_TOKEN secret. This most likely explains not only the workflow trigger issue, but maybe also why it can't parse the download url and version (i assume). I'll look into this and find how to use the right token for this.

[Macleykun]

Could you maybe point out where the selfmade repo token has to be added/changed in this workflow? https://github.com/rcmaehl/MSEdgeRedirect/blob/main/.github/workflows/MSER.yml

[TechWatching]

Instead of using secrets.GITHUB_TOKEN you should use a GitHub PAT as shown here.

[Macleykun]

Instead of using secrets.GITHUB_TOKEN you should use a GitHub PAT as shown here.

Thank you so much! So far it's almost making it work! I can now properly show this error that i'm always getting somehow: https://github.com/Macleykun/MSEdgeRedirect/runs/5126714611?check_suite_focus=true

But i wonder how that's possible? The .exe file that is specified is present at the releases tab. I assume the problem arises here?: https://github.com/Macleykun/MSEdgeRedirect/blob/patch-1/.github/workflows/winget-submission.yml#L19

[Macleykun]

~I've done some more digging, but i'm afraid we have to include/change the .exe to an .msi (or simalair) @rcmaehl I tried to execute it locally and got an invalid url was provided.~

~wingetcreate.exe new rcmaehl.MSEdgeRedirect -t ghp_mytokenfromgithub https://github.com/rcmaehl/MSEdgeRedirect/releases/download/0.6.2.0/MSEdgeRedirect.exe Downloading and parsing: rcmaehl.MSEdgeRedirect... Failed to download installer. Invalid URL provided. Please check the URL and try again~

~I assume that regular .exe files aren't supported.~

Well it seems that i was able to create it after all: https://github.com/microsoft/winget-pkgs/pull/45636

did it manually, but i assume that the first time we/i had to use the new option. interesting to see how it goes :), the process was way more easier by just running wingetcreate.exe locally withoud anything appended to it.

[TechWatching]

Yes indeed this pipeline is to upgrade existing package but you must have created once in the repository. Once it is done, the pipeline will automatically push the new versions.

[Macleykun]

@rcmaehl is it possible to use the MSEdgeRedirect.exe /silentinstall mode withoud the .ini file? Sadly, we need to be able to install MSEdgeRedirect.exe withoud any user input: https://github.com/microsoft/winget-pkgs/pull/45636

Yes indeed this pipeline is to upgrade existing package but you must have created once in the repository. Once it is done, the pipeline will automatically push the new versions.

aah, honestly it makes so much more sense. I'm pretty sure that's most likely the reason that the last part isn't working well (url part).

[Masamune3210]

if you use latest instead of a version it will pull the latest stable btw

[rcmaehl]

@rcmaehl is it possible to use the MSEdgeRedirect.exe /silentinstall mode withoud the .ini file? Sadly, we need to be able to install MSEdgeRedirect.exe withoud any user input: microsoft/winget-pkgs#45636

YEP, I can add that

[rcmaehl]

@Macleykun So sorry this took a while, got caught up with some real life issues. Tests on my system work. 0.6.3.0 should be out shortly

[Macleykun]

@Macleykun So sorry this took a while, got caught up with some real life issues. Tests on my system work. 0.6.3.0 should be out shortly

No need to say sorry! Thank you for adding wingetinstall ! I'll cancel the current PR on winget submissions as we'll start from a different version (this also makes things less confusing etc).

[rcmaehl]

Hey @Macleykun do you know which permissions the PAT needs?

[Macleykun]

Hey @Macleykun do you know which permissions the PAT needs?

I believe it only needs to be able to trigger a workflow on the repo, so i would say this would be enough:

Also, submitting the manifest again, then the url issue in that workflow should also be fixed Looking promising! https://github.com/microsoft/winget-pkgs/pull/46503

I still think this needs to be merged for the url to work fully if i believe TechWatching (tho i saw the workflow trigger when you made the release... which is what i wanted, but didn't expect...) https://github.com/rcmaehl/MSEdgeRedirect/pull/73

[rcmaehl]

Hey @Macleykun do you know which permissions the PAT needs?

I believe it only needs to be able to trigger a workflow on the repo, so i would say this would be enough:

Also, submitting the manifest again, then the url issue in that workflow should also be fixed Looking promising! microsoft/winget-pkgs#46503

I still think this needs to be merged for the url to work fully if i believe TechWatching (tho i saw the workflow trigger when you made the release... which is what i wanted, but didn't expect...) #73

Added the secret. Merging #73 now

[Macleykun]

@TechWatching you think everything is set correctly for the winget update workflow? (sorry, just want to double check so we know the next release will work :))

[TechWatching]

Never tested it. On the repo I was using, releases were created in draft and manually published so PAT was only needed to publish on winget-pkgs not to trigger the other workflow. But from what I see it looks good. Unfortunately we will only be sure when the next release will take place🤞

[gnpaone]

Hey @Macleykun do you know which permissions the PAT needs?

Hey @rcmaehl @Macleykun @TechWatching I can help you with that (code in one repo and publishing in this repo). For creating keys we need Linux or Mac (just to execute keys generation in terminal). Navigate to the folder where you want to store keys in terminal using cd command (for eg: cd /home/user/Downloads). Generate the keys using ssh-keygen -t rsa -b 4096 -C "$(git config user.email)" -f" where $(git config user.email) replaced with the mail id of the user of the github account where the code exists, <your-deploy-branch> is replaced with any branch name in rcmaehl/MSEdgeRedirect to push the code (currently "main" branch exists but can use another branch name (recommended)(no need to manually create branch). It will ask for name (any name is ok) & password, I recommend to give empty password (just hit enter when asked password). 2 files will be generated in the folder. Now open both the generated keys using notepad, sublime text or any text editor (I use sublime text always, like it's interface 😅). Public Key must be added to this repo (in settings) in "Deploy Keys" - give name as "Public key of ACTIONS_DEPLOY_KEY", private key must be added to the repo where code exists in the repo settings in Secrets>Actions with name "ACTION_DEPLOY_KEY". (Key value is whatever found in the text editor just copy and paste in respective places). Now in the Github workflow, in the action where you "deploy" it must be like this: with: deploy_key: ${{ secrets.ACTIONS_DEPLOY_KEY }} external_repository: rcmaehl/MSEdgeRedirect publish_dir: ./build publish_dir can be ./build or whatever publish_dir you mentioned in your workflow (I use this). Any doubts you can definitely ask. Can you share your github workflow after above steps here if you don't mind? (Just to see). Also the workflow file must exist and run in the repo where code exists.

This is the code to execute (Github error in typing 🙄😐): (must include ` in code)

[TechWatching]

I think you are not talking about the same key....

[gnpaone]

I think you are not talking about the same key....

There will be pair of keys generated. I mean both are interlinked, public key won't work without private key, this type is used when code and workflow yml is in one repo but workflow running and final workflow files to be in other repo

[TechWatching]

What I meant is that this is not the problem that @Macleykun and @rcmaehl are trying to solve. Their problem is an issue relative to GitHub not to Git. Their problem is that their workflow to submit the package to winget is not triggered by their workflow that builds the package. The issue is that the softprops/action-gh-release@v1 action that create the release is using the secrets.GITHUB_TOKEN. As explains here that can't trigger another workflow so they have to create a GitHub Personal Access Token and use it in their build pipeline. This is what they did from what I understood and that should be okay. They just have to wait for the next release to check it works.

By the way @Macleykun to test my workflow on another project, what I did is that I created the secrets, the Actions and a fake release on my fork . It allowed me to test without waiting for the main repo to release something.

[gnpaone]

What I meant is that this is not the problem that @Macleykun and @rcmaehl are trying to solve. Their problem is an issue relative to GitHub not to Git. Their problem is that their workflow to submit the package to winget is not triggered by their workflow that builds the package. The issue is that the softprops/action-gh-release@v1 action that create the release is using the secrets.GITHUB_TOKEN. As explains here that can't trigger another workflow so they have to create a GitHub Personal Access Token and use it in their build pipeline. This is what they did from what I understood and that should be okay. They just have to wait for the next release to check it works.

By the way @Macleykun to test my workflow on another project, what I did is that I created the secrets, the Actions and a fake release on my fork . It allowed me to test without waiting for the main repo to release something.

Ok so what we want is one workflow should trigger another workflow and ends with last workflow, right?

[TechWatching]

What I meant is that this is not the problem that @Macleykun and @rcmaehl are trying to solve. Their problem is an issue relative to GitHub not to Git. Their problem is that their workflow to submit the package to winget is not triggered by their workflow that builds the package. The issue is that the softprops/action-gh-release@v1 action that create the release is using the secrets.GITHUB_TOKEN. As explains here that can't trigger another workflow so they have to create a GitHub Personal Access Token and use it in their build pipeline. This is what they did from what I understood and that should be okay. They just have to wait for the next release to check it works. By the way @Macleykun to test my workflow on another project, what I did is that I created the secrets, the Actions and a fake release on my fork . It allowed me to test without waiting for the main repo to release something.

Ok so what we want is one workflow should trigger another workflow and ends with last workflow, right?

Well the initial workflow will just run and end without waiting for another workflow. But the fact that this initial workflow creates a release, that will trigger the other workflow. But yes that's it.

[gnpaone]

What I meant is that this is not the problem that @Macleykun and @rcmaehl are trying to solve. Their problem is an issue relative to GitHub not to Git. Their problem is that their workflow to submit the package to winget is not triggered by their workflow that builds the package. The issue is that the softprops/action-gh-release@v1 action that create the release is using the secrets.GITHUB_TOKEN. As explains here that can't trigger another workflow so they have to create a GitHub Personal Access Token and use it in their build pipeline. This is what they did from what I understood and that should be okay. They just have to wait for the next release to check it works. By the way @Macleykun to test my workflow on another project, what I did is that I created the secrets, the Actions and a fake release on my fork . It allowed me to test without waiting for the main repo to release something.

Ok so what we want is one workflow should trigger another workflow and ends with last workflow, right?

Main workflow: name: My workflow

on: [push]

jobs: .....

Workflow to be triggered after main workflow: (Second workflow) name: Triggered workflow

on: workflow_run: workflows: ["My workflow"] types:

• completed

jobs: .....

As main workflow creating a release, that part can be removed from first workflow and added to second workflow job so that after second workflow release is created.

Can you please share link/upload here both the workflows? I will modify and upload back here

[TechWatching]

Currently the second workflow has a trigger on the release being published and I think it is fine that way. I would not make it depends on the completion on the first one. Making it depends on release being published make them more independent I think. The 2nd workflow only job is to publish packages from a new release to Winget and I think that is a good idea. Now if you want to modify them there are in the . GitHub folder of this repository but I think they are fine as they currently ate

[gnpaone]

Currently the second workflow has a trigger on the release being published and I think it is fine that way. I would not make it depends on the completion on the first one. Making it depends on release being published make them more independent I think. The 2nd workflow only job is to publish packages from a new release to Winget and I think that is a good idea. Now if you want to modify them there are in the . GitHub folder of this repository but I think they are fine as they currently ate

Ok, actually there's a small mistake in second workflow so it failed, once try the code from https://github.com/rcmaehl/MSEdgeRedirect/pull/81 (change code of second workflow ffrom https://github.com/rcmaehl/MSEdgeRedirect/pull/81)

[gnpaone]

In #82 Second workflow runs on completion of first workflow and runs seperately from first workflow (just for testing purposes as of now), later it can be modified to just be based on release instead of for every first workflow run.

[gnpaone]

https://github.com/rcmaehl/MSEdgeRedirect/pull/84 is next step for creating "Chocolatey" packages

[rcmaehl]

Man you all are so over my head on this CI stuff. 😅

[Macleykun]

By the way @Macleykun to test my workflow on another project, what I did is that I created the secrets, the Actions and a fake release on my fork . It allowed me to test without waiting for the main repo to release something.

Yeah i wanted to test that too, but idk why but i believe i can't seem to push a tag the same way rcmahl does. I always pushed like two commits somehow xD

Man you all are so over my head on this CI stuff. 😅 xD tbh, same for me with this convo. But tldr is like: you do a commit and a publish, after you published github is like: oh, a new release? i'll trigger now the winget part and the winget part is like winget update and giving the version, new url and github token to make the update pull.

[gnpaone]

Hey @Macleykun I saw this https://github.com/microsoft/winget-pkgs/pull/46503 😅(nice negotiation btw😋), now I understand why it failed to install. I have modified few things and tested in sandbox environment as well as azure pipelines, it's working as intended except for few problems to be resolved. Before that @Macleykun can you please provide the manifest original files that you created (I found the files in that PR but since the PR is draft I couldn't download it - just asking to compare and change packageidentifier name 😅 I gave my own packageidentifier name in my run to avoid clashes). It's due to this error... ...this happened for winget-pkg mods: https://github.com/microsoft/winget-pkgs/pull/46503#issuecomment-1040871663 (since their environment has gui disabled there's no way they would have noticed this message) Is there anything you can do @rcmaehl about that install parameter? (FYI, my manifests are validated successfully - did few changes to @Macleykun manifests including Active mode and Service mode option: ). Also, I corrected my typo error in #85 for choco, please check that too @rcmaehl - only e2e3a07, not the remaining commits 😅

[gnpaone]

I have few suggestions too, I added arguments (it's validated successfully but implementation) such as /se= /we= etc, if not used then default option of mser installer will be selected. /wingetinstall (I think this parameter is created recently right? if installed through winget and choco can the GUI be disabled without this parameter and be installed just with winget install msedgeredirect

[Macleykun]

Hey @Macleykun I saw this microsoft/winget-pkgs#46503 😅(nice negotiation btw😋), now I understand why it failed to install. I have modified few things and tested in sandbox environment as well as azure pipelines, it's working as intended except for few problems to be resolved. Before that @Macleykun can you please provide the manifest original files that you created (I found the files in that PR but since the PR is draft I couldn't download it - just asking to compare and change packageidentifier name 😅 I gave my own packageidentifier name in my run to avoid clashes). It's due to this error... ...this happened for winget-pkg mods: microsoft/winget-pkgs#46503 (comment) (since their environment has gui disabled there's no way they would have noticed this message) Is there anything you can do @rcmaehl about that install parameter? (FYI, my manifests are validated successfully - did few changes to @Macleykun manifests including Active mode and Service mode option: ). Also, I corrected my typo error in #85 for choco, please check that too @rcmaehl - only e2e3a07, not the remaining commits 😅

You should be able to get them here: https://github.com/Macleykun/winget-pkgs/commit/8493497a7233933da638f7c261ba530a50778000 For every version you might look for: https://github.com/Macleykun/winget-pkgs/commits/autogenerated/rcmaehl.MSEdgeRedirect/c9074202-8b80-4b4d-972a-6737ac991bf9

/Silent isn't the right one, rcmaehl made specifically for winget the /winget option (See latest verion on that draft pull).

Also with the uh corrections, you can just make a PR on my fork to this branch: https://github.com/Macleykun/winget-pkgs/tree/autogenerated/rcmaehl.MSEdgeRedirect/c9074202-8b80-4b4d-972a-6737ac991bf9 I'll just merge them if it doesn't break anything :P.

@rcmaehl any progress on the settings not being persistant with winget?

[gnpaone]

Thanks @Macleykun I will create a PR. /winget in the sense /wingetinstall? Um, I can't find it P.S.: https://github.com/Macleykun/winget-pkgs/pull/1 Done👍🏻 @Macleykun /Silent parameter isn't given by me at all nor mentioned by me in the manifest (no parameters were mentioned in manifest while testing), in fact I didn't give any parameter, mser app gave it automatically while installing.

Actually when --scope user is given it installs in service mode, --scope machine installs in active mode (similar to original installer where administrator mode installs/activated active mode installation, this is my idea and already few people like visual studio etc people implemented it. Also I am working on "commands" manifest option from its documentation for the settings part. I need help on what arguments/value name the software currently accepting in the background for each settings change in the foreground

[gnpaone]

Thanks @Macleykun I will create a PR. /winget in the sense /wingetinstall? Um, I can't find it P.S.: Macleykun/winget-pkgs#1 Done👍🏻 @Macleykun /Silent parameter isn't given by me at all nor mentioned by me in the manifest (no parameters were mentioned in manifest while testing), in fact I didn't give any parameter, mser app gave it automatically while installing.

Actually when --scope user is given it installs in service mode, --scope machine installs in active mode (similar to original installer where administrator mode installs/activated active mode installation, this is my idea and already few people like visual studio etc people implemented it. Also I am working on "commands" manifest option from its documentation for the settings part. I need help on what arguments/value name the software currently accepting in the background for each settings change in the foreground

Hey @rcmaehl with my manifest in https://github.com/Macleykun/winget-pkgs/pull/1 it works well, it successfully installs, no need to change anything, also default installation I set as Active mode (ie --scope machine) - it's default because in my PR scope machine was mentioned first 😅 - can swap that if service mode needs to be default, if --scope user mentioned then it will install in service mode, can you please add similar type of silent install for choco too? Just needed settings arguments implementation for this (both choco and winget works similar in terms of install and settings arguments, for arguments in winget its Installerswitches > Custom and in choco it's --param)

[rcmaehl]

Thanks @Macleykun I will create a PR. /winget in the sense /wingetinstall? Um, I can't find it P.S.: Macleykun/winget-pkgs#1 Done👍🏻 @Macleykun /Silent parameter isn't given by me at all nor mentioned by me in the manifest (no parameters were mentioned in manifest while testing), in fact I didn't give any parameter, mser app gave it automatically while installing. Actually when --scope user is given it installs in service mode, --scope machine installs in active mode (similar to original installer where administrator mode installs/activated active mode installation, this is my idea and already few people like visual studio etc people implemented it. Also I am working on "commands" manifest option from its documentation for the settings part. I need help on what arguments/value name the software currently accepting in the background for each settings change in the foreground

Hey @rcmaehl with my manifest in Macleykun/winget-pkgs#1 it works well, it successfully installs, no need to change anything, also default installation I set as Active mode (ie --scope machine) - it's default because in my PR scope machine was mentioned first 😅 - can swap that if service mode needs to be default, if --scope user mentioned then it will install in service mode, can you please add similar type of silent install for choco too? Just needed settings arguments implementation for this (both choco and winget works similar in terms of install and settings arguments, for arguments in winget its Installerswitches > Custom and in choco it's --param)

More than likely. It'll be a while though. Going through some personal stuff

[gnpaone]

Hey @rcmaehl, I understood what's causing 4315 error and also confirmed in https://github.com/microsoft/winget-pkgs/pull/46503#issuecomment-1050874917. I tested 0.6.3.1 version and it's working fine, is it possible to create a release of that? 0.6.3.1 installs successfully. (Please don't mind that weird link in the screenshot from where 0.6.3.1 gets downloaded 😅, I created temporary link to simulate that version download as winget local file as installer is apparently a work in progress there)

0.6.3.0 in sandbox:

0.6.3.1 in sandbox:

(Also before that one more thing left to test, I may create a PR here related to that, will update on that tomorrow)

[gnpaone]

(Also before that one more thing left to test, I may create a PR here related to that, will update on that tomorrow)

Done👍🏻, created #88 (based on report from here). I have a doubt @Macleykun, after release is created the winget workflow is going to run right, since the first manual PR isn't yet merged in microsoft's winget-pkg repo so will the workflow create duplicate PR or merge into existing PR? Since the workflow is meant to update, not create, right? But since still not created so will it create a duplicate PR (which the bots in that repo don't like probably)? If yes, then the winget workflow can be skipped for 0.6.3.1 release and can be run from next release once the package is accepted in winget repo.

[gnpaone]

(Also before that one more thing left to test, I may create a PR here related to that, will update on that tomorrow)

Done👍🏻, created #88 (based on report from here). I have a doubt @Macleykun, after release is created the winget workflow is going to run right, since the first manual PR isn't yet merged in microsoft's winget-pkg repo so will the workflow create duplicate PR or merge into existing PR? Since the workflow is meant to update, not create, right? But since still not created so will it create a duplicate PR (which the bots in that repo don't like probably)? If yes, then the winget workflow can be skipped for 0.6.3.1 release and can be run from next release once the package is accepted in winget repo.

Hey @rcmaehl I fear this would happen, my first priority is merging in winget-pkgs manually and then auto-update it via workflows. So I have a suggestion, it's to disable the workflow Submit MSEdgeRedirect to winget temporarily by following Disabling and enabling a workflow and then releasing 0.6.3.1, then the app can be merged manually in winget, after that re-enabling this workflow. Is that fine?

[rcmaehl]

(Also before that one more thing left to test, I may create a PR here related to that, will update on that tomorrow)

Done👍🏻, created #88 (based on report from here). I have a doubt @Macleykun, after release is created the winget workflow is going to run right, since the first manual PR isn't yet merged in microsoft's winget-pkg repo so will the workflow create duplicate PR or merge into existing PR? Since the workflow is meant to update, not create, right? But since still not created so will it create a duplicate PR (which the bots in that repo don't like probably)? If yes, then the winget workflow can be skipped for 0.6.3.1 release and can be run from next release once the package is accepted in winget repo.

Hey @rcmaehl I fear this would happen, my first priority is merging in winget-pkgs manually and then auto-update it via workflows. So I have a suggestion, it's to disable the workflow Submit MSEdgeRedirect to winget temporarily by following Disabling and enabling a workflow and then releasing 0.6.3.1, then the app can be merged manually in winget, after that re-enabling this workflow. Is that fine?

Sounds good

[gnpaone]

After releasing 0.6.3.1, Chocolatey package will appear in https://community.chocolatey.org/packages/ - similar process to winget