Skip to content

Latest commit

 

History

History
87 lines (61 loc) · 4.06 KB

CONTRIBUTION.md

File metadata and controls

87 lines (61 loc) · 4.06 KB

DIP Platform Contribution Guide

Micro-service requirements

  • All instances need to be able to run in a standardized dev, production and test modes.
  • All external dependencies ( such as DB connections, MQ broker addresses, and so on) need to be configured through optional environment variables.

MQ messages format and processing

Each microservice should include a shared message registry reference.

The following attributes are universally passed along with the payload of the message:

  • correlationId - an UUIDv4 identifier for the message chain. It should be either generated in the sender, or if the message is a response for the other one - passed along with the results.
  • Header data. Needs to have originatorName and originatorVersion specified for book-keeping, but potentially allows for other free-form fields (unlike the parameters root)

Using shared libraries between microservices

  • Lerna in an independent mode is used to manage independently versioned packages
  • Because we use a monorep setup with microservices which are each bundled into a Docker image, we had to employ Lerna during docker build as well - dockerfiles for individual microservices are stored in the repo root so building them as access to both microservices and shared files.

GIT: commits, branches and pull requests

  • The commit message should ideally follow the following template:

    [GENIT-#] a brief description of the changes ( a list of names for affected microservices )

  • If the commits for one Task-tracker issue are following one another - they should ideally be squashed into one before being merged into master

Documentation

  • Esdoc is used to generate documentation
  • Javascript files should be documented with JSDoc syntax JSDdoc
  • Use npm run docs to generate docs

Testing

npm run test:e2e run end-to-end tests

npm run test run tests for packages

npm run coverage run tests coverage for packages

npm run collect:coverage collect tests coverage from packages in README.md

Contributing

Please refer to each project's style and contribution guidelines for submitting patches and additions. In general, we follow the "fork-and-pull" Git workflow.

  1. Fork the repo on GitHub
  2. Clone the project to your own machine
  3. Commit changes to your own branch
  4. Push your work back up to your fork
  5. Submit a Pull request so that we can review your changes

NOTE: Be sure to merge the latest from "upstream" before making a pull request!

Copyright and Licensing

Etheriscs open source projects are licensed under the Apache 2.0 license.

Etherisc does not require you to assign the copyright of your contributions, you retain the copyright. Etherisc does require that you make your contributions available under the Apache 2.0 license in order for it be included in the main repo.

If appropriate, include the Apache 2.0 license summary at the top of each file along with the copyright info. We recommend to use the SPX License-identifier at the top which will silence compiler and lint warnings: // SPDX-License-Identifier: Apache-2.0 If you are adding a new file that you wrote, include your name in the copyright notice in the license summary at the top of the file.

Apache 2.0 License Summary

You can copy and paste the Apache 2.0 license summary from below.

Copyright 2017-2018 by Etherisc

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Notes

Markdown syntax examples