OneUpdater — Update workflows with a single node

[vitor]

OneUpdater is an updater you can plug with minimal configuration into workflows, to keep them up-to-date in users’ machines.

Easiest way to use it is to copy one of its OneUpdater nodes (the pink ones, with the note) to another workflow.

If the workflow actions anything (you press ↵ at some point during usage), copy the top node (Run Script). Connect it to the most used action and double click to edit it. Fill the top variables with the correct values and you’re done.

If the workflow doesn’t action anything (Script Filters with no connections), copy the bottom node (Script Filter) instead and make its Keyword the same as the most used in the workflow. Edit the top variables the same way.

The top lines must be set, and the rest of the code should be left untouched.

• remote_info_plist is the URL to the workflow’s up-to-date info.plist on a server.
• workflow_url and download_type work in tandem. download_type must be one of direct, page, or github_release.
  • When direct, workflow_url must be a direct link to a Workflow file.
  • When page, workflow_url must be a link to a download page.
  • When github_release, workflow_url must be of the form username/repo.
• frequency_check is the number of day between update checks. Set it to when testing, so it fires on every use.

Example:

readonly remote_info_plist='https://raw.githubusercontent.com/vitorgalvao/alfred-workflows/master/ShortFilms/source/info.plist' 
readonly workflow_url='https://raw.githubusercontent.com/vitorgalvao/alfred-workflows/master/ShortFilms/ShortFilms.alfredworkflow'
readonly download_type='direct'
readonly frequency_check='4'

For it to work you need only update the workflow version in the configuration sheet (which should be done anyway). When any update happens, the user will be informed via a notification. It will be delivered by one of (in order and stopping at the first it finds) notificator, terminal-notifier, or plain AppleScript-called notification.

With both direct and github_release, new Workflow versions will be downloaded directly and opened (github_release grabs the first file from the latest release of the repository). page will open a page on the default web browser.

 

Download | Source

Edited October 24, 2017 by vitor

[deanishe]

Very cleverly done.

 

For workflows that don't action anything, perhaps you could provide a script-based version that can be sourced from bash/zsh (probably using nohup to stay fast)?

[vitor]

That idea is better than what I had in mind. Still, I’d prefer to continue with the “copy node” idea instead of including a file and then adding a line, so it can continue to be self contained. A big part of my goal is that if you’d like to get rid of OneUpdater, you can just delete a node and be done with it; similarly, you can be sure that to set it up, you need only worry yourself with that single node.

 

With that in mind, your idea actually had me improve mine to something that will be way easier to implement (I could’ve done it already if I had though of that) and still require only a single node. I’ll just put the exact same script in a Script Filter, and when setting it up you simply make its keyword the exact same as another in your workflow. Since this does not output any JSON or XML, it will still run but be invisible.

[deanishe]

Heh. So obvious now that you mention it

 

 

I love this. So simple to use. No need for an appcast.xml or other data feed.

[vitor]

Just realised another fun thing about this. Since there’s no update file for the developer to manage, we can actually add this to a workflow we haven’t developed and it will still work (provided the developer has the source available somewhere).

[vitor]

Update.

It now has the Script Filter option, eliminating the past limitation (details in the top post).

In addition, since this workflow’s only action is to force an update of itself, it’s own check is now 0 days (always run) instead of 15 days, since it won’t interfere with anything else. If you don’t want to wait the 15 days, this time you should update manually (no problem if you wait, you’ll get the 0 days from the next one).

[vitor]

Update.

 

OneUpdater seems to be behaving pretty solidly, so this update doesn’t change much. This is only concerned with the sanity checks it performs. Instead of always checking if the remote comparison file exists (it does not download it, only sees if it exists) it’ll now only try to ping it when it’s time to check for an update.

 

This likely won’t have any noticeable effect for you and it’s a pretty tame difference, so don’t worry about changing it in your own current workflows if you don’t feel like it.

 

As usual, update with :updateoneupdater.

[deanishe]

On 16/07/2016 at 4:32 PM, vitor said:

Just realised another fun thing about this. Since there’s no update file for the developer to manage, we can actually add this to a workflow we haven’t developed and it will still work (provided the developer has the source available somewhere).

 

Hmm. The update would presumably remove OneUpdater from the workflow, however.

 

Perhaps a standalone OneUpdater workflow that could update other workflows might be worth considering? Maybe with recipes…

[vitor]

4 minutes ago, deanishe said:

Hmm. The update would presumably remove OneUpdater from the workflow, however.

 

You’re right. For some reason I was under the impression Alfred kept your edits to nodes if they were simple enough (outright adding or deleting one). It does keep your changed Keywords and maybe even the Environment Variables.

 

7 minutes ago, deanishe said:

Perhaps a standalone OneUpdater workflow that could update other workflows might be worth considering? Maybe with recipes…

 

I did at one point envision a Homebrew-Cask-like system (or adding it to Homebrew-Cask itself) where anyone could submit an update (to the reference of) any workflow, such that we all could contribute to and benefit from a common system of updates, even if the developers themselves didn’t implement/contribute, but especially with the promise of a new Packal (which would also work with a CLI) and it being semi-official and all, I ended up scraping the idea. Not sure how that project is though, if it was outright abandoned or is just on hold (and if so, for how long).

[deanishe]

1 minute ago, vitor said:

with the promise of a new Packal (which would also work with a CLI) and it being semi-official and all, I ended up scraping the idea. Not sure how that project is though, if it was outright abandoned or is just on hold (and if so, for how long).

 

Shawn (like Smargh) got a job—they were both students before—and doesn't have the time for Packal any more. I'm  pretty sure Packal is a zombie now, and v2 will probably never see the light of day.

 

Would you be interested in working on a next-gen solution for updating workflows?

[vitor]

I knew Shawn was a student and regularly didn’t have time for Packal because of that, but wasn’t expecting it to be abandoned once he finished his studies, quite the contrary.

 

I barely touched the computer this weekend, which is why it took me a few days to reply. I have been thinking about your question these days, however, and about how I’d build such a system (knowing that would decide my answer). It’s also a long answer (divided into two posts), so it took a bit to write.

 

Without thinking of the past systems (I’d have a lot to say about them, but it’s not relevant here), here’s what I’m envisioning: first, we get rid of the “discoverability” angle. I think your question is spot on when asking about a new solution to updating workflows. Discoverability services (like Packal and alfredworkflow.com) where you post your workflows tend to mostly become a massive pile of garbage and useless results, as they become popular (think MacUpdate, i use this). It’s one major reason why I’ve always fought to make sure Homebrew-Cask does not become a discoverability service: there are too many, and they all suck. All the same apps rise to the top in all, and you’d be just as well served with a web search. Currently we have the forum, Packal, alfredworkflow, awesome-alfred-workflow, and who knows what else. Making another third-party Workflow discoverability service doesn’t seem like a good use of time.

 

On to the actual updating. The system I’ve been thinking about would work as a third-party system, but could have its logic transported to an official system down the line, which is where I think its strength lies.

 

For the third-party system, I was thinking of something completely open and with clear rules. Something that if the original core people were to leave, it could continue/be picked up. The problem with something as complex and closed as Packal is that it being abandoned means we’ll have to start something else all over, even with access to the code. There’s just too much infrastructure behind it.

 

So I was imagining something like a cask (picked a simple one). A simple text file with only a few details regarding a workflow: version and url (direct download), and possibly homepage (and/or forum link, and/or source page) and description. Of those, version is the only one that will regularly change. Then we could have an external updater (like the one you’ve built for Packal) to do the updating.

 

The advantages of this system are that you could trigger updates for workflows you don’t own (like in Homebrew-Cask) and the developer doesn’t have to know about the system for users of it to benefit. The more I think about it, though, and even as I’m writing it, the more I doubt its usefulness. Most workflows aren’t updated much, and the ones that are are usually from developers that care and would thus care about having their workflows up to date in such a system (if it were popular enough). Unlike with apps, no workflow (or not enough to justify it) is that popular that a third-party will keep it up to date in a system where the developer won’t. When we think of it that way, I don’t really see an advantage to this system over OneUpdater, for example.

 

Problem is that in any third-party system I envision, I only see two ways for workflows to be updated: either the workflows do it internally, or we use an external tool/workflow to do it. The former needs to be implemented on a case-by-case basis, and my answer to that in a language-and-wokflow-agnostic way is OneUpdater. The latter has a similar problem as the former (there’s somewhere where you always need to say it has been updated) but then you have the extra issue you need the extra tool (and for it to have enough adoption).

 

In the end, the only non-crappy solution I’m thinking about is a first-party one. Basically the same cask-like system I mentioned before, but managed officially by Alfred, and in a friendlier way. Leaving that for the next post.

Edited October 3, 2016 by vitor

[vitor]

So here’s how I’m thinking about the first-party system: when you buy the powerpack, you also get a user account tied to it. No need for account names and password, even. You open the preferences, go to the powerpack tab and pick “open powerpack page” — it generates some access token and logs you in. There, you see a simple webpage that has a list of your workflows, top to bottom. These only have their icon to the left, and on the right a few lines: title, version, bundle id, description, download url. All lines are editable, but you’ll likely only edit version, after the first time. This simple page will generate a simple feed for each workflow, on the backend. You also have, at the top of the page, a search bar that auto-filters your workflows by title as you type (no need to even press ↩).

 

To add workflows to this list, you simply right-click on them and pick some “share” option (like with themes) and it automatically opens your powerpack page and adds a new entry, with icon, version, title, bundle id, and description already filled. Only thing left to do is fill the download url.

 

Every time you update your workflow, you either change the version on your powerpack page, or you pick the same “share” option as before and it auto-updates when it recognises the same bundle id for the same user but a different version.

 

This will also work beautiful across Alfred versions. Only thing it needs is a different powerpack page for each version (just add v3, or v2, or whatever to powerpack page URL). When you right-click and share, it opens the correct page to your version.

 

Alfred itself will then, regularly (say once every 15 days), check for updates. It may even only check for updates to workflows you used in the last month (to minimise the already few and small network requests). It will do that by internally comparing the workflow’s version with the one from the online feed, and download the new versions.

 

This system still has the same issue as all the others: you need to update your workflow versioning somewhere. Only now that somewhere is official and can be done right from Alfred! You also do not need external tools and don’t need to implement an update system yourself, because Alfred itself takes care of everything. This makes the barrier to updating so small (and let’s not forget, official), there’s no longer a reason not to use it.

 

I’m yet to think of a third-party way for updating workflows that would come even close to this.

[deanishe]

I really like the idea of some kind of metadata file, akin (in purpose) to a cask recipe or a userscript.meta.js file.

 

I'd also prefer to keep it on my own server or in the GitHub repo than on alfredapp.com. 

 

Hosting the metadata file on alfredapp.com would be a nice option for folks without their own web space (or who don't want the hassle). I'd rather do it myself, though. 

 

What I really want to avoid is having to go to some webpage and manually update the workflow info (as you do on Packal). It's always a duplication of effort, seeing as my workflows all live on GitHub. 

 

Also, metadata files would allow anyone to build their own indexer/discovery service fairly easily, provided the files contain sufficient info.

 

As far as installing the updates goes, I'm a firm believer in leaving that up to Alfred. Re-implementing all the keyword, hotkey and variable migration logic seems needless duplication of effort to me. Leave the tricky stuff to Andrew

 

WRT Shawn and Packal: don't forget he works for an American company in the US. They probably have him working 16 hours a day…

 

[rice.shawn]

Sometimes it is near 16 hours a day. It's not quite dead yet.

[deanishe]

Hey Shawn! How's tricks?

 

We've missed ya.

[vitor]

For some reason I was under the impression you were Australian or European (maybe you are, but living in the US?). Not sure what gave me that impression.

[vitor]

Update.

 

Previously, OneUpdater only checked for updates if you hadn’t used the workflow for X days, since it reset the timer every time. Naturally, that was not the intended goal, since someone that used the workflow every day would never see updates. This update fixes that.

 

As usual, update with :updateoneupdater.

Edited October 4, 2016 by vitor

[deanishe]

4 hours ago, vitor said:

For some reason I was under the impression you were Australian or European (maybe you are, but living in the US?). Not sure what gave me that impression.

 

Who now? Shawn or me?

[vitor]

19 minutes ago, deanishe said:

Who now? Shawn or me?

 

Shawn. Your (Dean) Glosbe workflow was always an indication you are german (at the very least allowed for an educated guess since it’s the default language).

[deanishe]

I figured you must be talking to Shawn. OTOH, both of use have always had our locations right

<----- here

 

I'm also not German. Just lived here my entire adult life. Although now my stupid countrymen are leaving the EU, I'm probably going to apply to become a German.

 

Best chance I've got of being World Champion…

[rice.shawn]

I'm through and through American. I spent the first many years in Texas and the last decade in New York. But before I had to come into an office, my natural hours didn't quite match up to my timezone. 

 

The job has definitely got me working quite a bit with much less downtime to work on my other projects (last weekend, I had to work 28 hours to save a project that was moving past deadline), but I guess this is what I get for working at a publishing company with editorial deadlines.

 

I've been making an effort to carve out time to work on Packal, but a lot the Alfred 3 changes have made it harder to support both Alfred 2 and Alfred 3. I don't want to ditch those still using Alfred 2. Packal still gets about 18k page views a week and has some value as a central place for workflows, so I do want to repair it. So little time...

 

 

[deanishe]

A super-quick win on Packal might be changing the subtitle on workflow pages from "An Alfred 2 Workflow" to just "An Alfred Workflow".

 

[digisam]

On 10/4/2016 at 5:24 PM, rice.shawn said:

I've been making an effort to carve out time to work on Packal, but a lot the Alfred 3 changes have made it harder to support both Alfred 2 and Alfred 3. I don't want to ditch those still using Alfred 2. Packal still gets about 18k page views a week and has some value as a central place for workflows, so I do want to repair it. So little time...

 

 

 

I appreciate that your time is very limited, but it would really benefit users if could add a couple of notes on the Packal site reporting the overall current status and compatibility, and one about the Packal Updater and if it is still relevant.

 

Thanks

 

[vitor]

Update.

OneUpdater is still behaving solidly, so as usual this update isn’t mandatory, but it has some new niceties. I’ve removed the option to compare a local file to a remote file. Now, you always give it the location of the remote info.plist. Instead of comparing two files, it always compares the version in the local workflow to the version in the remote info.plist. This was done for several reasons:

• There’s now one less variable you need to set. The new (and only) method to trigger updates is to change the workflow version (which already was the previously recommended method) in the configuration sheet, and you should be doing that anyway.
• If you were already relying on info.plist and had Workflow Environment Variables (especially ones that are not exported), that meant an update notice could trigger even when there were no changes upstream.
• In that same line, if you’re a user and made some local changes to other parts of the workflow, you could also have an update triggered.
  

In sum, this update makes OneUpdater easier to setup and more reliable with corner cases.

 

This does mean compatibility with Alfred 2 is broken (since it does not have a version field for workflows), but the old version will continue to work fine.

As usual, update with :updateoneupdater.

[nikivi]

I have a question regarding implementing OneUpdater. I want to add it to a workflow (https://www.alfredforum.com/topic/10069-search-through-web-mind-maps-i-have-made-workflow/#comment-50550) but I am not sure what values I should include in the node. 

 

I have connected OneUpdater like so : 

 

 

 

But not certain as to what values I should include. In fact I find updating and keeping my workflow updated really time consuming, I wish there was a better way.

 

Currently if I want to update the workflow I not only have to push the changes to the GitHub repository of it here : https://github.com/nikitavoloboev/alfred-my-mindmaps 

 

But I also have to create a release and then manually change this release in the markdown. Is there a better way to do it perhaps, maybe have the markdown always link to a new release and somehow automate the creation of the release as well if possible. 

 

But aside from these issues, how do I implement OneUpdater. The question is about changing this setting : 

 

 

 

 

Since the download url changes with each new release, I am not sure what to include there.