Source control in Ignition 8

I read here that source control can be used in Ignition 8.

All resources can now be tracked with industry standard source control tools, such as Git. Resources can be tracked individually, and changes to disk caused by source control operations (checkout, pull, etc) will be applied automatically to the running system.

I havent found any tutorials or documentation pages for setting this up. Are there currently any resources I can turn to for this?
Alternatively, I know that if I had access to the files I could set up source control myself. Where can I find the root folder for scripts?

Im certain this is a hot topic and has been answered already, but I’ve done searches and I cant find an answer to my question.

Thanks for your help.

1 Like

All project resources are located in the gateway installation directory (if you’re on, say, Windows, this defaults to Program Files/Inductive Automation/Ignition/. From there, project resources are in /data/projects/. Each project will have a folder there, and all resources within that project are then separated into modules. Below each module is a folder structure representing the path that you see in the designer.

An individual resource is itself a folder, containing at minimum two files: a resource.json file that defines meta-information about the resource, and a data.bin file, which contains the direct Java serialization of the actual resource. Some resource types, but not all, have different representations; for instance, project scripts are directly encoded as code.py files, which are plain text, while Perspective views are their direct JSON representation.

As of right now, in Ignition 8.0.X, that’s basically all the “source control” integration you get. Triggering commits, reverting, etc, is all an exercise for the user. In fact, you would probably need to write a custom module if you wanted to do on-demand “commits” every time a save was pushed from the gateway. But, if you just want to rely on a system like git to perform periodic commits (and safe resource rollback), you’re set.

Future plans include, at minimum, scripting hooks to allow you to directly run commits and various other actions once you’ve configured a git or other VCS repository.

2 Likes

I appreciate the very detailed response. Thank you for your help.

Thanks for this help - I added my entire projects folder to a repo to capture any project changes, I know the .resource folder gets recreated if it’s missing - any issues with one repo for all projects? so far seems to be working fine for me

No, the main thing is keeping track of things. Also, since my original post, we’ve added a project update scripting hook; it’s pretty barebones at the moment, but you could use system.util.execute() to trigger a git commit on project update (theoretically).

Super cool thank you - Ill probably use that for my production project, keep development on manual pushes. Either way working well so far.

I know this is a bit stale (~1 year), but I would love to know your workflow.

I have installed Git on our test/dev Gateway, and have initialized a repo in the C:\Program Files\Inductive Automation\Ignition\data\projects directory, which works as expected - on the server.
However, this is where I have questions. When thinking about developer experience, I would like for them to be able to access the repo from their machine, over a mapped drive perhaps, via Git Bash or whatever client they’d like to use. While this concept works, it is slow. How do you handle this?

Thanks

Hi Scott - Actually never solved that, my workflow isn’t currently great, but we only have two people working on the project, and I solely handle the development pushes. I have git running on the projects directory and while I develop ‘locally’ I log into our server and commit changes to a development project, and then a production environment.

1 Like

Thanks Tyler. We’re small as well, with 2-3 folks building projects.

I was hoping that we could use a share/mapping to access the server repo. While that is certainly doable, it is (understandably) slow. A simple ‘git status’ takes 20-30 seconds (20 projects, ~1300 files).

It would seem that there are a few options:

  1. Connect to the server and handle the Git tasks manually (as you are)
  2. Automate commits, as mentioned earlier in the thread, using the ‘project updated’ hook in conjunction with ‘system.util.execute()’. I could see doing something like ‘git add .’, ‘git commit -am “my comment”’, ‘git push’. However, I’m not sure how you would be able to provide a meaningful comment upon each save.
  3. Access the repo ‘remotely’, as I was attempting to do, understanding that it might be slow.
  4. Ssh into the target Gateway server. This seems to work well in concept.

IMO, #4 is the best option at this point (OpenSsh as we are on Windows), and is probably how I will proceed.

Thanks again for your input!

Hi,

I was for your workflow are you running EAM? I am trying to work through this workflow also and I have one central EAM and then 20~ agents that are deployed with the MQTT transmission and local HMI’s for those sites. Right now all of our Twincat work and application work are done in Github already with great success.

We found that one repo did not work for our situation. However we have dozens of projects being worked on, so the one repo approach did not work. EAM started breaking down for deployment as our team got bigger as we did not have great visibility as to WHAT was deployed, only the when.

What we have just started implementing is discontinuing EAM and using Git and Azure DevOps to control deployment. We have a DEV/TEST/PROD environments for all projects. Ignition developers have access to a “toolbox” page with git status, and commit functions. Perspective then calls the git commands on the GW in the respective project folders. This triggers commits to Azure DevOps.

From there Azure DevOps takes over and we have dozens of options on how to process the commit. Some projects the commit forces a project push to other servers via a DevOps release, other project require a pull request and when the PR is opens and/or closed a release is created which is picked up by a DevOps release pipeline and pushed to the appropriate Ignition Gateway.

So far this works for projects, then we need to tackle a similar approach for tag and db schema deployments.

4 Likes

Thanks for the information, I guess the one thing that differs a little bit is that all of our agents are all running the same solution so its really more larger team working on one solution. I think as long as we have EAM updating the current folder for Prod/Dev/QA we should be fine as its only one main project then its dependencies should push down if they are inheriting. Maybe I am wrong…

I suppose you created your own perspective view for that. I think I will have to do the same, as I don’t want automatic commit

Yes. @kfortin did most of the work on that view, maybe he can share a few of the details…