Jump to content

OneUpdater — Update workflows with a single node


Recommended Posts

@nikivi From that screenshot, you’ve downloaded an old version of OneUpdater. Where did you get it from?

 

If you want to distribute the Workflow via github releases, then put the releases page url in workflow_url and change workflow_type to page.

 

If you don’t want to keep making new github releases, do what I do: add the Workflow as any other file in the repo and update that.

Edited by vitor
Link to post
  • Replies 54
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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 p

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.

Updated for Notificator 1.2.0. Also shortened the default update interval to 4 days. If you already use OneUpdater in any Workflow, there’s no need to do anything.

Posted Images

I found the workflow in my library. It was this one (https://transfer.sh/LdatR/t-oneupdater.alfredworkflow).


I have updated it though from your github repository. :)

 

I have changed all values, here is the finished version, I hope that works, I can't really test it I think. https://transfer.sh/25Qdk/research.alfredworkflow

 

I like the idea of keeping the .alfredworkflow in the root of the repository. Thank you for your help.

 

Link to post
24 minutes ago, nikivi said:

I found the workflow in my library.

 

It can self-update from there by calling :updateoneupdater.

 

24 minutes ago, nikivi said:

I hope that works, I can't really test it I think.

 

You can, by running the workflow and looking at the debugger. Currently, you’ll see [ERROR: action.script] You need to set a workflow version in the configuration sheet.. So you need to fix that. Also, on the remote_plist variable you’re not actually linking to the plist, you’re linking to a github web page. You need to link to the raw file: https://raw.githubusercontent.com/nikitavoloboev/alfred-my-mindmaps/master/info.plist

Edited by vitor
Link to post
  • 1 month later...
55 minutes ago, vitor said:

@xilopaint Looking good. Everything seems to be setup correctly.

 

You can, however, simplify the connections on the Workflow itself:

w0yS43H.png

 

I tried to downgrade the version number on configuration sheet to test if OneUpdater does its job and nothing has changed. I may be missing something.

Edited by xilopaint
Link to post
12 hours ago, xilopaint said:

I may be missing something.

 

You need to change frequency_check to 0 to test. You have it at 15, meaning it’ll only try to check for updates 15 days from now.

Link to post

Update.

  • Add support for notificator.
  • Add support for the newer versions of terminal-notifier, where it is no longer distributed as an app but as a CLI binary.

This only adds new features, so there’s no need to update it in your current workflows.


To update, download the latest version (same URL) or wait a few days (15 or less) and it’ll prompt you to on next usage, since it uses OneUpdater.
 

Link to post
  • 2 months later...
On 31/07/2017 at 4:55 PM, deanishe said:

Any chance of shortening the default update interval to a day or two?

 

It seems I always end up downloading the updates manually, as the interval is so long and there's no "check for update now" mechanism :( 

 

Sure, I’ll consider it. My though process for the 15 days is something like “after a while it’s so seldom updated, it’s a waste to keep checking frequently”. It’d make sense to have a low limit at first and then bring it up.


Also note I don’t warn of every update on every Workflow. Some are so minor I just release them.


Next time I release an update to a Workflow, I’ll try to remember to shorten the time (no point in doing it now).

Link to post
  • 1 month later...
  • 4 weeks later...

@xilopaint Yes. Mind giving some help with testing? Since it’s not the method I use, I need someone else for feedback.

 

Replace the code in your OneUpdater node with this one:

# YOU MUST SET THESE VARIABLES. SEE THE README FOR AN EXPLANATION OF EACH.
readonly remote_info_plist='https://someserver.tld/myworkflow/info.plist'
readonly workflow_url='xilopaint/alfred-things'
readonly download_type='github_release'
readonly frequency_check='0'

# FROM HERE ON, CODE SHOULD BE LEFT UNTOUCHED UNLESS YOU KNOW WHAT YOU ARE DOING!
function abort {
  echo "${1}" >&2
  exit 1
}

function url_exists {
  curl --silent --location --output /dev/null --fail --range 0-0 "${1}"
}

function notification {
  readonly local notificator="$(find . -type d -name 'Notificator.app')"
  if [[ -n "${notificator}" ]]; then
    "${notificator}/Contents/Resources/Scripts/notificator" --message "${1}" --title "${alfred_workflow_name}" --subtitle 'A new version is available'
    return
  fi

  readonly local terminal_notifier="$(find . -type f -name 'terminal-notifier')"
  if [[ -n "${terminal_notifier}" ]]; then
    "${terminal_notifier}" -title "${alfred_workflow_name}" -subtitle 'A new version is available' -message "${1}"
    return
  fi

  osascript -e "display notification \"${1}\" with title \"${alfred_workflow_name}\" subtitle \"A new version is available\""
}

# Local sanity checks
readonly local_info_plist='info.plist'
readonly local_version="$(/usr/libexec/PlistBuddy -c 'print version' "${local_info_plist}")"

[[ -n "${local_version}" ]] || abort 'You need to set a workflow version in the configuration sheet.'
[[ "${download_type}" =~ ^(direct|page|github_release)$ ]] || abort "'download_type' (${download_type}) needs to be one of 'direct', 'page', or 'github_release'."
[[ "${frequency_check}" =~ ^[0-9]+$ ]] || abort "'frequency_check' (${frequency_check}) needs to be a number."

# Check for updates
if [[ $(find "${local_info_plist}" -mtime +"${frequency_check}"d) ]]; then
  if ! url_exists "${remote_info_plist}"; then abort "'remote_info_plist' (${remote_info_plist}) appears to not be reachable."; fi # Remote sanity check

  readonly tmp_file="$(mktemp)"
  curl --silent --location --output "${tmp_file}" "${remote_info_plist}"
  readonly remote_version="$(/usr/libexec/PlistBuddy -c 'print version' "${tmp_file}")"

  if [[ "${local_version}" == "${remote_version}" ]]; then
    touch "${local_info_plist}" # Reset timer by touching local file
    exit 0
  fi

  if [[ "${download_type}" == 'page' ]]; then
    notification 'Opening download page…'
    open "${workflow_url}"
    exit 0
  fi

  download_url="$([[ "${download_type}" == 'github_release' ]] && curl --silent "https://api.github.com/repos/${workflow_url}/releases/latest" | grep 'browser_download_url' | head -1 | sed -E 's/.*browser_download_url": "(.*)"/\1/' || echo "${workflow_url}")"

  if url_exists "${download_url}"; then
    notification 'Downloading and installing…'
    curl --silent --location --output "${HOME}/Downloads/${alfred_workflow_name}.alfredworkflow" "${download_url}"
    open "${HOME}/Downloads/${alfred_workflow_name}.alfredworkflow"
  else
    abort "'workflow_url' (${download_url}) appears to not be reachable."
  fi
fi

As you can see (you need only care about the top variables, as before), I’ve already set it up to work with your Things workflow, and to check on every run. It should be clear how to change (and to what) to make it work on another Workflow.

Edited by vitor
Link to post
41 minutes ago, nikivi said:

And it grabs the update from releases.

 

Not exactly. What it’s doing in that case (workflow_type='page') is opening the releases page from which the user will have to manually download. With this new change, it directly downloads the URL as if you had input a direct link.

 

2 minutes ago, xilopaint said:

It works perfectly! Thanks!

 

Good to know. Should put out an official release soon (still have to rework the README).

 

Also note that if you add more than one file to the Github releases page, it always gets just the first one.

Link to post
36 minutes ago, nikivi said:

Thank you @vitor

 

Works perfectly for me too. I set my interval to 5. I think it's a pretty good interval.

 

You shouldn't have edited your post. I will repost it here for the sake of discussion:

 

Quote

Okay I tested it and it doesn't work for me.


I tried to use it on this workflow. I released new version v1.4.2


And changed current workflow version of the workflow I linked to 1.4.1.


Running the workflow then gets me no update prompt.

 

I downloaded your workflow and didn't manage to update in the first attempts as well (don't have a clue why). After some attempts it started to work. The same thing occurred when I tried to test with my workflow, but I didn't tell anything here because I thought I was missing something.

 

Now I'm afraid there's some unpredictable behaviour with @vitor's implementation of the new feature. I hope I am not misleading here. It's a very welcome feature.

Link to post

I think it was because the raw info.plist didn't update instantly. So the version that OneUpdater saw in the raw info.plist was old. I think it was some kind of bug or delay with GitHub.

 

But if the version it reads is correct from that info.plist and is indeed higher than what you have, it will trigger an update. It worked for me in the end. :) 

Edited by nikivi
Link to post

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