diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 4c2dceafd..a85b991f5 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -4,10 +4,12 @@ - [NPM Command Reference](#npm-command-reference) - [`npm install`](#npm-install) - [`npm test`](#npm-test) - - [`npm run test-system`](#npm-run-test-system) - - [`npm run test-lint`](#npm-run-test-lint) - - [`npm run test-unit`](#npm-run-test-unit) - - [`npm run test-integration`](#npm-run-test-integration) + - [`npm run test-system`](#npm-test) + - [`npm run test-lint`](#npm-test) + - [`npm run test-unit`](#npm-test) + - [`npm run test-integration`](#npm-test) + - [`npm run test-cli`](#npm-test) + - [`npm run test-library`](#npm-test) - [Repository](#repository) - [Structure](#structure) - [Branching and Tagging Policy](#branching-and-tagging-policy) @@ -21,42 +23,41 @@ - [Documentation guidelines](#documentation-guidelines) - [The CI Platform](#the-ci-platform) - [Ensuring your commits will not fail build](#ensuring-your-commits-will-not-fail-build) - - [Accessing build log on CI server](#accessing-build-log-on-ci-server) - [Security](#security) ## Getting Started Quick In order to contribute to this project, you should: -1. Clone this repository / your fork of this repository using `git` -2. If not on `develop`, switch to the `develop` branch with `git checkout develop` -3. Run `npm install` in the project directory +1. Clone this repository / your fork of this repository using `git`. +2. If not on `develop`, switch to the `develop` branch with `git checkout develop`. +3. Run `npm install` in the project directory. 4. Make sure everything is working by running `npm test`. 5. Create a new feature branch from `develop` with `feature/your-feature-name`. -6. Make the necessary changes in line with the objective(s) of the pull request -7. You can debug newman locally by running `node ./bin/newman `. -8. Ensure that you have added unit and integration tests for any new features added / bugs fixed -9. Run `npm test`. If any tests fail, resolve the issue with the code, and re-try -10. Once the tests pass, commit and push. **Do not** alter the `version` in `package.json` -11. Create a pull request to `develop` +6. Make the necessary changes in line with the objective(s) of the pull request. +7. You can debug Newman locally by running `node ./bin/newman `. +8. Ensure that you have included unit and integration tests for any new features added / bugs fixed. +9. Run `npm test`. If any tests fail, resolve the issue with the code and retry. +10. Once the tests pass, commit and push. **Do not** alter the `version` in `package.json`. +11. Create a pull request to `develop`. ## NPM Command Reference ### `npm install` -Installs all `dependencies` listed in `package.json` +Installs all `dependencies` listed in `package.json`. ### `npm test` -The script associated with `npm test` will run all tests that ensures that your commit does not break anything in the -repository. As such run `npm test` before you push. In addition to performing a few logging and pre-test configuration -actions, this test bootstrap script will also trigger the various sub test tasks, which include code lint checks, unit -and integration tests. At present, the following sub tests can be run on a standalone basis: +The script associated with `npm test` will run all tests. That ensures that your commit does not break anything in the +repository. As such, run `npm test` before you push. In addition to performing a few logging and pre-test configuration +actions, this test bootstrap script will also trigger the various sub-test tasks, which include code lint checks, unit +tests, and integration tests. At present, the following sub-tests can be run on a standalone basis: * `npm run test-system`: Runs system tests * `npm run test-lint`: Performs code style checks, flagging inconsistencies and other miscellaneous anomalies * `npm run test-unit`: Runs unit tests to verify the correctness of various methods used within the project -* `npm run test-integration`: Checks Newman sanity with a sample requests categorized by collection +* `npm run test-integration`: Checks Newman sanity with sample requests categorized by collection * `npm run test-cli`: Runs CLI integration tests * `npm run test-library`: Runs library integration tests @@ -68,56 +69,56 @@ Directory | Summary ------------------------|----------------------------------------------------------------------------------------------- `bin` | Contains scripts that wrap around all the other methods provided within the project `examples` | A sample script to demonstrate collection file parsing within Newman -`lib` | Houses the core logic and configuration sets for Newman, including reporters, and the runtime +`lib` | Houses the core logic and configuration sets for Newman, including reporters and the runtime `npm` | All CI scripts (triggered by NPM run-script) `test` | Contains all the test scripts for Newman -`test/unit` | Method wise tests for Newman -`test/system` | Erstwhile `infra` tests, checks for proper code structuring and division across the project -`test/integration` | Contains the integration test runner, validates Newman as a library +`test/unit` | Method-wise tests for Newman +`test/system` | Formerly `infra` tests, checks for proper code structuring and division across the project +`test/integration` | Contains the integration test runner and validates Newman as a library ### Branching and Tagging Policy -This repository uses standard `git-flow` branch management policy/strategy. If you want to learn more on `git-flow`, -refer to [tutorial from Atlassian](https://www.atlassian.com/git/workflows#!workflow-gitflow) and more details at -[http://nvie.com/posts/a-successful-git-branching-model/](http://nvie.com/posts/a-successful-git-branching-model). +This repository uses a standard `git-flow` branch management policy/strategy. If you want to learn more about `git-flow`, +refer to this [tutorial from Atlassian](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow). +More details can be found at [http://nvie.com/posts/a-successful-git-branching-model/](http://nvie.com/posts/a-successful-git-branching-model). -> Deletion of `main` and `develop`. -> Rebasing on `main` is blocked. +> Deletion of `main` and `develop` and rebasing on `main` is blocked. ## Preferred IDE + It is advised to use an IDE that provides [EditorConfig](http://editorconfig.org) support via `.editorconfig` files, -either natively, or through plugins. In addition, the `.gitignore` file has been populated with entries to support +either natively or through plugins. In addition, the `.gitignore` file has been populated with entries to support ignoring metadata / manifest files for various IDEs. ## Commit Guidelines -The following best practices, coupled with a pinch of common-sense will keep the repository clean and usable in future. -The idea is that everything that goes into the repository is not for an individual, but someone else who will be +The following best practices, coupled with a pinch of common sense will keep the repository clean and usable in the future. +The idea is that everything that goes into the repository is not for an individual but someone else who will be directly or indirectly affected by it. ### Check for errors before committing -Checking for errors should be done for each commit whether it is being pushed to remote or not. +Checking for errors should be done for each commit, whether it is being pushed to remote or not. First, you don't want to submit any whitespace errors. Git provides an easy way to check for this before you commit, run `git diff --check`, which identifies possible whitespace errors and lists them for you. If you run that command before committing, you can tell if you're about to commit whitespace issues that may annoy other developers. Secondly, you should ensure that your commit does not break builds. Run `npm test` on the repository to execute all -sanity and smoke tests. If any test fail, do not change the test to pass your commit. The tests were there with a +sanity and smoke tests. If any test fails, do not change the test to pass your commit. The tests are there with a purpose. Discuss within your team to ensure that the changes that you do to test specs are valid. If you are adding a -new feature, accompanying them with new tests are a good practice. +new feature, accompanying them with new tests is a good practice. ### Atomic commits -Try to make each commit a logically separate change set. If you can, try to make your changes digestible don't code +Try to make each commit a logically separate change set. If you can, try to make your changes digestible. Don't code for a whole weekend on five different issues and then submit them all as one massive commit on Monday. Even if you don't commit during the weekend, use the staging area on Monday to split your work into at least one commit per issue, with a useful message per commit. If some of the changes modify the same file, try to use `git add --patch` to partially stage files. The project snapshot at the tip of the branch is identical whether you do one commit or five, as long as all the -changes are added at some point, so try to make things easier on your fellow developers when they have to review your +changes are added at some point. So try to make things easier on your fellow developers when they have to review your changes. This approach also makes it easier to pull out or revert one of the change sets if you need to later. There are -a number of useful Git tricks for rewriting history and interactively staging files use these tools to help craft a +a number of useful Git tricks for rewriting history and interactively staging files. Use these tools to help craft a clean and understandable history. ### Clean commit message @@ -133,7 +134,6 @@ It's also a good idea to use the imperative present tense in these messages. In "I added tests for" or "Adding tests for," use "Add tests for." You should see if your commit message answers the following questions: -Answer the following questions: 1. **Why is this change necessary?** 2. **How does it address the issue?** @@ -154,8 +154,8 @@ A good commit message template ``` Short (50 chars or less) summary of changes with relevant project management issue ID. -More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line -is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from +More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line +is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. @@ -171,7 +171,7 @@ Run `git log --no-merges` to see what a nicely formatted project-commit history ### Writing tests -Over the course of contributing to Newman, several new features will be added and discovered bugs / glitches will be +Over the course of contributing to Newman, several new features will be added, and discovered bugs / glitches will be fixed. It is important to ensure that all of these changes are cross-checked via their respective tests. Two important points in this context are `unit` and `integration` tests. @@ -209,18 +209,18 @@ For instance: }); ``` -The result sentence derived by combining the descriptions in the `describe` and `it` blocks are: +The resulting sentences derived by combining the descriptions in the `describe` and `it` blocks are: **Logic tests** should throw an error if parameters are missing **Logic tests** should pass when valid values are provided #### Integration tests -Integration tests test Newman from the outside, and as a whole. As you might have already guessed, these tests don't -test one method at a time. With regard to Newman, each integration test consists of a postman collection, and optional -set of environment, data, and globals files. +Integration tests test Newman from the outside and as a whole. As you might have already guessed, these tests don't +test one method at a time. With regard to Newman, each integration test consists of a Postman collection and an optional +set of environment, data, and global files. -All these files are arranged without any directory segregation, as can be seen in [test/integration](https://github.com/postmanlabs/newman/tree/feature/v3/test/integration). +All these files are arranged without any directory segregation, as can be seen in [test/integration](https://github.com/postmanlabs/newman/tree/main/test/integration). Each of these file names should follow the convention outlined below: * File names with multiple words must have `-` as a separator, not `_`. @@ -245,47 +245,47 @@ file-name.postman_data.csv ## Guidelines for sending a Pull Request -Commit to `main` branch and `develop` branch is locked. As such, `git-flow` for feature completion and release will not -work. Thus, the last steps of feature completion in `git-flow` will happen as a Pull Request from website. Avoid -changing the `version` field in `package.json` for feature pull requests, as `version` bumps are handled separately. +Commit to the `main` branch and `develop` branch is locked. As such, `git-flow` for feature completion and release will not +work. Thus, the last steps of feature completion in `git-flow` will happen as a Pull Request. Avoid changing the `version` +field in `package.json` for feature pull requests, as `version` bumps are handled separately. -1. Pull Request comment and commit comments should explicitly discuss what changes were made. The Pull Request reviewer - should not need to communicate out of scope of issue tracker and the pull request description in order to understand - what changes has been done. +1. Pull Request comments and commit comments should explicitly discuss what changes were made. The Pull Request reviewer + should not need to communicate out of scope issues or have to clarify the pull request description in order to understand + what changes have been done. 2. Pull Requests with build failures will not be merged. Ensure that `npm test` passes on the `head` of your feature branch. The same goes for pull requests with untested new features / resolved bugs. -3. Ensure that your feature branch has been tested and if it is associated with issues from corresponding issue-tracker, - the issue must be in a "resolved" state, implying that the issue has been fully tested, and accepted for inclusion. +3. Ensure that your feature branch has been tested and is associated with issues from the corresponding issue tracker. + The issue must be in a "resolved" state, implying that the issue has been fully tested and accepted for inclusion. -4. Pull Requests with merge conflict are very difficult to review, and are at a higher likelihood of being rejected. +4. Pull Requests with merge conflicts are very difficult to review and are at a higher likelihood of being rejected. Ensure that the `head` of your feature branch is either already merged with `develop` or has no conflict when it is merged with `develop`. -5. The turn around time to close a Pull Request is directly proportional to the delta of changes done - more the change - in files, more time it would take. As such, if you anticipate a feature branch to have a large delta on feature - completion, break it into sub-issues of the issue-tracker, test them, close them, and then send PR for that branch. +5. The turnaround time to close a Pull Request is directly proportional to the delta of changes done - more changes + in files, more time it takes to review. As such, if you anticipate a feature branch having a large delta on feature + completion, break it into sub-issues in the issue tracker, test them, close them, and then send a PR for that branch. -6. In addition, the turn around time for Pull Request would get affected if commit messages are unclear. +6. In addition, the turnaround time for a Pull Request is affected by unclear commit messages. -7. If you have deadlines to ensure feature completion, send Pull Request ahead of time. Better still, ensure that your - feature development time window accounts for PR acceptance time as well. +7. If you have deadlines to ensure feature completion, sendthe Pull Request ahead of time. Better still, ensure that your + feature development time window accounts for the PR acceptance time as well. -8. If you have mentioned issue tracker references in Pull Request description, the severity and priority of those issues - will be taken into account. Otherwise, no Pull Request will take priority over others already in queue - it is - first-pull first-merge! +8. If you have mentioned issue tracker references in the Pull Request description, the severity and priority of those issues + will be taken into account. Otherwise, no Pull Request will take priority over others already in the queue - it is + first-pull, first-merge! ## Documentation guidelines Details on usage, sample use cases, licensing and current project status, and community support are to be specified -within `README.md`. All information related to contribution is to be added to `CONTRIBUTING.md`. More in depth -information on aspects like project architecture, design, and so on is to be added to the project [wiki](https://github.com/postmanlabs/newman/wiki) +within `README.md`. All information related to contribution is to be added to `CONTRIBUTING.md`. More in-depth +information on aspects like project architecture, design, and so on is to be added to the project [wiki](https://github.com/postmanlabs/newman/wiki). ## The CI Platform The CI system is built as a bunch of bash scripts to execute a set of tasks. These scripts are meant to execute tasks -that can run on every local machine. In general, knowledge about these scripts are not necessary for development +that can run on every local machine. In general, knowledge about these scripts is not necessary for development. **The scripts are to be only accessed using `npm run