I have a generic question. I am trying to keep my nodered flows within a GIT repo to enable versioning. So I export all the flows and copy them over into a git repo.
What I noticed there is that the "id" attribute of nodes seem to change on some occasions. I am not sure what the reason for that to happen is. The problem of course is now that I always have lot's of changes in each flow file (as al ids are different) and it is impossible to find out what really changed.
What is actually triggering the ids to become new ones? Are new Ids created on every import, or on every restart of the nodered service? Is there a way to keep the old ids?
Do you have any suggestions what I could improve to keep the ids consistent?
Thanks for your support.
Yes, dont export - simply version the
Better still, use the
projects feature for built in git history.
They can be yes. Not always.
Are you using subflows?
No, that should not change any IDs
flows ids will change, for many reasons... node-red will handle that changes without a problem... but quite frankly, I don't see the relation of your final question with the intro of your post.
You can do version control on git in two ways:
1- activate the "projects" feature on node-red (adjusting settings.js). This is the "node-red" way of doing version control, although you'd probably find it complex if you don't have more than one instance of node-red. (Pls. take this last comment as a very personal view I have).
2- create a repo, gitignore anything that is not relevant, and git commit on a regular basis.
Both options would work fine, even if the ids of the flows change from time to time for whatever reason
Hi Steve, thanks for your reply.
What is the difference between the export and the json file? Are they not the same?
In which version of Nodered got the projects feature implemented. I am at the moment only able to use a pretty old version. (1.x.x)
Yes I am also using subflows.
Probably the Ids change also comes from reimports. I am currently using an environment to develop and test features. When i need to go back to an older version to implement changes I am reimporting the old version to avoid having test fragments in the file. And then I adapt the code. After that I compare to previous versions. Before I commit I'd like to recheck what is commited, but since every Id changed it is impossible to find out the real changes. So basically I want to avoid to have changes in my repo that are just id changes. Is there any way to achieve that?
Probably this entire process can be optimized, but honestly I don't know how I could do better.
I don't remember exactly when projects were introduced (easy enough to find in the changelog) - BUT what I will say is - that version is almost 2 major releases old (be will be landing soon)
With projects I believe your workflow will improve so I'd recommend updating to latest version. In fact I'd recommend v3.0.0-beta.2 it is pretty much feature/API complete & has proven very stable.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.