Jump to content
jerome

Best Practices for Workflows in Revision Control

Recommended Posts

I'd like to have my workflow in Git so that I can see the history of each of the scripts that go into the total thing. 

 

Right now I can unzip my .workflow and add all the files separately, but not only is that an awkward process, but you end up with all your scripts in the info.plist along with all the alfred configuration data. 

 

Is there an easy way to keep everything clean and human readable in revision control? Or would I have to comprehend the full nature of info.plist and write some sort of  build system? 

 

 

I looked around on github and i didn't see anything encouraging so far. Just a bunch of .workflow archives committed directly. 

Share this post


Link to post
Posted (edited)

Hi @jerome, welcome to the forum.

 

54 minutes ago, jerome said:

Is there an easy way to keep everything clean and human readable in revision control? Or would I have to comprehend the full nature of info.plist and write some sort of  build system?

 

There isn't a single best practice, but broadly speaking, you should put non-trivial code in external scripts. Historically, we've treated the Script box in Alfred's Run Script/Script Filter actions like a shell command line and called scripts from there, but Alfred now has an External Script option (so you can point Run Script/Script Filter elements directly at a script file), which you should use where possible.

 

When Alfred runs a workflow, the workflow directory is the working directory, so it's very easy to run external scripts.

 

The main goal is to keep as much code as possible out of info.plist. IMO, the best approach is to treat info.plist like you would a binary blob: you shouldn't edit it directly, but only via Alfred Preferences, and you shouldn't put any more code in it than absolutely necessary.

 

You'll find a lot of workflows that don't do that, but as you note, they work miserably with SCM.

 

Generally speaking, most experienced workflow developers put the workflow's source code in a subdirectory of the repo, such that you can symlink that subdirectory to Alfred's workflow folder. Using a subfolder is a good idea because you can then leave files that don't belong in the workflow itself in the repo, such as demo GIFs or a packaged copy of the workflow. Also, many authors keep all their workflows in a single repo.

 

If you’re writing your workflow in a compiled language, the best method is to create a build subdirectory, which you can symlink to Alfred’s workflow directory and exclude from the repo.

 

I typically structure my Python workflows like this, with the src subdirectory being the actual workflow (i.e. if you symlink that directory to Alfred’s workflow folder, you have a working workflow).

 

I typically also put a built version of the workflow in the repo root, but that's strictly to avoid questions from the idiots who refuse to read the instructions. The "official" workflow file is in GitHub releases, not least because the workflow libraries I use (see my sig) pull workflow updates from GH releases.

Edited by deanishe

Share this post


Link to post

Thanks! I just added this bit, which is quite important, imo:

 

6 minutes ago, deanishe said:

When Alfred runs a workflow, the workflow directory is the working directory, so it's very easy to run external scripts.

Share this post


Link to post

@jerome This script might be of interest to you. You pass it your workflow's directory and it figures out where Alfred's workflows are and symlinks your directory there, so you don't have to put repos directly in Alfred's workflow directory.

Share this post


Link to post
On 6/5/2020 at 8:46 PM, jerome said:

Right now I can unzip my .workflow and add all the files separately

 

You can also take the opposite approach of having your directory and packaging that as a .alfredworkflow.


That’s a (considerably) simplified approach of what I use for keeping all Workflows in the same repo, as @deanishe linked above.

 

All I need is be inside the Workflow’s directory, run alfred-workflow-update <commit message>, and I’m done. It packages the workflow correctly; bumps the version; updates the README, source, and download file; pushes everything; copies a standard message to the clipboard; and opens the forum to a search of the Workflow’s name so I can post the update notice.

 

That’s practical for me, but as is should not be for you. Still, as @deanishe mentioned, there’s no single best practice so more examples should give you more ideas.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...