Templates /
GitHub Pull Request Procedure

GitHub Pull Request Procedure

This should be used for all PRs to reduce errors, ensure thorough testing, and start the review process.
1
Introduction:
2
Make sure you finished the issue
3
Make sure to thoroughly test the issue
4
Check usages of modified methods
5
Don't forget to test on mobile for anything visual that you change
6
Run all tests to make sure they're passing
7
Make sure the PR contains a new test
8
If BE: Make sure the PR removes 1 Scalastyle issue
9
Run code formatters if applicable
10
Create a PR in GitHub
11
Attach this checklist link as a comment in the JIRA issue
12
Move the issue from In Progress to In Review
13
Assign this task to reviewer
14
Give yourself a self five
15
Sources:
16
Related checklists:

Introduction:

To avoid errors and ensure you’re keeping your GitHub records useful and readable, you need to know the correct way to make a pull request. This checklist will make sure the issue is properly tested (for both functionality and user experience), and also guide you through the review process.

There are some optional steps in this checklist that are designed to help passively squash low-priority bugs. Feel free to remove step 8 if you’re not concerned with that, or if you want to make the process go faster. Since the PR process is run so often, it’s a great place to insert small steps like this and whittle down your bug backlog.

Make sure you finished the issue

Re-read the summary and description of the issue in JIRA and make sure that you finished it.

Make sure to thoroughly test the issue

Please do not take this step lightly.

This is very important. The majority of issues that fail review are because something was not tested carefully.

Make sure that the thing you have fixed is indeed fixed.

For example, if your issue was to track a field in Intercom, then make sure that the field is actually being sent to Intercom and shows up.

Check usages of modified methods

It’s possible that during code refactoring some methods were changed, we need to check their usages and make sure that logic is not broken.

  • 1

    Check usages of modified Service methods
  • 2

    Check usages of modified Repository methods

Don’t forget to test on mobile for anything visual that you change

Chrome developer console has a button where you can resize the screen to the mobile size. This is a way to see if anything is looking weird.

If it’s a visual change, make sure it’s working on all browsers too. You can check with https://caniuse.com/ or Mozilla reference guide

For visual changes:

  • 1

    Check Chrome
  • 2

    Check Internet Explorer
  • 3

    Check Safari
  • 4

    Check Firefox

Run all tests to make sure they’re passing

For the front-end, run grunt-test:

grunt test

Make sure the PR contains a new test

The test does not have to be big.

If BE: Make sure the PR removes 1 Scalastyle issue

We’re trying to get rid of all Scalastyle issues, so make sure you remove one issue when making a BE PR.

To see a list of all issues, type sbt scalastyle.

Run code formatters if applicable

If it’s a BE PR, then run this:

sbt fmt

If it fails, then so will CirlceCI. If it doesn’t seem to be formatting correctly you can go in to the offending file and use Command-Shift-L (or Ctrl-Shift-L if not on Mac) or do sbt clean and then start over from the top.

If it’s a FE PR, then run this: 

grunt lint

Fix any errors (if you don’t, CircleCI will squawk).This will run a javascript linter, and also a SCSS linter.

SCSS Guidelines:

  • Make sure there is a namespace for each new scss file:
    ex:
    .feature {
    .feature-component {

    }
    }
  • Make sure the class is saying what the element does vs. using another class because you already have it (Make it semantic).
  • CSS properties should be added in alphabetical order.
  • Avoid vendor prefixes, use bourbon mix-ins when needed instead. @includes go above the alphabetical ordering.
  • Colors should be written as lowercase HEX values. Ex: #fff vs. white or #FFFFFF
  • Avoid nesting selectors too deeply.
  • Use `//` comments everywhere

  • Leading Zeros: `0.8` should be written without a leading zero as `.8`

  • Avoid qualifying elements in selectors (also known as "tag-qualifying").
  • Prefer the shortest shorthand form possible for properties that support it.
    • Ex: margin: 1px; vs margin: 1px 1px 1px 1px;

You can read the entire lint list here:

https://github.com/brigade/scss-lint/tree/master/lib/scss_lint/linter

Create a PR in GitHub

Here is a link to generate a BE PR (doesn’t work for forks):
https://github.com/[account]/[repo]/compare/develop…{{checklist.name}}

Here is a link to generate a FE PR (doesn’t work for forks):
https://github.com/[account]/[repo]/compare/develop…{{checklist.name}}

[Edit the link above to include account/repo in place of placeholders]

Here are specific links for each developers fork:

[Add links to your developer’s forks here]

  • 1

    Make sure PR is against the develop branch (if it exists) otherwise the staging branch
  • 2

    Make sure that the PR is mergable without conflicts
  • 3

    The PR title must start with the case-sensitive issue #, e.g. PS-1337 or PUB-101
  • 4

    The PR title must have a short description like, e.g. "PS-1337 Fixes issue with sidebar display"

Move the issue from In Progress to In Review

Make sure to assign it to a reviewer who will understand the changes, and try to assign it to someone who has fewer reviews in their queue.

Assign this task to reviewer

Do not check this until the review has happened.

Contact your reviewer and coordinate a time to demonstrate your feature or bugfix.

If you have several things to review, try to do them all at once.

Please do not waste each other’s time by making sure that you’ve fixed and tested the issue carefully.

When you are reviewing, asking the developer what they did, why they did it, and how they did it.

Give yourself a self five

Self five! You’ve earned it.

Sources:

Take control of your workflows today.