An improvement to working with git projects

Share Your Nodes
1

I recently switched to using the projects feature but felt it didn't give me a real benefit as far as version control goes because everything is squashed together in a single .json file.

I couldn't see any good solutions for this problem out there, so I built a flow to help with that. It runs in the background and splits all flows into separate, well readable .yml files every time a deployment is made.
These files can then be separately committed any time changes are made to a specific flow. This allows a better overview of the changes at the project level where you can see which flows have been changed, removed or added. Also function nodes are multiline, so changes in a function can be easier identified line by line in a diff.
The goal was mostly better organization of git repositories but it also offers the ability to revert a single .yml file to any point in time and to then merge it back into the main flows.json file.

Node Project Flow Splitter - Export flows to separate YAML files

image
image637Ă—1740 31 KB

2 Likes
2

That might make a great Node-RED plugin or custom node! :slight_smile:

3

That's very interesting.

Reminds me of this: node-red-contrib-flow-manager (node) - Node-RED (nodered.org) .

This one is also related: node-red-flow2src (node) - Node-RED (nodered.org)

I've never tried to use those, especially the first one looked too complex for me :slight_smile:

But with your solution it is much easier to see what's happening, and I don't need to install new nodes.

Some small things:

  • The 'Get flows' http request node has a URL field filled in, but the input message also contains msg.url. That override will trigger a warning in Node-RED 4 beta 1.
  • Personally I like to limit the number of rules in a change node, you could use a JSONata expression to simplify some things. For example to build the last API string: apiHost & '/flow/' & payload.id.
4

BTW, I encountered two practical issues using when trying out this flow.

  • when I use the roll back action, the affected tab moves to the end of the tab row
  • you have to remember to edit the name of the tab to roll back, and deploy, before pulling/editing a specific yml file
5

Yeah I looked at node-red-contrib-flow-manager too. It can handle subflows, which mine doesn't do yet but also seems to be geared towards a more advance use case than just prettying up your git repo.

The 'Get flows' http request node has a URL field filled in, but the input message also contains msg.url. That override will trigger a warning in Node-RED 4 beta 1.

Thanks, it's fixed now. I'm already getting these messages on 3.1.7 but that one must have slipped through when I was finishing up.

when I use the roll back action, the affected tab moves to the end of the tab row

I suppose that's a consequence of going through the admin API instead of working with the json file directly.

you have to remember to edit the name of the tab to roll back, and deploy, before pulling/editing a specific yml file

Your're right. I wasn't sure what you meant by this and then promptly made that exact mistake. If I go to edit the injection node with the name of the file I want to restore it will of course overwrite that file again. A solution for this would be a mechanism that prevents the file watch node from triggering when the flow is first deployed but the only way I can think of would be using a "inject once" node and those don't trigger when you're only deploying only modified flows, so that would only work when you're doing a full deploy every time.