-
Notifications
You must be signed in to change notification settings - Fork 5
Development
- Homebrew
brew install nodenv # and set up your environment
nodenv install 13.8.0
brew install yarn
yarn
make test_unit
- Auto-formatters and Linters
- Documentation Generation
- Install Homebrew
- Homebrew installation documentation
- Command(s)
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
- Update Homebrew
- Command(s)
brew update
- Command(s)
- Install node
- Command(s)
brew install node
- Command(s)
- Install yarn
- Yarn installation documentation
- Command(s)
brew install yarn
- Install Docker
- Docker for Mac installation documentation
- Command(s)
- See 'Docker for Mac installation documentation'
- Install JavaScript dependencies
- Command(s)
- From the root of the repository
yarn
- Command(s)
We have a set of conventions on how git commit messages should be formatted. Specifically, we've decided to follow conventional commits to make project commit history more readable and generate changelog automatically.
The commit message formatting can be enforced by using a CLI wizard (Commitizen). After staging your changes, run yarn run commit and follow the prompt to finish formatting your commit messages.
Each commit message should follow the format described below:
<type>(<scope>): <subject>
<blank_line>
<body>
<blank_line>
<footer>
Type must be one of the following:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code
- refactor: A code change that neither fixes a bug nor adds a feature
- release: An aggregation of code changes to be used for a release
- perf: A code change that improves performance
- test: A code change that adds, updates or fixes tests
- ci: A code change in CI pipeline
- revert: Revert to a commit
Scopes are broken down at service level and must be one of the following:
- action
- auth
- catalog
- core
- examples
- identity
- ingest
- kvstore
- search
- streams
Note: scope is optional, use * if your changes do not apply to any of the scopes above. * can also be used when your changes affect more than one scope.
The subject is a short description of the change:
- Start the sentence with present tense: "Add", not "added" nor "adds"
- Don't capitalize first letter
- Don't put any references to JIRA tickets, Github issue number in subject
Same rule as subject. The body should contain more detailed descriptions of the code changes.
Before submit your pull request, please follow these guidelines:
- Create a new git branch
git checkout -b my-branch develop
- Make code changes in your branch with tests following code style and convention
- Check if you have any lint error
yarn run tslint
- Commit your changes using conventional commit. Adherence to the commit conventions is required since release notes are automatically generated from these commits.
yarn commit
- Push your branch to Github
git push origin my-branch
- In Github UI, create a pull request targeting develop branch. This will trigger CI to run automatically.
- After pull request is merged, delete your branch by clicking the button from the UI.
- Pull changes from develop branch
git checkout develop
git pull develop