rsi.cli
Version:
The swiss army knife for RSI related tasks.
112 lines (81 loc) • 3.47 kB
Markdown
# Repsoitory structure
Service repositories consist at least of a package.json, a README.md and the CHANGELOG.md.
Assuming <servicename> is the desired service name, the folder structure would be similar to the following example:
```bash
rsi.service.<servicename>/
├── doc/
│ └── ...
├── test/
│ ├── custom.spec.ts
│ └── ...
├── src/
│ └── ...
├──package.json
├── README.md
└── CHANGELOG.md
```
## doc/
The [Doc](./doc) contains service usage specifications - e.g. userstories. The folder MUST only hold `*.md`, `*.pdf` for text and `*.png`, `*.jpg`, `*.bmp`, `*.svg` and `*.puml` files in any subfolder.
## test/
This folder is optional and might contain custom tests the service. Only test which can to be autogenerated from `src/schema.json` go here.
## src/
The `src/` folder contains the the `schema.json` file, which defines the service itself.
# Contribution
In order to streamline contribution to RSI servcie definitions, some guidelines are described below.
## Git Commit Guidelines
These rules are adopted from [the AngularJS commit conventions](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/).
### Commit Message Format
Each commit message starts with a **type**, a **scope**, and a **subject**.
Below that, the commit message has a **body**.
- **type**: what type of change this commit contains.
- **scope**: what item of code this commit is changing.
- **subject**: a short description of the changes.
- **body** (optional): a more in-depth description of the changes
```
<type>(<scope>): <subject>
<BLANK LINE>
<body>
```
Examples:
```
feat(ruler): add inches as well as centimeters
```
```
fix(protractor): fix 90 degrees counting as 91 degrees
```
```
refactor(pencil): use graphite instead of lead
Closes #640.
Graphite is a much more available resource than lead, so we use it to lower the price.
```
```
fix(pen): use blue ink instead of red ink
BREAKING CHANGE: Pen now uses blue ink instead of red.
To migrate, change your code from the following:
`pen.draw('blue')`
To:
`pen.draw('red')`
```
Any line of the commit message should not be longer 100 characters. This allows the message to be easier
to read on github as well as in various git tools.
### Type
Is recommended to be one of the below items. Only **feat** and **fix** show up in the changelog, in addition to breaking changes (see breaking changes section at bottom).
* **feat**: A new feature
* **fix**: A bug fix
* **docs**: Documentation only changes
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
semi-colons, etc)
* **refactor**: A code change that neither fixes a bug or adds a feature
* **test**: Adding missing tests
* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
generation
### Scope
The scope could be anything specifying place of the commit change. Usually, the affected resource is named here.
### Subject
The subject contains succinct description of the change:
* use the imperative, present tense: "change" not "changed" nor "changes"
* don't capitalize first letter
* no dot (.) at the end
### Breaking Changes
Put any breaking changes with migration instructions in the commit body.
If there is a breaking change, put **BREAKING CHANGE:** in your commit body, and it will show up in the changelog.