Jump to content

OneUpdater — Update workflows with a single node


Recommended Posts

  • 2 weeks later...
  • 2 years later...

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.

Link to comment
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 by vitor
Link to comment
  • 1 year later...

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 by optimus1509
Added GitHub Link
Link to comment

@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

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...