vitor Posted October 6, 2017 Author Share Posted October 6, 2017 Update. Added support for Github releases. Link to comment
xilopaint Posted October 6, 2017 Share Posted October 6, 2017 Well, so I presume it's stable. I will update my workflow with it. Thanks again, @vitor. Link to comment
vitor Posted November 8, 2017 Author Share Posted November 8, 2017 Small note that all my Workflows now default to checking every 4 days. xilopaint 1 Link to comment
biati Posted November 16, 2019 Share Posted November 16, 2019 Hi @vitor is there a difference between setting "download_type" to "github_release" and setting the download type to direct and in the workflow_url setting the url to the latest release for example "https://github.com/user/repo/releases/latest/download/weorkflowname.alfredworkflow"? Also after implementing the updater I did a test and it notified me about and update (it downloaded the workflow from GitHub correctly and asked me to update, everything good here) except that there was no update, the thing is that I forgot to push the updated "info.plist" to GitHub (the one in GitHub said 1.0.0) while my workflow was in version 1.0.4, so it appears that the updater only does a simple comparison like $v1 !== $v2 instead of actually checking if the release version is bigger than the current version. So my question is do you think this could cause an issue (not now and not in my case) in the future with any workflow where the author forgets to change the version or something happens? or am I just dumb for making such mistake? Anyways, I think this is awesome, it's really simple to implement and it could basically be implemented in any workflow. As a new Alfred user I spent a few weeks looking and testing workflows you can find 3 or 4 different versions of the same workflow, outdated information, outdated links, etc. and it appears that there's not a single source where everyone could look for workflows (apart from the forum and I'm not sure this is the best way) I hope OneUpdater could become the standard for handling updates. Thank you for sharing. vitor 1 Link to comment
vitor Posted November 17, 2019 Author Share Posted November 17, 2019 (edited) On 11/16/2019 at 8:02 PM, biati said: Hi @vitor is there a difference between setting "download_type" to "github_release" and setting the download type to direct and in the workflow_url setting the url to the latest release for example "https://github.com/user/repo/releases/latest/download/weorkflowname.alfredworkflow"? It should work the same, with the exception that with github_release you don’t need the Workflow’s name to not change. On 11/16/2019 at 8:02 PM, biati said: so it appears that the updater only does a simple comparison like $v1 !== $v2 instead of actually checking if the release version is bigger than the current version. Yes, that’s correct. As a long-time maintainer of Homebrew Cask, I’ll say that trying to figure out every versioning method from everyone to understand when a release is higher or lower is a waste of time and resources. For an auto-updater you want the latest version, and that’s the one on the source. On 11/16/2019 at 8:02 PM, biati said: the thing is that I forgot to push the updated "info.plist" to GitHub (the one in GitHub said 1.0.0) while my workflow was in version 1.0.4 Another case where the simplistic comparison is useful. On 11/16/2019 at 8:02 PM, biati said: So my question is do you think this could cause an issue (not now and not in my case) in the future with any workflow where the author forgets to change the version If an author forgets to change the version, the only thing that will happen is that users won’t get the update (same as other updaters). On 11/16/2019 at 8:02 PM, biati said: or something happens? Like what? On 11/16/2019 at 8:02 PM, biati said: Anyways, I think this is awesome Thank you! On 11/16/2019 at 8:02 PM, biati said: it's really simple to implement and it could basically be implemented in any workflow. Those are its design goals, so happy to see it succeeds. On 11/16/2019 at 8:02 PM, biati said: I hope OneUpdater could become the standard for handling updates. Thank you again. Some libraries, like @deanishe’s Alfred-Workflow (for python), have builtin-updaters, so if you’re using the library for everything else, it makes sense to use its updater. Edited November 17, 2019 by vitor Link to comment
optimus1509 Posted July 15, 2021 Share Posted July 15, 2021 (edited) Hi @vitor, I am trying use OneUpdater in the TimeZones workflow which is at Version 2.30 in the configuration, however OneUpdated re-downloads version 2.30 saying it's an update. This is my configuration of OneUpdater: readonly remote_info_plist='https://raw.githubusercontent.com/jaroslawhartman/TimeZones-Alfred/v2.30/source/info.plist' readonly workflow_url='jaroslawhartman/TimeZones-Alfred' readonly download_type='github_release' readonly frequency_check='0' Also, every time an update happens the OneUpdater Node within the TimeZones workflow is also deleted, is this by design? How can i correct the above 2 issues. I am linking to the correct plist file? This should be from the latest release in GitHub right? GitHub Link - https://github.com/jaroslawhartman/TimeZones-Alfred Edited July 15, 2021 by optimus1509 Added GitHub Link Link to comment
vitor Posted July 16, 2021 Author Share Posted July 16, 2021 @optimus1509 You can’t add OneUpdater (or any code, really) to another person’s Workflow and have it stay there after updates. It has to be added by the developer. Either way, the way you have it now wouldn’t work because you’re checking a versioned directory, meaning you’re not really checking for updates. Link to comment
realliyifei Posted January 4, 2022 Share Posted January 4, 2022 Thanks for recommendation. Two quick questions: 1. If my workflow contains both action and no-action component (both can work individually), can I use both `Run Script` and `Script Filter`? As showed below: 2. Just double check that I don’t need to fill anything on the boxes (keyword, placeholder title, …) and also the variables set below are correct? Link to comment
vitor Posted March 29, 2022 Author Share Posted March 29, 2022 Made a few small updates. Added support for the new notificator and removed support for the old one and terminal-notifier. I also improved the process of getting packages from GitHub, to ensure a .alfredworkflow is downloaded. You don’t have to add the new version to your Workflow if you don’t want and it’s working fine; nothing was broken, the behaviour is the same. iandol and xilopaint 2 Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now