recruitment-portal

Steps to run the repo:

  1. Clone the repo
  2. Run cd frontend to navigate to the project folder
  3. Run yarn install to install dependencies
  4. Create a .env file in the frontend folder and paste the environment variables messed to you as a one time secret
  5. Run yarn dev to start the dev server

Gitflow

Please do not push to main directly. BoG Component Library only accepts code that has been approved from a Pull Request. In order to make changes to the code, we recommend the following steps:

  1. Create a new branch from develop following the naming convention. (e.g. initials/brief_issue_description or sp/add_cool_feature)
  2. Create a pull request. (refer the section below on how to do this)
  3. Wait for approval from the EM and another developer.

NOTE: You can create a new branch in command line with git checkout -b myBranchName. To check what branch you are on, you can run git branch. If you don't see a branch, try git fetch origin.

Steps for creating a PR (Pull Request)

Typically PRs are only created once you're done with all your changes; however, Github allows you to create a draft PR before you've finalized your branch. This is super useful if you need the EM, designers, the PM, or a fellow dev to take a look at your changes before you proceed with your task.

  1. Navigate to the pull requests tab on Github.

Screen Shot 2022-01-23 at 2 19 02 AM

  1. Click on the New pull request button.

Screen Shot 2022-01-23 at 2 20 36 AM

  1. This will prompt you to choose a branch to merge into main, following this prompt, choose your branch that you've committed changes to.

image

  1. This will take you to a page with the summary of the changes you've made. If you want to take a look at your code before you assign reviewers then this is a good way to view all your changes consolidated.

Screen Shot 2022-01-23 at 2 24 01 AM

  1. Once you're done looking at your beautiful, elagant, and hyper-optimised (I'm sorry I ran outta adjectives) code, go ahead and click on the Create pull request button. This should take you to a screen with a standard PR template.

image

  1. Navigate to Zenhub then click on the ticket you're working on, then click to view the issue on Github and copy the issue's url from your browser. Replace the <!-- Link to Github issue this PR closes --> comment on the template with this link.

Screen Shot 2022-01-23 at 2 26 41 AM

  1. Briefly explain the changes you've made in your branch (please simplify this explanation as much as possible) and replace the <!-- What does this PR change and why? --> comment with your explaination.
  2. Get rid of the <!-- Choose one --> comment and the 3 other options of the type of change that your branch, once merged, is going to make to the main code. Use your best judgement to choose the type of change, and if you cannot choose one, then feel free to slack the EM to get a second opinion.
  3. Once you've chosen the type of change, now would be a great time to change the default title of the PR. Format the title of the PR according to the following format: <Type of change>(<1-2 word discription of change>): <Title of issue>. An example of this would be something like feature(Alert): Alert Component.

Screen Shot 2022-01-23 at 2 30 04 AM

  1. Copy the acceptance criteria from your ticket onto the issue and mark each checkbox if completed. Make sure that you meet all the acceptance criteria before merging the PR. A quick way to do this is to click "Edit" on the issue and copy the markup code for the acceptance criteria (on the issue) on to the PR.

  1. Finally assign the EM as a reviewer.

  2. Finally, you're all done! (YAY!) Now all you gotta to is wait...

Merging a PR

  1. Once you've opened a PR, wait until the EM and atleast one designer has approved your changes.
  2. If one (or more) of your reviewers request changes, then please do so.
  3. Once you're fully approved, go ahead and merge your changes! (your EM is automatically pinged so you may or may not choose to Slack them regarding your status)
  4. Hooray! You're code is now (hopefully forever) a part of the project! You may not see your changes deployed right away; typically we try to deploy twice during the semster.