Concerns when following the "Deployment Best Practices" guide

I’ve been following the “Ignition 8 Deployment Best Practices” guide for some time now for our own infrastructure and have run into concerns about some behavior I’ve been seeing especially as our project grows more complex.

Our setup involves individual developers using a local copy of ignition for development and creating/developing on their own feature branches, and then changes get merged into a testing branch for testing on a staging server, and then those changes get merged into master for production.

The main concern we run into is Ignition’s handling of resource.json files. It seems that basically every time an action is performed that updates the project in any way via git, the ignition gateway updates every single resource.json file in all Perspective views (at least it appears to mostly/only be Perspective views). In our case, this results in nearly 100 changes and, due to our workflow, sometimes results in merge conflicts that require manual resolving for every one of these files.

From what I can tell, I don’t believe that the resource.json files can simply be ignored by git, since that would cause problems when new things are merged into the gateway, if I recall correctly, things don’t work properly if the resource.json file isn’t present for a resource.

Is there anything that can be done to alleviate these issues? Is there a chance that changes are coming that will make Ignition work more nicely with git?

1 Like

I face the exact same problem.
Perhaps the Ignition team knows a way for us to ignore these changes, or a way to separate these changes into a different file that can be put in .gitignore

Ideally, we should only have to revision control the files that are needed to repeatably build the same software. Anything that is generated (especially if the generated content is random) should be isolated somehow.

Are you pushing/pulling across platforms (Windows <-> Linux)? Are your git settings set up to unify linefeeds?

My development system is Linux, and the testing/production servers are Windows servers.

However, I believe that git unifies line feeds because none of the changes to the files have anything to do with line endings. It’s always the modification timestamp/modification signature in the resource.json that gets changed by Ignition and causes problems.

Right, but the system sets that actor: external value when it detects a signature mismatch between the content of resource.json and the hash in the file. My hunch is that the hash calculated on Windows is not correct for the file restored on Linux, hence the mismatch and overwrite.

I’ve attempted to get the line endings unified, but I can’t seem to get the issue to go away.

Like I mentioned over a month ago, I’ve seemingly configured git to unify line endings using whatever solutions I was able to find. However, this behavior is continuing to cause serious issues for our merging workflow. At this point I think I’ll just need to write some kind of script to automatically fix the 250+ merge conflicts that come up when trying to merge changes.

I don’t know if there’s any way that Ignition itself could be set up to make version control better, but I still think that needing to have the resource.json files in source control at all is causing a whole lot of headache. But I understand that it’d probably be an incredible amount of work to change how that behaves.

Have you tried forcing LF line endings on checkout for all resource.json files in your .gitattributes?

Add this line to .gitattributes:
resource.json text eol=lf
Then run:
git add --renormalize .