Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
128 lines (88 loc) · 5.63 KB

CONTRIBUTING.md

File metadata and controls

128 lines (88 loc) · 5.63 KB
Raw

Contributing to the Linode manager

Contributing to the Cloud Manager just involves sending a Pull Request.

The following buzzwords are involved in this project:

Development

Coding Style

The manager is written in ES6, with some ES7 in use as well. A general guideline for the coding style is "imitate the code that's already there". When in doubt, apply the Airbnb style guide or just let the linter do its thing.

If you're interested in learning how we write code and want to follow our guidelines, please see our code style documentation.

Testing

This project uses Jest for unit testing, snapshot testing, assertions, and mocking.

End-to-end tests are written using WebdriverIO.

For everything related to writing and running tests, please see the documentation here.

Git workflows

Creating and Committing to a New Branch

When creating a new feature, you should attempt to create a descriptive branch name. All branch names must be prefixed with M3, which stands for Manager 3, as this is the third iteration of this product.

For example M3-my-cool-feature

Once you have made all your changes, you can commit them.

We use Husky to perform the following tasks before the commit succeeds:

  1. Linting
  2. Unit testing
  3. Storybook end-to-end component testing
  4. Circular dependency check
  5. Type Checking (as we're using TypeScript in the src code)

If any fail the commit will be aborted. Address the reported issues, stage the changes, and attempt the commit again. This behavior can be skipped using the --no-verify flag, but we highly suggest you do not use this flag.

Merge Conflicts

Merge conflicts happen, and when they do, we recommend rebasing.

git rebase -i develop will allow you to interactively pick which commits you want to keep and then you can address the conflicts as they appear.

If you absolutely must merge the two branches, that is fine as we will squash all commits once the PR is merged, so we aren't that stressed about merge commits.

Deploying

We are following a CI/CD (continuous integration / continuous deployment) process for Cloud Manager. This means:

  1. develop branch gets automatically deployed to our development environment
  2. testing branch gets automatically deployed to our testing environment
  3. staging branch gets automatically deployed to our staging environment
  4. master branch gets automatically deployed to our production environment, AKA https://cloud.linode.com

This means we can deploy features quickly and efficiently.

When a new version of Cloud Manager is released, it must be accompanied by an update to CHANGELOG.md. See Keepachangelog for formatting details

What to Do When Releasing

Once your code from the develop branch has been merged into testing and you intend on pushing this code live:

  1. Pull down the latest testing branch locally
  2. Run yarn version --new-version vX.X.X (replace the X's with the appropriate version number)
    • this will apply the Git tags and update the version number in the package.json
  3. Generate the Changelog
  4. Review the Changelog and update manually if necessary
  5. Stage and commit the version bump and changelog addition with the commit message, which should be as simple as: vX.X.X
  6. Push up the changes to the testing branch with git push origin testing
  7. Finally, follow the merge flow. Merge from testing to staging and finally to master

Generating the changelog

Get a Python 3 installation with pip. On a Mac:

brew install python (Python 3 is now the default)

The Changelog is generated by the script generate_changelog.py. This script should ideally only be run on the testing branch

The script accepts 3 parameters:

  1. ${release version}
    • vX.X.X for example
  2. ${release-date yyyy.MM.dd}
    • 2019-09-17 for example
  3. ${mangerRemote}
    • origin for example

So altogether, the command should look like:

python generate_changelog.py v0.52.0 2019-09-17 origin

This script does a git log diff of manager/master...HEAD, printing only the commit subject. Strip any reference to a JIRA ticket, and disregards any testing or automation ticket, and updates the CHANGELOG.md Added, Breaking, Fixed, Change based on keywords in the commit subject.

Other Things

Reporting Bugs

First, remember that this is a work in progress. Please don't report bugs for features that aren't present, links that lead to 404's, buttons that don't appear to do anything - these are all likely in-progress or not started features. Instead, report bugs for regressions or problems with things that are already implemented. Please search GitHub issues to see if there's already a bug filed for your problem - if so, leave a comment mentioning that you can reproduce it. Otherwise, go ahead and open an issue with as much detail as you can provide (for example: node version, operating system, browser, device, etc.). Thanks!

References