Skip to content

Fix broken or outdated content in Contributing guidelines #3320

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from
Open

Fix broken or outdated content in Contributing guidelines #3320

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
084202b
Update CONTRIBUTING.md
marcthayer Mar 13, 2025
cb6f7a0
Update CONTRIBUTING.md
marcthayer Mar 13, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
146 changes: 73 additions & 73 deletions .github/CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand All @@ -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 <command-name>`.
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 <command-name>`.
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

Expand All @@ -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
Expand All @@ -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?**
Expand All @@ -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.

Expand All @@ -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.

Expand Down Expand Up @@ -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 `_`.
Expand All @@ -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 <script name>`.** This ensures that the execution point of the
scripts (`pwd`) is always the repository root.
Expand All @@ -294,8 +294,8 @@ scripts (`pwd`) is always the repository root.

> `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
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.

### Security

Expand All @@ -307,9 +307,9 @@ details, including but not limited to:
2. The operating system(s) to which the bug is relevant
3. Bug description

Please **refrain** from publicly posting about the security vulnerability in **any** form, until it's corresponding fix
has been released
Please **refrain** from publicly posting about the security vulnerability in **any** form until its corresponding fix
has been released.

---
*Sections of this document use excerpts from various books and the Internet, among whom, [this](http://git-scm.com/book)
*Sections of this document use excerpts from various books and the Internet, among which, [this](http://git-scm.com/book)
is a dominating influence.*