Not on the same desktop, they aren’t open. In most cases they haven’t even been opened and closed since the last pull, merge, or commit.
And these are projects where we are not using any Vision resources at all.
The last modification is actor, timestamp, and signature of the resource contents.
Changes made within Ignition should always save without a subsequent scan complaining.
Changes made externally, e.g. with a text editor, likely won't be able to update any of the info, so on the next scan when Ignition notices this resource changed it writes back a modified copy indicating the last modification was external and an updated signature.
This does make things a bit unfriendly for using an external editor, but shouldn't be unfriendly to VCS in general.
No, it should be honoring the actor, timestamp, and signature supplied by the external pull. It should be regenerated only if the external change didn't supply a new resource.json (like a direct edit in the filesystem). Or it should be excluded/excludable from source control.
It will, if the signature is correct.
How is the signature calculated? If one gateway’s signature won’t be honored by another gateway when the entire resource is replaced, the signature can’t be considered friendly to source control. And if resource content is text (like Perspective), and git successfully merges two independent changes by others, Ignition is going to make another change because neither source signature could be correct. This signature is very unfriendly. I recommend the signature be split into another file and that other file be excluded from source control.
If one gateway’s signature won’t be honored by another gateway when the entire resource is replaced, the signature can’t be considered friendly to source control.
Yes, you're right, but this isn't how it should work, one gateway's signature should be honored anywhere. The signature calculation is just a hash, it should be completely deterministic regardless of where and when it is calculated. That's why I'm a bit perplexed as to the cause of the behavior described in this thread...
2 Likes
I ran into the problem again, and it happens reliably for a specific commit. Here’s how to replicate it if anyone is interested:
git clone https://github.com/jlbcontrols/Flintium.git
git checkout 3c6be9171f5f2ee8356b4f7537f994a84c6f17e3
At this point, git status shows no changes. If you start a new, clean Ignition Gateway with this project, it will show resource.json changes for two scripts. If you have docker-compose you can try it:
cd ./Flintium/docker/devenv
docker-compose up
This doesn’t really help because as far as Ignition is concerned this behavior is expected.
These 2 resources have incorrect signatures given their contents. It’s expected that Ignition will then update the the last modified timestamp and signature and write that back to the resource.json file.
What would be more interesting is how that incorrect signature got there in the first place. As mentioned previously, if you’re editing the code.py files in an external editor then that is likely to lead to you committing with a signature that isn’t correct. If that’s not what’s causing it, then whatever is would be the interesting thing to reproduce.
That will be tougher to catch! I can tell you it was not edited externally though.
I wonder if it is inadvertently being modified externally then, or if there is a save bug lurking somewhere, or what… because even the previous version before Ignition catches this incorrect hash and writes it back indicates it was modified externally:
git diff ignition/script-python/flintiumscripts/administration/tagfiles/exporternode/resource.json
diff --git a/ignition/script-python/flintiumscripts/administration/tagfiles/exporternode/resource.json b/ignition/script-python/flintiumscripts/administration/tagfiles/exporternode/resource.json
index 39467af..ae14213 100644
--- a/ignition/script-python/flintiumscripts/administration/tagfiles/exporternode/resource.json
+++ b/ignition/script-python/flintiumscripts/administration/tagfiles/exporternode/resource.json
@@ -9,8 +9,8 @@
"attributes": {
"lastModification": {
"actor": "external",
- "timestamp": "2020-06-27T16:39:03Z"
+ "timestamp": "2020-10-18T20:18:54Z"
},
- "lastModificationSignature": "48f6b565e3e26fc5167150c7914227340065a948187dd2617d2990931b8412ac"
+ "lastModificationSignature": "8f40494624197d92c7095b4e88411a6925addc955837c9d28137bf52cc3fc6d3"
}
}
Of course the previous “external” modification could have just been another case where Ignition corrected an incorrect hash with no other actual changes, but it all had to start somewhere, somehow…
I agree it sounds like a save bug or an inadvertent external change. I only manipulate these files externally with git commands that change both script and resource.json at the same time to another state with valid signature… checkout, reset, etc.
1 Like
@joseph.burns, @Dan_Bridgeman - hoping to resurrect this thread. Did you guys find any solutions to this? I’m running into the same problem in our development workflow. We are also using Azure DevOps Git source control and we’re all developing individually on our own gateway instances. We have a batch file in our repo that uses symlink to hard link the local repo files to the Ignition projects directory. I’m getting the same error as you Dan, with multiple resource types (Vision windows, python scripts, Perspective views, etc.) showing a modified resource.json file when I run ‘git status’.
There isn’t going to be a solution until IA splits the resource.json into separate files–one that carries resource metadata that supplements but is independent of the resource content, and one that carries the housekeeping for the resource system. The former would be git-merge compatible, the latter would get an entry in .gitignore.
Signatures and timestamps and audit traces (any generated material) are fundamentally incompatible with treatment as source-control content.
1 Like
@andrea.tidwell Unfortunately I haven’t found a solution.
@pturmel I’d like separate metadata as well, but don’t see any reason why it couldn’t work as-is (if it was functioning correctly). There shouldn’t be any phantom changes if no edits were made.
1 Like
Same on both counts.
I tried putting resource.json in .gitignore, which went about as well as you’d imagine.
At this point my workaround is to stash the rogue resource.json modifications when I need to pull from the origin or merge from another branch. They come back pretty quickly, but it works well enough. Then when there are enough of them that they’re starting to clutter the status, I commit them by themselves, so they don’t confuse any actual code changes.
1 Like
Perhaps I wasn't clear?
Just a bit vague. The current system is acceptable when it works. A new timestamp doesn’t bother me if the associated file actually changed.
1 Like
I could see it working if resource.json only changed when the cksum of code.py (or whatever) had changed, but it seems to be using timestamps. And in theory this could work, but something seems to touch the code files in a way that changes their timestamps. It would lead to less hair-pulling if it were at least consistent, but I’ve not been able to find a rhyme nor reason behind it.
Of course the cksum method would only work if everyone agreed on the same whitespace and EOL formatting, but I believe you can configure git to standardize all that.
I’m having a similar problem with subversion. I get a lot of conflicts on the resource.json files when I try to check in. In this case, I notice that SVN shows a login time of 11/21/2021 6:07 PM. Then when I go to check the file timestamp, it is showing 11/21/2021 6:01 PM, six minutes before the checkin, so SVN believes a file conflict happened, and I have to go through a nerve-wracking process of un-conflicting everything. I guess it’s a little les nerve-wracking now that I understand more about what is happening
Any traction or addition suggestions on this topic? When going through a code reviews it is very tedious to have to scroll through 400 changes to find the 1 file with the 1 line of code changed.