OneUpdater — Update workflows with a single node

[vitor]

Update.

Added support for Github releases.

[xilopaint]

Well, so I presume it's stable. I will update my workflow with it.

 

Thanks again, @vitor.

[vitor]

Small note that all my Workflows now default to checking every 4 days.

[biati]

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]

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

[optimus1509]

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

[vitor]

@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.

[realliyifei]

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?

 

[vitor]

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.