How To := Axon + Git

Published on 10 Jan 2023 by Steve Eynon
Updated on 01 Oct 2023

How To := Axon + Git

Software developers use Source Control Management (SCM) tools to:

  • keep a versioned, incremental backup of their code
  • to compare versions, to see what's changed (and by who)
  • to roll back to a previous version if if all goes wrong
  • to facilite continuous builds / deployment / automation code checkin

Real hardcore, battle hardened programmers use a proper Distributed Source Control Management (DSCM) tool like Mercurial (aka Hg), whereas lesser script kiddies seem to prefer an unknown distributed file system called Git (just because you can doesn't mean you should! - ahem).

But, which ever tool floats your boat, the most important thing for developers is that they use one. And all these tools have one important thing in common - they all synchronise and version files on the file system.

Compare this to SkySpark, where your Axon source code is stored in the Folio database.

For SkySpark developers working with Axon, it would be really handy to be able to work on source code (stored in Folio) and have this sync this with the file system, so it may be committed to a source code repository.

And you can in 2 ways!

1. Use our Folio File Sync extension

The Folio File Sync extension is the latest software developer tool from Fantom Factory! (Available now on StackHub)

Folio File Sync Article

Or...the hard way!

2. Use the native Task app in SkySpark

The TLDR; use a SkySpark Task to observe Folio commits and write function records to disk, then use Hg (or a lesser system, <cough>, Git) as usual.

The setup

The SkySpark Task App is all about background processing, and running Axon functions behind the scenes in response to an event. It is concurrency and event handling for Axon.

SkySpark Tasks (Axon functions) can even run in response to someone committing records to Folio. So that will be our approach.

We could set up a Task to observe ALL Folio commits, and write ALL function records to disk each and every time - but that could be very computational heavy. So let's try to be a little more selective instead.

We will add the tag afFileSync to every Axon function we want to write to disk, and add a Task to just observe those records that have been tagged with it.

Tasks App

To do this, visit the Tasks View in the Tasks App and click New.

Our Task will observe obsCommits (look under obsRecs in the picker), meaning our Axon Task function will be invoked in response to Folio updates.

In obsFilter we put afFileSync as that is the tag that will mark which function records we want to write to the file system.

taskExpr is then the name of the Axon function that will be invoked when Folio is updated.

And don't forget to add the Marker tags, obsAdds, obsRemoves, and obsUpdates - these ensure our Axon afDoFileSync() function is called when ever a record (with the afFileSync tag) is added, removed, or updated.

New Task

Next we create the afDoFileSync() Axon function.

// afDoFileSync()
(msg) => do
  funcRec  : if (msg->subType == "removed") msg->oldRec
             else                           msg->newRec

  filename : "func-" + funcRec->name + ".trio"
  filepath : ("io/axon/" + filename).parseUri()

  if (msg->subType == "removed")

The funcion inspects the given observable message to determine if a func is being updated or deleted (removed) from Folio. It derives a filename / path to save the function to, and saved it as a .trio file in the project's io/axon/ folder.

For real world use, extra checks should be performed on the msg passed in, but to illustrate a working example, the function above is perfectly usable.

The result

Tag your Axon functions with afFileSync and every time you save it in the Code Editor, the Task will invoke afDoFileSync, which will save the changes to the project's io/axon/ folder as a .trio file.

You can now commit and push your code to your favourite Version Control System (VCS) Hg (or a lesser system, <cough>, Git) repository as usual!

The future

The above process is sound, but afDoFileSync() could be updated to handle:

  • other records types (defs, views, apps, etc...)
  • record renames
  • customisable file name patterns
  • customisable directory patterns
  • saving multiple records into a single .trio file

And then, what about re-syncing file updates back into Folio? Handling concurrent modifications between files and Folio?

Hmm ...maybe you should consider our Folio File Sync extension after all!


< Back to all articles