Flows Versioning

[Rogério R. Alcântara]

Hi there,

For my customer, flows versioning is a must-have requirement quite urgent.

I've already read the Design: -Version-Control wiki and, at first, we thought that the best storege would be the GIT approach.

Which begs the questions:

1. Should we try to implement this feature and send a PR?
   
   
2. Should we implement some manually temporary solution - versioning the flows files, for instance - and wait for the Version Control feature to be fully implemented?

On the second approach:

I've been failing miserably to change the flow file path.

On the `~/.node-red/settings.js` file, I've changed the flowFile property to `/flows/flows.js`:

module.exports = {
    ..

    // The file containing the flows. If not set, it defaults to flows_<hostname>.json
    flowFile: 'flows/flows.json',
    ..

But the flow is still being saved on the `~/.node-red/cat` file:

24 May 12:28:09 - [info] Node-RED version: v0.16.2
24 May 12:28:09 - [info] Node.js  version: v6.10.2
24 May 12:28:09 - [info] Darwin 16.6.0 x64 LE
...
24 May 12:28:12 - [info] Settings file  : /Users/roalcantara/.node-red/settings.js
24 May 12:28:12 - [info] User directory : /Users/roalcantara/.node-red
24 May 12:28:12 - [info] Flows file     : /Users/roalcantara/.node-red/cat

Even if I change it to `flows.js` (as suggested), I get the same result. Weird.

Any ideias?

Cheers.

Att.
Rogério

[Colin Law]

On 24 May 2017 at 17:19, Rogério R. Alcântara

<rogerio....@gmail.com> wrote:
> Hi there,
>
> For my customer, flows versioning is a must-have requirement quite urgent.
>
> I've already read the Design: -Version-Control wiki and, at first, we
> thought that the best storege would be the GIT approach.
>
> Which begs the questions:
>
> Should we try to implement this feature and send a PR?
>
> Should we implement some manually temporary solution - versioning the flows
> files, for instance - and wait for the Version Control feature to be fully
> implemented?

It depends what you mean by versioning. If you put the files in git
then they are implicitly versioned. If this is enough then there is no
need for changes in nodered, just use git manually to control the
files.

Colin

> --
> http://nodered.org
>
> Join us on Slack to continue the conversation: http://nodered.org/slack
> ---
> You received this message because you are subscribed to the Google Groups
> "Node-RED" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to node-red+u...@googlegroups.com.
> To post to this group, send email to node...@googlegroups.com.
> Visit this group at https://groups.google.com/group/node-red.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/node-red/93532b2d-6d67-4593-8709-25451113ef3f%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Nick O'Leary]

Hi Rogério,

the design you link to is a work in progress. It is not complete and has many open questions. It is not suitable for implementing in its current state.

Adding version control support is a priority item once we get 0.17 released in the very near future. So I'm keen to get the design fleshed out some more. Let me know if that's something you'd be interested in helping with.

As for the flow file/settings issue - the fact it is using a flow file called 'cat' suggests to me you are specifying the flow file on the command-line when you start node-red. Doing so overrides whatever the settings file says.

Nick

On 24 May 2017 at 17:19, Rogério R. Alcântara <rogerio....@gmail.com> wrote:

--

http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.

[Simon H]

about version control; it's one thing I really miss when using NR; I'm constantly aware that I'm modifying flows (complex function nodes) with no easy way of knowing what I changed when it no longer works tomorrow!.

I'm considering producing a temporary node which if in a flow and configured, on deploy, exports the flow, and also each function node's content as a .js file, all to a specified folder.  And then just have that folder managed by git as normal.

[Nick O'Leary]

Simon,

there is already a node in the community that lets you have a Function node that points at a .js file. Haven't tried it myself, but it's there.

Nick

On 25 May 2017 at 16:30, 'Simon H' via Node-RED <node...@googlegroups.com> wrote:

about version control; it's one thing I really miss when using NR; I'm constantly aware that I'm modifying flows (complex function nodes) with no easy way of knowing what I changed when it no longer works tomorrow!.

I'm considering producing a temporary node which if in a flow and configured, on deploy, exports the flow, and also each function node's content as a .js file, all to a specified folder.  And then just have that folder managed by git as normal.

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.

To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/c7b84500-3ccb-46fa-a6c8-e18e6cfe4f58%40googlegroups.com.

[Simon H]

tried it, but it loses the advantages of using the NR editor - which I love! :(.

[Colin Law]

Use Git. Then you can always get back to where you were. Also if you run

sed -r 's/\\n/\n/g' flowfile.json > flowfile.json.formatted

where flowfile.json is your flowfile, then that will generate a
formatted file that you can also commit so you can see in detail the
changes made at each commit.

Colin

On 25 May 2017 at 16:30, 'Simon H' via Node-RED
<node...@googlegroups.com> wrote:

> --
> http://nodered.org
>
> Join us on Slack to continue the conversation: http://nodered.org/slack
> ---
> You received this message because you are subscribed to the Google Groups
> "Node-RED" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to node-red+u...@googlegroups.com.

> To post to this group, send email to node...@googlegroups.com.
> Visit this group at https://groups.google.com/group/node-red.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/node-red/c7b84500-3ccb-46fa-a6c8-e18e6cfe4f58%40googlegroups.com.

[Simon H]

@Rogério

you may like my new set of nodes:

https://groups.google.com/forum/#!topic/node-red/ARdsT51kXQA

as an easy to use temporary solution until NR has some native support....

s

[Nathanaël Lécaudé]

Sadly the node that takes a js file is really old and doesn't support any of the newer functionality like context... I wouldn't recommend it.

[Rogério R. Alcântara]

Hi, everyone!

Thanks for the reply.

About manually versioning on git:

[TL;DR]

Given that I've got this node-red environment:

..
30 May 17:44:46 - [info] Settings file  : /Users/roalcantara/.node-red/settings.js
30 May 17:44:46 - [info] User directory : /Users/roalcantara/.node-red
30 May 17:44:46 - [info] Flows file     : /Users/roalcantara/.node-red/flows.json
..

In order to be able to restore this flow completely in another environment (server/docker/whatever), all the `/Users/roalcantara/.node-red` folder should be versioned, right?

[/TL;DR]

Now, just to clarify, I've come to realize that the customer need is a little bit more complex from what I've thought:

[LR]

I'm still studying my customer need - which is quite complex - but it is, basically:

0) Background:

Given a dev, staging, and production node-red instances (simple put: env) are up and running.
And a git repository with a staging and master branches.

1) Permissioning:

• Users can only edit flows on node-red dev env;
• Flows deployed on both staging, and production node-reds envs should not be editable by users.

2) Versioning:

• Users should commit and push flows to the staging branch;
• Users should list the flow's history changes containing author, created_at, and commit message;
• Users should restore a flow version (commit, tag) completely in the dev environment;

3) Continuous Deployment

• When a commit is pushed to the staging branch, a deployment to the staging environment should be fired.
• When a commit is merged with the master branch, a deployment to the production environment should be fired.

There is a lot more, actually - this is kinda draft.

At first, we will try to do all this "manually", using Git Kraken or something to validate this business process.

Then, we might try to create a custom Node trying to do these stuff on the red-ui-tab on node-red.

[/LR]

What you folks reckon?

Cheers.

BTW:

Nick said:
As for the flow file/settings issue - the fact it is using a flow file called 'cat' suggests to me you are specifying the flow file on the command-line when you start node-red. Doing so overrides whatever the settings file says.

This was pretty spot on!

Thanks, mate! ☺️