0xhacking / inventory-check

Inventory check Contribution Guide

About

Take a moment to familiarize yourself with the following rules, guidelines, and contribution process.

Learn more about project specifics:

• npm scripts
• setup
• structure
• technologies
• webpack

Post any questions to the 'Atlas UI Dev Team' Spark room. Contributors are expected to be actively engaged on Spark. If you need more help or access to a Spark room, please reach out to a core team member.

Rules and Guidelines

These rules establish and enforce best practices in order to improve code quality, maintainability, and readability. All contributors are expected to take the time to learn and apply them. Adherence is mandatory. Please refactor non-compliant code.

• Unit tests are mandatory. Unit tests are the foundation of our testing strategy. They provide a way to test business logic and components in isolation while controlling all conditions and expectations. See the examples module for examples of different types of unit tests.
• Code reviews are mandatory. Code reviews are performend through GitHub's Pull Requests. GitHub provides an easy-to-use tool for reviewing and maintaining commit history by linking commits with their associated pull requests.
• Code style is mandatory. Style should be enforced through linting and code reviews.
  • Javascript Style Guide
  • Angular Style Guide
  • Angular's Git Commit Guidelines
• Build failure triage is mandatory. When you push code that breaks the builds, you are responsible to investigate and triage this failure before attempting another push. More info on the triage wiki.

Contributing

First Time Contributors

Your first PR is an important one, and to help you acclimate to our coding style and patterns it is best to keep it simple. If you are new to the codebase, we ask that you keep your first PR under 500 lines max.

This helps your reviewers help you. The smaller you keep your PR, the sooner your reviewers can offer feedback, allowing you to learn best practices and respond with updates quicker. Remember that your first PR will very likely require multiple rounds of feedback and updates, so keep it small and lean to help this process flow quicker.

Workflow

1. Setup your repository

• git clone https://github.com/stonedpebbles/inventory-check.git
• origin should be the above WebExSquared repo (git remote -v to see remote details)

2. Run the application

• npm install to install project dependencies
• npm start to run the development server
• See npm scripts for more build commands

3. Make your feature change or bug fix

• Create a local branch (tracking origin/master) to implement your work
  • git checkout -b <local-branch> origin/master
• Example Hello World module
• Example components
  • index.ts
  • example.component.ts
  • example.html
  • example.service.ts

4. Create your unit tests

• npm test or npm run test to run unit tests
• Example components - npm run ktest-watch -- examples/unit/*.spec.ts
  • example.component.spec.ts
  • example.service.spec.ts

5. Analyze code coverage

• Generated by every unit test karma run
• View your own report in the test/coverage directory
• Jenkins also publishes Coverage Report for every build

6. Create End-to-End test

• npm run protractor to run protractor e2e tests
• e2e tests are organized by modules
  • Only add e2e tests for critical, happy-path workflows
• Protractor elements are abstracted into Page Objects
• All element interactions are implemented through Util functions

7. Create Pull Request code review

• git checkout <local-branch> (if not already on your local branch)
• Before creating a pull request, update your local branch (tracking origin/master) to the latest remote code
• git pull --rebase
• Push your updated local branch to your fork
• git push <fork> <local-branch>
• On your fork, select your branch and click Pull request to create a new PR
• Add appropriate reviewers using @mention
  • Add @WebExSquared/atlas-web-jedi for core team members if needed
• Respond to feedback and push new commits if necessary

8. Push to Gauntlet (build queue-ing tool) for validated merge (after approved review)

• git remote add gauntlet https://gauntlet.wbx2.com/api/git/atlas-web
• git checkout master
• Your master branch should have no local commits. Reset your HEAD if need be.
• git pull --rebase to update your master branch with the latest from github
• git merge <local-branch> (resolve conflicts if necessary)
• git push gauntlet master
  • Use your CEC username and internal password.
  • Consider putting your internal password into ~/.netrc
  • You can monitor the gauntlet queue here

9. Jenkins Build Triage

• Build failures happen - sometimes they are related to your work and sometimes they aren't
• All contributors are required to triage their failure to a root cause
• A GitHub Issue (GHI) will be created with failure details and you will be notified on Spark how to triage
• Atlas Triage Wiki