Skip to content

Latest commit

 

History

History
151 lines (103 loc) · 4.39 KB

CONTRIBUTING.md

File metadata and controls

151 lines (103 loc) · 4.39 KB
Raw

Leto Modelizer (leto-modelizer)

Technical topology low-code editing tool.

Install

npm install

Default commands

Usage explanation of scripts in package.json.

dev

Run the application in dev mode.

build

Build the application in dist folder.

prepare:docs

Prepare jsdoc to generate documentation.

build:docs

Generate documentation with jsdoc.

lint

Run eslint to check on the project.

lint:fix

Run eslint to fix on the project.

lint:report

Generate issues report with eslint for sonar.

test

Run all the unit tests.

test:coverage

Run all the unit tests and generate coverage report of the unit tests for sonar.

test:e2e

To run all the e2e tests, you need to run the application with ALL official plugins and use specific url for library of template:

npm ci
npm run plugin:install -- name="terrator-plugin" version="0.12.2"
npm run plugin:install -- name="githubator-plugin" version="0.5.2"
TEMPLATE_LIBRARY_BASE_URL="https://raw.githubusercontent.com/ditrit/leto-modelizer-templates-library/leto-modelizer/e2e_test" npm run dev

Run the e2e tests locally with specific proxy

  1. Install terrator-plugin and githubator-plugin
npm ci
npm run plugin:install -- name="terrator-plugin" version="0.12.2"
npm run plugin:install -- name="githubator-plugin" version="0.5.2"
  1. Build the application for e2e tests
docker build -t leto-modelizer -f DockerfileE2E .
  1. Run the application
docker run -p 8080:80 -d leto-modelizer
  1. Run the e2e tests
npm run test:e2e

Development

Directory structure

This is the default directory structure we use for the project:

leto-modelizer
├ cypress              ⇨ Contains all the cypress related files
│ ├ e2e                ⇨ Contains all the e2e tests
│ ├ videos             ⇨ Contains all videos of each run test (only locally)
│ └ support            ⇨ Contains all support files for e2e tests
│   └ step_definitions ⇨ Contains all step definitions for e2e tests
├ dist                 ⇨ Contains the built application
├ docs                 ⇨ Contains all files generated by jsdoc
├ public               ⇨ Contains all public files, like favicon
├ reports              ⇨ Contains all the report files for sonar
├ src                  ⇨ Contains all files for the leto-modelizer application
│ ├ assets             ⇨ Contains all the assets
│ ├ boot               ⇨ Contains all boot configurations
│ ├ components         ⇨ Contains all vue components
│ ├ css                ⇨ Contains all style files
│ ├ i18n               ⇨ Contains translation engine and translation files
│ ├ layouts            ⇨ Contains all the page layouts
│ ├ pages              ⇨ Contains all the pages
│ ├ router             ⇨ Contains the router engine and the route definitions
│ └ stores             ⇨ Contains store engine and all storage definitions
└ tests                ⇨ Contains all files related to the tests

How to release

We use Semantic Versioning as guideline for the version management.

Steps to release:

  • Create a new branch labeled release/vX.Y.Z from the latest main.
  • Increase the version number in package.json, package-lock.json and changelog.md.
  • Verify the content of the changelog.md.
  • Commit the modifications with the label Release version X.Y.Z.
  • Create a pull request on github for this branch into main.
  • Once the pull request validated and merged, tag the main branch with vX.Y.Z.
  • After the tag is pushed, make the release on the tag in GitHub.

Git: Default branch

The default branch is main. Direct commit on it is forbidden. The only way to update the application is through pull request.

Release tag are only done on the main branch.

Git: Branch naming policy

[BRANCH_TYPE]/[BRANCH_NAME]

  • BRANCH_TYPE is a prefix to describe the purpose of the branch. Accepted prefixes are:
    • feature, used for feature development
    • bugfix, used for bug fix
    • improvement, used for refacto
    • library, used for updating library
    • prerelease, used for preparing the branch for the release
    • release, used for releasing project
    • hotfix, used for applying a hotfix on main
  • BRANCH_NAME is managed by this regex: [a-z0-9._-] (_ is used as space character).