I have all my workspaces version controlled with Git. At the moment I always have to login to the machines and commit/push everything manually. By workspace I mean the directory where your flow file, settings and local nodes reside, ~/.node-red by default. I use multiple workspaces on a single machine, each for different tasks and a different set of nodes. Each workspace uses a different repository, of course.
I know that if you enable "Projects", you can issue Git operations from within the Editor.
I also know could create a workspace with exactly one project to get that feature.
However, I don't want to use Projects, in fact, never have, because it doesn't make much sense to me in a production environment. Each workspace is responsible for exactly one runtime and needs to keep running. Also, the structure of the workspace would be completely different.
So would it be possible to enable the Git support in general, independent of the Projects feature?
The Git support seems to be hard-coded into the filesystem storage plug-in, which handles both single and project workspaces. But I cannot assess how much effort it would take to enable it for "normal" workspaces as well.
There's no specific workflow behind it. It would even be sufficient to just make commits to the local git working copy that manages the workspace. So you can keep track of changes and revert if necessary, same as you can with "Projects" now. That spares you to do all of that manually on the console, where you can't even distinguish between different deploys.
I think it is not that different, you just skip the project layer and get the same functionality for the whole workspace as you would with projects.
It doesn't matter which workflow you use or if it's production or not. My thought was, since it's already implemented in both front and back-end anyway, it might not be much trouble to enable it for "normal" workspaces as well. More like a general feature, because I think there are many here who manage their workspaces with Git.
It is implemented as an integral part of the projects feature. It would be a lot of trouble to change that.
Why don't you want to use the projects feature? Nothing requires you to create more than one project. You can forget you ever enabled it once it's set up.
Well, the easiest way to do this is to set up a flow to do it
I also have something on the backlog for uibuilder since it makes a lot of sense to have your front-end code under source control. But it wouldn't be automatic because that isn't common with source control. All it would really be is a button to commit, another to push to origin. Maybe with a dialog to capture the commit message. Just trying to hit the 80/90% mark of things that people need to do and make it easier.
Most likely, I will use npm and package.json's scripts capability because that would let me also run npm updates and the like with minimal coding.
You could also set up a "watcher" application that automatically committed your workspace after a watched file had changed. Again, you could probably do that with a flow though a separate script would probably be more sensible.
There is nothing really magic about either the Node-RED configuration/flow files or git and process automation is the heartblood of computing. So set up the common commands you want to run in the scripts section of your package.json file and add inject/exec flows to run them or set up a watch flow/script and run them that way instead.
That's what I suspected when I had a look at the code.
I'd have to migrate a lot of workspaces to the new structure, both at home and at work.
And it would introduce a new feature that could be used the wrong way. Not a problem for my systems at home, but at work even more so.
I think I will give it a try anyway on some test projects. Thank you Nick for the clarification.
That's how I solved it at the moment.
Using the existing features like commits (in project-mode) would give you atomic commits for each deploy, a clean state instead of one big change of the flows file.
Maybe at least the UI part could be reusable or enabled for a custom Storage plug-in. Have to investigate this...
Possibly the missing link here is a Node-RED wide event that is triggered when doing deploy's. Such an event could be listened for and actioned. That would make it pretty easy to create a Node that did all of this I would think.
Of course, Nick is probably now beating his head against a wall knowing that such a thing already exists?
If it doesn't exist, would it be relatively easy to add to the actions of the deploy API?
Actually, thinking about it, Node-RED already outputs info log messages when deploying so there must be a point in time that this could be picked up?
The first time you run with projects enabled it offers to do the migration for you.
Yes it's work involved. The alternative is an unknown amount of development time reimplementing features that are already available to you.
I don't follow. You want version control. Projects gives you version control.
Nothing stopping you creating your own local file system storage plugin that does all of the git handling automatically in the background. You just won't be able to expose it into the UI and will require all of the git setup to be done via the settings file.
Nick is on holiday trying not to revisit the 6 months of work that went into the projects feature where he had to deal with so many edge cases and use cases.
There is a PR I opened a while ago that made a start on a simplified got workflow (still only with projects enabled) that will automatically commit changes with every deploy. The sticking point was coming up with meaningful commit messages to help the user identify what changed when. I do want to revisit this, but as ever, it's in the backlog waiting for my time or someone else to be interested enough to help.
I didn't mean it that way nor did I want to impose any more work.
My line of thought was, some of the functionality is already in there, might be easily adopted to regular workspaces. But since I didn't write the code, it is hard to assess the effort. You could have said: "Oh, that's an easy one!"
No big deal really. That's why I started a discussion. I need to play around with the storage API a bit.
Now back to your holiday! Node-RED addiction confirmed...
I must admit I tend not to use projects a lot of the time (especially when writing nodes) - but just use git outside of Node-RED to manage "my projects" folder(s) - not exactly hard.
Where as I use Projects all the time on my local development machine. I can switch between different things I'm working on via the editor.
The alternative is having a folder full of 100 random flow files that I have to remember what's what. And restart Node-RED each time I need to quickly check something in one of them. Nothing wrong with that... just personal choice as to what works.
Personally, I just shove everything into my main flow file and then tidy up from time-to-time
As you say, each to their own.
Also personally, I wouldn't use projects in "live", I'd rather keep everything in a single, simple setup but have >1 instance of NR if I really needed to. I love that we have the choice though.
That's what I meant by "introduce a new feature that could be used the wrong way".
Because I'm not the only user in our professional use-case, I'd have to take care that no one accidentally created a new project and activated it. That would be... not so great. And sometimes, words aren't enough.
I think we just stick with the current workflow for now and keep projects disabled in live/production systems.
However, it's definitely worth a try for test environments, because I find myself having "a folder full of 100 random flow files" at the moment. Managing and switching these from the runtime is a benefit. Though I won't need the Git part there, I think.
