GITHub integration

#1

Full integration with git would be really cool to keep track of workflows, dashboards, experience page code and JavaScript inside function nodes.

The Workflow version control is helpful but a bit incomplete in the context of an entire application.

#2

How do you see a Git integration working? Would you be storing device and workflow configuration as JSON objects within a repository? Or did you have something else in mind?

#3

at the moment we have to copy and paste experience page code, workflow configurations, and any javascript from function nodes to and from git to track revisions.

So i didnt have any particilar method in mine, so long as there was a way to track source files without copy and paste.

#4

One of our next big feature pushes will be versioning / staging vs. production status in experience views. We’re envisioning it working similarly to workflow versions, where we would store each “published” version and allow you to set a default version to return to your users while testing “in development” versions without disrupting the current experience. Would that satisfy your requirement?

#5

that would be very helpful. It was be great if there was a way to keep a copy of the versions offline however.

I suggested git because because its so standard and its where all of our other software projects are housed, so its logical to use the same tools.

#6

The main advantage of git being that our team can see incremental changes and compare diffs ,etc. I would presume the source for platform itself would use a revision control system like git so why not the content itself?

#7

Yes please to Git. Visual languages (Labview, Simulink, Losant, etc.) have their strengths, but searching and diffing code are hard.

I had a wee think about how Git could integrate with Losant.

  1. Losant designs and publishes a JSON schema for the Application tree (workflows, globals, etc.)
  2. Losant designs an API that supports a query language for extracting all or part of the tree. Think XSLT + XQuery but simpler and JSON centric.
  3. Third party with appropriate API access recovers snapshots of the tree / sub-tree as JSON snapshots.
  4. Third party denormalises the JSON into a well defined file hierachy inside a Git working repo, ie. JSON to directory of files.
  5. Third party uses normal git commands to detect new, changed, removed content and commits the differences.
  6. (Getting fuzzy here) Third party includes scripts to normalise the file hierarchy back into Losant Application JSON and “publish” into Losant.