| navTitle | 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{rel="nofollow"}
using the New Repository Checklist and then worked through.
- 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.installerorhelm
- A rule should be added under the projects
settings/branchesto prevent pushing directly to themainbranch - The
Do not allow bypassing the above settingsrule should be ticked when creating the branch rules
All Git Repositories must contain the following files:
README.mdLICENSE
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.
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.
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.
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.
For private repositories, you will also need to add a Repository Secret as they cannot access the organization-wide secret we have in place.
-
Generate a Personal Access Token with
repo, write:orgscope. -
Add it as a Repository Secret to the Private Repo (https://github.com/FlowFuse//settings/secrets/actions) with the name
PROJECT_ACCESS_TOKEN
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.
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
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 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.
As we build more FlowFuse specific nodes we will need to add these to the Stacks
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
Any nodes or themes should be added to the package.json in node-red-container/ directory of the docker-compose project
Any nodes or themes should be added to the package.json in node-red-container/ directory of the helm project