- handbook
- Company
- Company
- Board
- Communications
- Decision making
- Guides
- KPIs and OKRs
- principles
- Remote Work
- Security
- Asset Management Policy
- Business Continuity & Disaster Recovery Policy
- Information Security Roles and Responsibilities
- Operations Security Policy
- Risk Management Policy
- Third-Party Risk Management Policy
- Human Resources Security Policy
- Access Control Policy
- Incident Response Plan
- Cryptography Policy
- Information Security Policy and Acceptable Use Policy
- Secure Development Policy
- Data Management Policy
- strategy
- values
- Operations
- Product
- Feedback
- Market Segments
- Metrics
- Node-RED Dashboard
- personas
- Pricing Principles
- Principles
- Responsibilities
- Strategy
- Versioning
- Customer department
- Customer
- Customer Success
- Hubspot
- Marketing
- How we work
- Marketing
- Video
- Customer Stories
- Social Media
- blog
- Community
- Marketing - Website
- Webinars
- FlowFuse Messaging
- Sales
- Engineering & Design Practices
- Design
- Engineering
- Certified Nodes
- contributing
- Front End
- Packaging Guidelines
- Platform Ops
- Deployment
- Incident Response
- Observability
- Production Environment
- FlowFuse Dedicated
- Staging Environment
- Project Management
- Releases
- Security Policy
- tools
- Website A/B Testing
- Internal Operations
- People Ops
# Packaging Guidelines
This section describes the requirements we have for all GitHub repositories, and npm modules we maintain.
To help ensure all of the requirements are met, an issue should be raised in
FlowFuse/admin
using the New Repository Checklist
and then worked through.
# GitHub projects
# Naming
- FlowFuse Components should start with
flowfuse-
- If a Node-RED plugin/node should start with
nr-
- Installers or Orchestration projects are named without the leading
flowfuse-
e.g.installer
orhelm
# Settings
- A rule should be added under the projects
settings/branches
to prevent pushing directly to themain
branch - The
Do not allow bypassing the above settings
rule should be ticked when creating the branch rules
# Content
All Git Repositories must contain the following files:
README.md
LICENSE
# Linting
All code repositories should adopt our standard linting rules by copying the
.eslintrc
from the FlowFuse/.github repository.
If a repository has any additional requirements for linting, such as handling Vue code, then additional plugins can be added.
We use StandardJS, with one exception - 4 spaces not 2.
# Notifications
Repositories should be added to the appropriate Slack channel. For core code repositories, this would be in the #gh-flowfuse
channel.
To create a subscription, go to that channel and type the message:
/github subscribe FlowFuse/NAME-OF-REPO comments reviews
This will subscribe to any notifications covering: issues
, pulls
, commits
, releases
, deployments
, comments
and reviews
.
# Workflows
# Project Automation
All code repositories must have the Project Automation workflow added. This is done by adding .github/workflows/project-automation.yml
. This workflow will ensure any opened issues are automatically added to the Product board where it can be triaged and prioritised.
# Release Publish
For any repositories that contain modules to be published to npm, they should also have a copy of .github/workflows/release-publish.yml
.
This workflow will publish to npm whenever the repository is tagged with a vX.Y.Z
format tag.
Note that each repository may have slightly different pre-publish requirements - for example if there is a build step or not. You may need to customise the workflow to match what is needed.
# Private Repositories
For private repositories, you will also need to add a Repository Secret as they cannot access the organisation-wide secret we have in place.
-
Generate a Personal Access Token with
repo, write:org
scope. -
Add it as a Repository Secret to the Private Repo (https://github.com/FlowFuse/
/settings/secrets/actions) with the name PROJECT_ACCESS_TOKEN
# Labels
We have a standard set of labels that should be applied to all repositories. This ensures we have a consistent approach to planning and tracking of work.
The definitive list of labels is maintained here and are synchronized across all repositories via GitHub Actions.
- Type:
epic
,story
,task
,bug
,artwork
- Sizing:
XS - 1
,S - 2
,M - 3
,L - 5
,XL - 8
,XXL - 13
- Area:
area:docs
,area:db
,area:migration
,area:frontend
,area:api
,area:device
,area:billing
,area:infrastrucutre
,area:install
,design
- Priority:
priority:high
,priority:medium
,priority:low
- Status:
blocked
,consideration
- Product Scope:
scope:devices
,scope:enterprise
,scope:node-red
,scope:collaboration
- Other:
good first issue
,upstream
,needs-triage
,headline
,backport
,research
New repositories must be added to the list in flowforge-repositories.yml
, and then the Synchronize Labels action manually run.
# NPM packages
# Naming
Note: we are migrating to the @flowfuse
scope of packages. See this issue
for details. This section of the handbook will be updated as part of the migration.
- All packages should be scoped to
@flowforge
Node-RED plugins should start with nr-
e.g.
- @flowforge/nr-storage
- @flowforge/nr-auth
FlowFuse plugins should start with forge-
e.g.
- @flowforge/forge-driver-localfs
- @flowforge/forge-driver-docker
- @flowforge/forge-driver-k8s
# Content
The package.json
must contain the following keys
- description
- repository
"repository": { "type": "git", "url": "git+https://github.com/FlowFuse/flowforge.git" },
- homepage
"homepage": "https://github.com/FlowFuse/flowforge#readme",
- bugs
"bugs": { "url": "https://github.com/FlowFuse/flowfuse/issues" },
- license
- Apache-2.0
- SEE LICENSE IN ./LICENSE
- author
"author": { "name": "FlowFuse Inc." },
- engines
"engines": { "node": ">=16.x" }
# Package Version Numbering
Package numbers should follow the Semantic Versioning Scheme as laid out on semver.org.
Each component will stay in step with the core flowforge/flowforge release numbering for major.minor
but will increment their own fix
values as needed. e.g. On release of v0.2.0 all components will tag and release v0.2.0, but can independently release v0.2.1 as needed.
Major and minor releases will follow the schedule laid out in the Cadence section of the handbook.
A Fix release can be made at any time, depending on the best judgement of the engineer making the fix but requires a review by another team member.
The process for making a release is documented here.
# Adding NPM packages to Stacks
As we build more FlowFuse specific nodes we will need to add these to the Stacks
# Localfs
Currently bundled packages for the localfs driver need to be added to the nr-launcher package.json
and the path to the node needs to be added to the nodesDir
array in the lib/launcher.js
file (around line 70). This will be updated in the next release to be controlled by the driver-localfs project
# Docker
Any nodes or themes should be added to the package.json
in node-red-container/
directory of the docker-compose project
# K8s
Any nodes or themes should be added to the package.json
in node-red-container/
directory of the helm project