FlowFuse
SubFlow Version control
Description
The idea here is for a sub-flow to function like a snapshot and act as a single source of truth.
If said sub-flow changes, then it could propagate to all instances that have said sub-flow.
This would be helpful in updating and maintaining similar instances that all reply upon the same sub-flow portion, but contain unique characteristics that can not be controlled for with snapshots and environment variables.
Which customers would this be available to
Enterprise Tier Only (EE)
Have you provided an initial effort estimate for this issue?
I have provided an initial effort estimate
Now that we have support for a team-wide npm repository, the proposal here is to take advantage of the fact subflows can be packaged and distributed as npm modules.
The high level workflow would be:
- User develops subflow in Instance A.
- When they want to share it with other instances, they package and publish to the team node repository
- The module can then be installed into any other team instances via the palette manager
- If there is an update to distribute, the subflow is updated in Instance A, then an updated module published to the team repo
- The module can then be updated via the palette manager in other instances.
The technical guide for how the packaging works is available here.
Subflows already have a 'Module Properties' tab in their edit dialog that allows the user to enter much of the required info:
From a UX point of view, the missing part is then the ability to publish to the team repository.
Proposal
- Create a NR plugin that provides:
- UI sidebar for managing subflow modules
- List subflows, allow user to view/edit the module meta data
- The existing form is free-form. We have strict requirements on module name when working with the team repo - need to validate and enforce in the sidebar UI
- Have a 'publish' button to trigger npm publish on the backend
- List subflows, allow user to view/edit the module meta data
- UI sidebar for managing subflow modules
Open problem: npm credentials
Currently instances/devices are provisioned with individual npm read-only token that do not have permission to publish to the registry. But this work will require the instance to have access to a write token.
Write tokens are scoped to individual users; for RBAC and auditing.
One potential solution; create an api end point that generates a short-lived npm token for a user. This can be called by the plugin backend as part of the publish workflow. (This short-lived token should not replace any existing token the user has provisioned manually via the UI).
For the UI Plugin for the Editor, do we want to consider a generalised "FlowFuse" plugin? We could extend that with creating snapshots, importing blueprints, etc. in the future? Rather than having scope for multiple tabs being added for each functionality?
@knolleary Would it be possible for a user to export the JSON of a subflow and create a node with it, without us needing engineering time here?
Yes. That is all possible to do today, but is a manual, technical process. The proposed scope of this item is the UI work to automate it, making it easy to do in the context of a low code tool.
Would it be possible for a user to export the JSON of a subflow and create a node with it, without us needing engineering time here?
The key here too is that if you import it, it just treats it like any imported flow, so has no tie-in the the "source". If a change is made to the subflow, it would be a manual process to have to go and update all the Instances that then used the subflow.
The proposal here is that the version control could be managed by publishing the subflow as a node to the Team's private NPM catalogue. By doing so, the source control is fully automated, and a user can update the subflow through the Node-RED palatte manager, without having to manually update flows.
PoC done. now need to make it "safe" and report errors.
https://flowforgeworkspace.slack.com/archives/C04GW82DJFK/p1755186033671719
https://github.com/user-attachments/assets/06cafd30-63ce-469c-90fc-ed9c04227080
While this is marked as Enterprise is it going to have it's own feature flag or be covered under the same flag as the Team NPM registry?
@gstout52 ^
While this is marked as Enterprise is it going to have it's own feature flag or be covered under the same flag as the Team NPM registry?
Given the dependency of the subflow version control on the Team NPM Registry, I think having them share the same flag is fine for now I'd say.
@joepavitt
- https://github.com/FlowFuse/nr-subflow-export
- https://github.com/FlowFuse/nr-launcher/pull/375
- https://github.com/FlowFuse/flowfuse/pull/5928
PR opened as https://github.com/FlowFuse/nr-subflow-export/pull/1 for the UI work
Outstanding items:
- [x] Follow "new Repo" process for nr-subflow-export plugin (https://github.com/FlowFuse/admin/issues/428)
- [x] Publish first release of nr-subflow-export plugin
- [x] Add it to the nr-launcher dependencies (https://github.com/FlowFuse/nr-launcher/pull/375)
- [x] Add it to the dev-env package so it is correctly linked (https://github.com/FlowFuse/dev-env/pull/39)
- [x] Merge forge app pr (#5928)
- [x] Merge nr-launcher pr (FlowFuse/nr-launcher#375)