We recently upgraded our product version from 8.0.16 to 8.1.10.
We use git and GitHub as a version control solution.
Ever since the upgrade I’ve noticed issues when pulling branches to my dev system or to the servers we use. The first thing I notices was after pulling a branch and opening a session, I was presented with a “view does not exist” message. Checking the folders and files showed that the content was in place. Opening a designer however, presented a different picture. The designer didn’t show any views, or styles. I did not investigate Project Library scripts, Named Queries, or other content.
After this I closed the designer and performed a
git reset --hard origin/my_feature_branch
After finding the issues was still present, I performed the hard reset again.
This time it seemed to take.
Another developer working on the same project has had the same issue with the same resolution.
Now I’ve found myself in a new conundrum. I created a new branch in GitHub from our development branch. I pulled that to my dev system and tried to open a designer. This time I got the window wanting me to add/import projects. Going to the Gateway Config/Projects page, it shows I have no projects!
I’ve done the hard reset a couple of time. Restarted the Ignition service. Restarted my system. All to no avail.
I did notice that the Named Queries retain the data.bin file until they are actually opened and saved. Is there any possibility that there are files that are at an old rev sitting in our repository that when pulled to a Gateway can cause things like this to break?
I’m trying to set the scan freq to 60 seconds.
I merged a branch into my development branch and pulled (fast forward merge) the new development branch to my validation server, but even after several minutes I’m still seeing no projects on the server (in the GW webpage):
If they aren’t getting picked up when you restart there must be something wrong with the structure or contents… you might need to work with support so they can look at your logs and directory structure/contents.
I am finding a lot of Named Queries, that even though I had gone through and opened and saved them all to get them to convert to the new format (query.sql and the new resouce.json content), a number of them seem to still have the old resource.json files in the repository, and therefore on the server once I pull the development branch down to the server. I also had an issue with the Perspective General Properties files. I had gotten rid of the “overrides” so that the Id Provider in the Project Props. General category would control that, but on merging that newer branch with the older development branch, it deleted the data.bin folder but kept the resource.json file for the Perspective General Properties.
That brings me to a question. Why does the upgrade process not automatically convert the data.bin and resource files to the 8.1.x format?
Something changes the data.bin and resource.json files to a query.sql and a resource.json file that contains the NQ’s configuration (parameters, type, etc.) when you open and save the NQ. Why do these have to be edited before that process occurs?
Okay, I should have been more clear. There is no sweeping process on startup that looks at all your resources and sees if there is a newer version of it available. Every resource is responsible for managing its own versioning and serialization. Some resources may be provided by modules and we know nothing about them.
It’s easier and safer to only upgrade resources to newer versions when they are saved again.
to mark resource files as untracked.
We have not been doing this as it was more cumbersome than simply dealing with the resource files (in my opinion) since we tried it way back when. Apparently there were half a dozen or so files that had not been set back to be tracked so the new forms of the resource files were NOT being pulled to the server. I found this when I actually deleted the files on GitHub directly then pushed the branch from my dev machine and saw that the newly formed resource files were still the old versions and were dated almost a year ago. Once I set them back to a tracked status and pushed to the repo, then pulled to the server, things started working normally again!
Git is a frustrating beast!