Resource.json and git

We’ve been having some strange problems with how the resource.json files get handled when Ignition meets git. The resource.json files seem to update themselves after they are checked in or out.

I can do a git reset --hard to set everything back to the HEAD, run a git status, and see that everything is clean. If I wait a few seconds and run git status again, all of my projects’ resource.json files have been modified. When I do a git diff to see what changed, I see that the lastModificaitonSigniture has changed and the “lastModification” has been changed to the current time with an external actor.

I read through an earlier post on this http://forum.inductiveautomation.com/t/project-library-script-version-control/35262, and tried using Joseph’s .gitattribute file, but it did not make a difference.

Has anyone else seen this behavior?

1 Like

I suspect it has something to do with line endings. Inside every resource.json file there are attributes about the last modification:

    "lastModification": {
      "actor": "admin",
      "timestamp": "2020-09-11T20:45:10Z"
    },
    "lastModificationSignature": "875d5ae2c5c4fc47929bbd86fc4263dd44c0ae41f517da9ef3aa8325da4bcb8c"

The project directory is scanned for changes and a signature for contents of the newly changed resource is compared to the signature in lastModificationSignature attribute. If they don’t match, the assumption is that an external entity of some kind modified the resource in some way, so the resource.json file is updated to reflect that it has been modified by an external actor and has a new signature.

You probably have entries like this in your Ignition logs to go along with every resource you’re seeing this: “Setting LastModification to “external” on …”.

So something about your workflow is causing a mismatch between the signature in the resource.json file and the signature calculated from the actual resource contents.

What kinds of resources are you generally seeing this with?

This is a Perspective project, and I’m seeing it with the resource.json files for page-config, session-permissions, and session-props; for every view in the project; and for every script in the project library.

It seems to be a vicious cycle. If I reset a resource.json file to the HEAD of the git branch, it doesn’t show up in git as having been modified. But then Ignition sees that the resource.json file has changed, and so it makes another modification to it, to update the lastModification info. And now the file is out of sync with git. I don’t see a way out of this loop once you enter it.

You can’t just reset the resource.json file, you have to reset the entire resource folder. A resource is comprised of everything in its folder.

I am resetting the entire project. But at the time I reset it, the resource.json files are the only ones that are modified. Unless I misunderstand how git works in Windows, the code.py files don’t get modified when I reset the project. So it would appear that Ignition is updating the resource.json files because the git reset modified them.

I think may have committed your project in an inconsistent state then.

Not sure how it could get into such a state in the first place, but that must be it. In any case, I seem to have it in stable condition now. I had to

  • add @joseph.burns’s .gitattribute to the project’s repository;
  • commit all of the resource.json files in their current state; and
  • push the commit up to the origin.

As this revision gets pulled down and merged with other local repositories, I’ve had to repeat the process of committing all of the resource.json files. But at least for now, this seems to be holding.

Hmm, just a design question, what’s the purpose of having that checksum and “lastModification” info on the filesystem instead of in the database?

We’re trying to get things out of the database! :slight_smile:

Also it would mean every scan for project resource changes not only scanned the filesystem but then queried the internal DB.

1 Like

Glad to hear its working out for you Dan. Once I updated the .gitattributes file, I believe I had to run

git add --renormalize .

to stabilize everything. I haven’t had any problems since.

It turns out that it hasn’t quite worked out, it just took longer for the problems to resurface. I was going to try a couple other things before reviving the thread.

It’s still every single resource.json file being updated as soon as a branch is pulled and/or checked out on our shared development gateway. It does appear to be resolved on my personal gateway, although I’m getting a little gunshy at this point.

I had not been familiar with this --renormalize argument, however. I will try running that, and let you know how it goes.

1 Like

Alas, still no dice. It would be less maddening if it was always every single resource.json, or if it was always ones where some changes had been made. But I’m also seeing things like changing a couple of project scripts in a commit, and when I pull that commit down to another gateway that project modifies the resource.json files for six random views.

Hmmm that is frustrating. Is it only happening for view resource.json files since you renormalized? I haven’t seen any issues since updating my gitattributes, but I mostly use Vision.

It happens with resource.json files in ignition/script-python subdirectories as well as scripts.

Our setup is two developers developing Ignition projects on our Windows 10 desktops, with an Azure DevOps git repository as our origin.

If I have everything in my local repository committed, and I pull down from the origin, I will often within seconds see multiple resource.json files which have changes to commit, all updates since I pulled from the origin, wihtout my having touched anything.

The other scenarios is if I make a change to one script, the resource.json files of one or more other scripts that I haven’t even opened in the designer will show changes to commit.

IA probably won’t have much luck with source control systems if Ignition noticing a change in the source produces more changes in the source. That way lies madness. resource.json may need to be redesigned to not have the timestamp, or possibly not be source controlled at all (placed in .gitignore, perhaps).

2 Likes

Are you sure they aren't open? Even if it's in another workspace?

Vision resources will be considered modified with a timestamp update every time you save if they are open at all, even if the Vision workspace is not active.

I tried having git ignore resource.json for a while. The hassle there is that every time you pull a new view or script into your branch, you would have to manually grab the resource.json file. Or I suppose you could copy a dummy one and put it in place.

I’m not sure there is a solution as long as resource.json contains anything other than the actor of the last modification. Or maybe autogenerate it in a post-commit hook script so it can otherwise be in .gitignore.