Contributing to Build Tracker
Thank you for your interest in helping out with Build Tracker! This is a project done with joy and care, out of our free time. Before getting started, please familiarize yourself with the Contributor Covenant Code of Conduct.
Getting started
Fork and pull the repository from Github. If you're unsure how to fork a repository, read the getting started docs here.
Install dependencies
Build Tracker is a monorepo managed by Yarn. Start by installing dependencies for all packages:
Make your changes
Always work on features in a separate branch from the main master branch.
Now that you're on a branch, make changes directly to the code related to your feature or bug fix.
Ensure to always add tests, preferrably before you start making changes. This helps both you and any future reviewer verify that the code's intentions work correctly.
Run tests using the main script from the root of the repository:
Once you've completed your changes and all of your tests pass, commit and push your branch to your fork:
Open a pull request
Finally, open a pull request on the main Build Tracker repository.
Monorepo
The Build Tracker git repository is a monorepo that is composed of many publishable packages. This has been done so that it's easier to iterate on cross-functional dependencies without requiring premature publishing steps.
The tool for managing these packages is Lerna with Yarn workspaces.
Package workspace structure
./src
Source All core Build Tracker packages reside here.
All folder names should be mapped as the publishable name without the @build-tracker
scope. For example: @build-tracker/app
is in the path src/app
, while @build-tracker/server
is at src/server
.
./plugins
Plugins All implementation-specific code for various integrations should be kept here, instead of in the src
directory.
All folder names should be mapped as the publishable name without the @build-tracker/plugin-
scope. For example: @build-tracker/plugin-with-mariadb
is in the path plugins/with-mariadb
.
Some local configs are available for development purposes. To use them, it's recommended to use a Docker container, since it's easy to seed and throw away:
MariaDB
MySQL
Postgres
./docs
Docs This directory holds packages related to the documentation website
Development
Here are some things to keep in mind while working in a monorepo:
Adding a dependency to a package
To add a third-party dependency to a sub-package in the Build Tracker repository, ensure that it's done from the specific sub-package using the yarn workspace
command:
Don't abstract too early
Repeating code is not inherently bad. If some logic clearly fits in one of the already published packages, that's probably the right place for it. If there isn't a package available for something that is reusable, use your best judgement about complexity and scope of functions to determine if a new package is warranted.
Typescript
Build Tracker is written in Typescript throughout all workspaces. Please do not add code that is not written in Typescript or change to another language.
Dev environment
To run the development environment, first, run yarn build
to prebuild some static sources. Once that is done you can run one of the pre-configured test/dev environments:
yarn dev
Run the server and application in a hot-reloadable environment using pre-seeded builds on the filesystemyarn dev:large
This is the same asyarn:dev
, but with a larger dataset. More builds and many more artifacts in each.yarn dev:maria
Run the server using a local MariaDB instance (see plugins for more requirements)yarn dev:postgres
Run the server using a local Postgres instance (see plugins for more requirements)
Code integrity
The following conformance checks can be run manually and will be automatically run on pre-commit
as well as during the pull-request verification flow via Github Actions.
yarn lint
Lint and auto-format codeyarn test
Jest testsyarn tsc
Typescript type check
Documentation
Documentation is a great place to get started contributing to the Build Tracker project because writing good docs is difficult. For that reason, your help is always appreciated.
Running the docs locally
To run the documentation with hot reloading from your local machine, simple run:
Your browser should automatically be opened to the documentation site running locally. If it is not, you can visit http://localhost:3000
(or swap the port 3000
with whatever is on the last line of the output above)
Updating documentation
To update any documentation pages, open the appropriate Markdown files in ./docs/docs
. Make any changes you’d like.
Updating other pages
All pages and templates are written with React.js and can be found in src/pages
.
Submitting your PR
After your changes look the way you want on your local documentation server. You can close the server down (CTRL+C
). Commit your changes to a local feature branch, push them to your fork on GitHub, and open a PR on the Build Tracker repository.
Other help
Build Tracker uses Docusaurus for generating it's docs. If you're unfamiliar with any of the internals of how the docs are built, structured, or how to add a feature to them, the official docs are the best place to start.
Publishing
yarn build
- Build all packagesyarn lerna publish
- Lerna will request a new version and publish only the changed packages