I have been trying to use git for version control on an Ignition perspective project, and I have ran into some issues. I am running a gateway at my work station, so that I can make changes to my project and test them locally before integrating the changes into production.
I initialized a git repo in my projects folder, created a development branch, then created another branch to work on refactoring a few of the scripts on one of the views in my project. After refactoring the code and making several commits, I tried to checkout my development branch:
$ git checkout development
Unlink of file 'com.inductiveautomation.perspective/session-props/props.json' failed. Should I try again? (y/n) y
I figured that it failed to unlink some of the files because I still had the gateway running in the background, so I stopped that, but still got the same message. Not knowing what to do, I told git to not try again for all the files that it couldn’t unlink, so now I am in my development branch with a whole list of untracked changes that belong in the other branch.
I am beginning to think that my life might be easier without using git with Ignition, but I wanted to check here first to see if I am doing it wrong, or if somebody else has a solution to version control in Ignition.
I’m trying to set up the same type of development environment you describe (gateway on localhost using multiple Git branches in a project), but I’m struggling with it. Switching branches in Git does not consistently update the project in the Designer. None of the following steps seem to force the Designer to load the branch’s files:
update project (Ctrl+Shift+U)
reopen the project
close and reopen the designer
delete the .resource directory in the projects directory
Eventually, the Designer does seem to detect a change, and I’m able to use the “Update Project” function, but it’s unclear what triggers this. It just happens at random a minute or two after switching branches.
If anyone has any advice about how to properly switch branches in an Ignition project, I’d love to hear it.
I’ve changed the ignition.conf file, and this appears to work. Is there a different way we can trigger Ignition to scan the file system immediately instead?
Interested in this too. We have Azure DevOps pushing projects to gateways from Pull Requests and a triggered project refresh would be cool. For now we will just set the scan to 60 seconds.
We use git (bitbucket) as well for ignition version control.
The engineers have local branch for development and then we merge changes to dev branch which is pulled on dev on-prem server and then merge to prod branch which is pulled on prod server.
As such everything is working well.
The challenge (other than running sourcetree in admin, which I have a solution for but not a big deal) is that code review during pull request is painful.
Even a small change results in many many files changing which we dont really care about.
Cant ignore those json files as they are needed for a clean installs.
Code review can be a challenge for us, too. We generally skip over resource.json files during the review.
Perhaps the biggest challenge is reviewing Python code in view.json files, since it’s typically all stored on one long line in json. For these files, we have a script for Beyond Compare that translates escape sequences (i.e. new lines and tabs) to be displayed as their actual characters. This really improves the readability of the code and helps with code reviews. Here’s the Python code that Beyond Compare runs each time it opens a view.json file:
import sys
input_file_path = sys.argv[1]
output_file_path = sys.argv[2]
with open(input_file_path, 'rb') as input_file:
input_file_contents = input_file.read()
output_file_contents = input_file_contents.decode('unicode-escape')
with open(output_file_path, 'w') as output_file:
output_file.write(output_file_contents)
First thing I just changed on bitbucket is to ignore resource.json and prop.json files in pull request so at least it will keep the file differences to relevant ones.
Next I will look at your suggestion.
Keep in mind there are times you definitely do not want to ignore changes to resource.json files. For instance, named queries use resource.json to store input parameters. If these parameters change on a named query, you’ll want to commit the change made to the query’s resource.json file.