Upgrade from 8.0.16 to 8.1.10 in a git managed system - now having issues

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.


One of the project folders:

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?

The project scan time was slowed to 5 minutes by default in 8.1. You can increase it with a parameter in ignition.conf

Although having restarted the Ignition service should have caused any changes to get picked up, so maybe it's something else...

Hi Kevin,
Now that you mentioned it, I do recall this being said in a webinar somewhere.
Thanks for reminding me! :+1: :slightly_smiling_face:

Hey @Kevin.Herron, I’ve added this to my ignition.conf file:

# Java Additional Parameters
wrapper.java.additional.1=-Ddata.dir=data
#wrapper.java.additional.3=-Xdebug
#wrapper.java.additional.4=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:8000
wrapper.java.additional.2=-Dignition.projects.scanFrequency=60

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):


There should be three project there.
Is my scanFrequency line formatted correctly?
What else may be causing this to happen, if anything?

Looks right to me. Not sure what else could be going wrong. I don’t have a git setup handy, but when I copy and paste a project folder with a new name it picks it up just fine.

The folders and project content are there.
The GW just doesn’t see them for some reason.

Does it pick them up after a gateway restart? Did you restart after modifying ignition.conf?

I restarted the Ignition service (a couple of times) with no resolution.
I have not tried rebooting the server.

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?

There is no upgrade process beyond 7.9 to 8.x.

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.

I have a feeling that this is part of my issue. That and the use of git. The various versioning of the different files/components and how git handles merging, seems to be causing a huge issue for me.

If you zip one of the projects that Ignition isn’t able to detect on startup and provide it to support we may be able to see what’s wrong and if there’s any potential fix.

A quick update. Somewhere along the way (a year or so ago) we tried using the git command

git ls-files -z '**/resource.json' | xargs -0 git update-index --assume-unchanged

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! :frowning:

1 Like