I know (at least as of 8.1) you can reconfigure the scan rate at startup time with the ignition.projects.scanFrequency definition in your ignition.conf file, but is there a way to temporarily pause scanning just while doing some external operation that might temporarily put the projects directories in a weird state?
I’m looking for some way to do some git commands without having to stop or restart the server, and only have it scan and use the new files once I have had a chance to validate the git changes worked cleanly.
Yes, I know the proper method is to do all the changes on a separate copy of the git repo and make it so the server can just be pulled forward to that new commit. But, I’m in a weird spot with a development server that the projects directory is an uncommitted mess but I also would rather not have to stop serving projects from it while cleaning it up. (Trying not to bump a long-running test…)
No, but we’ve discussed a similar idea internally, where you can disable scanning but trigger by some external means like touching a file… nothing we’ve made any decision on yet though.
I hit it this morning! I was doing a git pull and Ignition just happened to scan one of my reports mid-change and freak out. Got this in the log right at the same time I did the pull:
customer Report 'AutomaticPower' deserialization did not return an object
After that the report could no longer be opened in Designer, and was showing uncommitted local changes in git. I just did a git checkout to set it back to where the pull was supposed to have put it and I’m good to go again.
But, yeah, confirmation of the concept. It can definitely happen. I kinda guessed exactly what had happened as soon as I saw it because of this thread.
@Kevin.Herron Any progress on this front? We had an odd issue the other day…
We are using DevOps to handle deployments. In our DEV environment the projects are controlled in GIT, we then push to DevOps. Once there we are using DevOps release pipelines to copy the target project to the TEST and/or PROD environment as defined in the pipeline. DevOps is copying the artifacts to the projects folder.
What happened is it seemed that the projects folder scan process picked up in the middle of DevOps writing out the files, normally this wouldn’t be the end of the world and the next scan, missing files would be imported. However in this case it seems the project was refreshed and more specifically script resources were loaded into memory, but one script was missing resulting in errors. It showed up in the designer and in the filesystem, but running gateway scripts could not locate the script. It was a weird situation where it seems what was loaded into memory was different than the filesystem.
Restarting the affected project fixed the issue right away. I assume this was a needle in haystack possibility, but still wanted to bring it up. The ability to “tell” Ignition a project has been changed either though an API call, file touch, etc would be valuable to ensure externally deployment tools can confirm a project was refreshed as part of the deployment.
Yes, ability to pause the standard scanning is a good idea to ensure external deployments don't conflict with any internal processes. Maybe with some reasonable timeout value to auto-restart the scanning if for some reason a process fails to re-enable the scanning.
We do not run git on any of our production environments, its just a simple file copy via a DevOps deployment node. We found keeping a git repo on every gateway for every project did not add much value and was a lot of server side maintenance with git setups and config (at least on windows).
though it is a old thread, [ and came here for the system.project.scan() reference, ]..
most of the users would have already solved the similar way, i wanted to share the below small detail that how we do automated deployments with git actions is, as part of the pipeline we delete the ".resources" folder in the "projects" directory, and the timer action waits for the same ".resources" folder to regenerate , this does confirm that the ignition project scan is complete, and picks up the new file changes.
and for the local dev environments - the project scan rate is set to minimum as of now, but will use the system.project.scan() triggered going forward.