Node server update fails with (pullrepo: undefined)
Opened this issue · 6 comments
The error message is not helpful to the end user at all and should be improved. But the larger issue is that this is happening more frequently as more folks start using Polisy/Polyglot.
This error indicates that the 'git pull' command failed in the local repository. This may be because the pull would cause conflicts or because some file in the repository was changed locally and would now get overwritten by the pull. In either case, there isn't a lot that the end-user can do to fix this without knowing something about how git works and manually correcting the problem using Unix command line commands.
I see three possible fixes:
-
change the command to be git pull -f and force the pull to overwrite files. The downside is that this may cause unsaved files to be lost by node server developers while developing or advanced users that are messing around with the code.
-
add an option to force the upgrade. When the above fails, give the user the option to try again with the '-f' option. I.E. pop up an alert "This action may overwrite file in your local installation. Proceed Y/N?"
-
create a much more complex upgrade option that clones the repository to a temporary location then runs a user defined upgrade script to copy the appropriate files to the local installation or something like that. This method could also be used for initial installation so that what is installed locally isn't an actual git repository but only the files needed to run the node server.
Just to be complete, since I think bpaauwe meant this to go without saying:
- Write the detailed information from a git status command to the log so that the specific file(s) modified can be documented -- and provide feedback to node server developers regarding development practices required so as to prevent node servers from modifying their own git-controlled data, and feedback to users regarding admin/command-line access practices so as to prevent users from modifying git-controlled data.
In other words - this shouldn't happen, and the first and foremost action before taking on one of the three suggested actions should be to log enough information to find out what changed and when it changed, so that we can prevent this from happening in the first place. (I'm of the opinion that rather than inventing an easier way to solve a problem, we should avoid the problem in the first place!)
Just to be complete, since I think bpaauwe meant this to go without saying:
- Write the detailed information from a git status command to the log so that the specific file(s) modified can be documented -- and provide feedback to node server developers regarding development practices required so as to prevent node servers from modifying their own git-controlled data, and feedback to users regarding admin/command-line access practices so as to prevent users from modifying git-controlled data.
In other words - this shouldn't happen, and the first and foremost action before taking on one of the three suggested actions should be to log enough information to find out what changed and when it changed, so that we can prevent this from happening in the first place. (I'm of the opinion that rather than inventing an easier way to solve a problem, we should avoid the problem in the first place!)
I believe it does log more detailed information, but currently only if Polyglot debugging mode is enabled (which it isn't for normal installations). There's already an issue open to have this information moved to the normal log.
While it may seem like this shouldn't happen, there are a number reasons why it may and even some where it can't be avoided. Currently, Polyglot itself writes files in the repositories directory structure (logs, profile.zip, python cache files) so it's possible that may modify something that causes the pull to fail. Also files may be changed intentionally by the node server itself. I've written node servers that modify the profile files based on the user configuration. Since the node server installation will fail if those files aren't present, I have to have initial versions in the repository. It should be possible to perform an upgrade regardless of the state of the local installation.
Yes, as mentioned in #41 the messages are shown in the log, but only when debug mode is enabled. IMO, it would be nicer if when you clicked update or install that it started a popup with just the logging for that process so you can easily see the status as it progresses and where it fails. All the info from this issue should have just been added to #41... This is also related to #85 where the install process should provided more information as well.
@bpaauwe For my nodeservers that modify the profile, I store the files in a template directory then copy them over to the profile directory when updated so the files managed by git are never touched.
Regarding modifying versioned files -- OUCH! I shall defer to the polyglot architects for their expertise, but in all my many years I've never encountered a case where an architect permitted this sort of coding as acceptable by design. That's not to say I've not seen it -- just that every time I've seen this, it's been classified as a bug. I'd urge the Polyglot architects to stipulate the requirement that no Poly should ever modify it's own git-managed files. Anything else is chaos and confusion.
Newbie here! I want to propose code changes to the developers of the NodeServers. I also want to test them before requesting them. Just worked through my first request and sure enough I ran into this exact problem. Ended up having to uninstall, reinstall, and reconfigure my node server (hope I didn't lose links to my programs in ISY)
Perhaps we need to be able to install a 2nd copy of a NodeServer which can be used for testing/code changes. Like a SandBox...
I even tried creating a new Remote Repository with my code changes but couldn't find a way to install these into the PolyGlot..
The other option is to blindly propose code changes and rely only on the developer to test them ..