IRTE Flow Engine

About

Engine for future IR Tech sport apps

Versioning

This project follows the flavor of semver used by pub. This has some key differences from the regular semver, see pub_semver.

Latest version

0.0.1

Changelog

Changes and fixes are documented in CHANGELOG.md.

Installation

Refer to this package as a dependency using the git URL, see Git packages.

Example

dependencies:
  irte_engine:
    git:
      url: git@bitbucket.org:ir-tech/flow.engine.git
      ref: v0.0.1

Development Guide

Package resolution

To use this repository for development, simply use the path to refer to the location of this package from another project (e.g. Sample App).

See Path packages

Commit Hooks

git_hooks is used to run commands at each hook during the git lifecycle and enforce certain rules. If any of the commands return a failure status or throw an error, the git commit is aborted.

Before your first commit please ensure the hooks are initialized in your environment by running.

flutter pub run git_hooks create bin/git_hooks.dart

Pre-commit

Code Fixes

Apply automated fixes to Dart source code.

The dart fix tool is used to look for and fix analysis issues that have associated automated fixes.

Formatting

Whitespace is formatted using the dart format commands.

Lint

Linting is performed with the dart analyze command. The rules for analysis are provided for by flutter_lints and any modifications can be found in the analyzer_options.yaml file.

Commit-msg

Commit Message

The commit message is validated against Convention Commit Format using the lintCommit function from conventional We need this to ensure a clean, auto generated changelog.

Syntax

type[(scope)?]: description

[body?]

[BREAKING CHANGE: reason?]
[Refs?]

Header

The first line of the commit message type[(scope)?]: description is called the header.
This line should not exceed 100 characters.

Type (required)

Must be one of the following (lower case only):

• build: Changes that affect the build system or external dependencies (example scopes: pub)
• ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
• docs: Documentation only changes
• feat: A new feature
• fix: A bug fix
• perf: A code change that improves performance
• refactor: A code change that neither fixes a bug nor adds a feature
• revert: If the commit reverts a previous commit, it should begin with revert: , followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• test: Adding missing tests or correcting existing tests The type can be one of the following. This is case sensitive and must be written in lower case.

build, ci, docs, feat, fix, perf, refactor, revert, style, test, chore

Scope (optional)

Scope is optional; multiple scopes are supported (current delimiter options: "/", "" and ",")`

Description (required)

A brief description of changes being committed.

Body (optional)

This consists of one or more lines of text preceeded by a new line. This can be used to provide further details of changes in the current commit.

Breaking change (optional)

Indicate a breaking change in a new line below the header by starting a line with BREAKING CHANGE:. This would then be followed by a brief desription of the breaking change on that line.

References (optional but encouraged)

One or more references can be included to link taks/issues with a commit.
This may follow one or more words indicating how the reference relates to the commit e.g. Solves #FLOW-12.

Examples

fix(audio-engine): pause playback 

A body describing this commit in more detail.

The body in this example is multi-line.

BREAKING CHANGE: This is a breaking change because of X Y Z.

Fixes #FLOW-1

More Examples

Post commit

Docs generation

dartdoc is used to create API reference documentation from the source code. For guidance on writing doc comments, see the documentation part of Effective Dart.

Pre-push

Tests

Run tests

flutter test

Unit-Test

The Unit tests will be checked. Any failing test will stop the commit.

CI Pipelines

CI pipelines are executed using Bitbucket pipelines. Current configuration can be found in bitbucket-pipelines.yml.

Operations

Code coverage

Code coverage is generated using the test command flutter test --coverage.
This will generate a file that is ignored by source control at coverage/lcov.info.
This step is done automatically by Bitbucket CI within the pipeline and results are sent to Codecov for analysis. This step is done for each Pull Request commit and for merges to the develop branch.
The current coverage can be viewed at the CodeCov Dashboard.

No current code coverage limit is set.

In the future, this may be set and required.

Ignore lines from coverage

// coverage:ignore-line to ignore one line.
// coverage:ignore-start and // coverage:ignore-end to ignore range of lines inclusive.
// coverage:ignore-file to ignore the whole file.

Release/Changelog generation

The changelog is automatically generated and updated based on the commit messages of the commits present within a release. Automatic changelog generation is produced using conventional. This will be done for pubspec.yaml

Important: Don't commit other changes while doing a release. Commit them separately. Important: Make sure your working directly is clean. Important: Follow SemVer

To make a release, you can simply use flutter run scripts/release.dart. This will use the nextVersion function of conventional to determine the next version for the release based on the commits since the previous release. Once the changes are made for the release then run git push --follow-tags origin master to push the changes to the repository