flowfuse/mqtt-schema-agent repository overview

⁠Utility to gather active topics from any MQTT Broker

Not intended to be run manually, should be started by the FlowFuse k8s driver

⁠Release process

In this project, the Release Please⁠ is used to automatically determine the next release version based on the commit messages in the codebase.

By using the Conventional Commits⁠, the project adheres to a standardized format for commit messages, which Release Please uses to determine whether the next release should be a major, minor, or patch release.

⁠Components

1. The Prepare release GitHub Action workflow:

   • A Release Please action that analyzes commit messages to determine the type of release required (major, minor, patch) based on the Conventional Commits specification
   • Creates a pre-release pull request with the proposed version bump and changelog
   • Once merged, automatically updates the version number in package.json and creates a new release on GitHub with the appropriate changelog

2. The Lint Pull Request Title GitHub Action workflow:

   • A workflow that runs on pull request creation and uses the amannn/action-semantic-pull-request action to validate that pull request titles follow the Conventional Commits format
   • Together with adjusted default merge commit message, this ensures that all commits merged into the main branch adhere to the expected format, allowing Release Please to function correctly

⁠Pull Request Title Format

The Conventional Commits preset expects pull request titles to be in the following format:

<type>(<scope>): <subject>

• Type: Describes the category of the commit. Examples include:
  • feat: A new feature (triggers a minor version bump).
  • fix: A bug fix (triggers a patch version bump).
  • perf: A code change that improves performance (triggers a patch version bump).
  • refactor: A code change that neither fixes a bug nor adds a feature (does not trigger a release unless it's accompanied by a BREAKING CHANGE).
  • docs: Documentation-only changes (does not trigger a release).
  • chore: Changes to the build process or auxiliary tools and libraries (does not trigger a release).
• Scope: An optional part that provides additional context about what was changed (e.g., module, component).
• Subject: A brief description of the changes.

⁠Handling Breaking Changes

To indicate a breaking change, the exclamation mark ! should be used immediately after the type/scope:

• feat!:,
• fix!:
• refactor!: