Skip to content

Commit 656a9d7

Browse files
shamasisshamasis
committed
Initial commit with code migrated from proof-of-concept stage
1 parent ba1cacc commit 656a9d7

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

79 files changed

+6430
-1
lines changed

‎CONTRIBUTING.md

+186
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,186 @@
1+
# Contributing to Postman Collection SDK
2+
3+
## Command Reference
4+
5+
### `npm install -d`
6+
7+
### `npm test`
8+
9+
### `npm test-lint`
10+
11+
### `npm test-infra`
12+
13+
## Repository
14+
15+
### Structure
16+
17+
Directory | Summary
18+
----------------|---------------------------------------------
19+
`scripts` | All CI scripts (triggered by NPM run-script)
20+
`lib` | Library source modules, tests and doc source
21+
`tests` | All repository and lib test specifications
22+
`bin` | Command line scripts
23+
`examples` | Sample artefacts, fixtures and scripts
24+
25+
~~ to be documented further ~~
26+
27+
### Branching and Tagging Policy
28+
29+
This repository uses standard `git-flow` branch management policy/strategy. If you want to learn more on `git-flow`,
30+
refer to [tutorial from Atlassian](https://www.atlassian.com/git/workflows#!workflow-gitflow) and more details at
31+
[http://nvie.com/posts/a-successful-git-branching-model/](http://nvie.com/posts/a-successful-git-branching-model/).
32+
33+
> Deletion of `master` and `develop`.
34+
> Rebasing on `master` is blocked.
35+
36+
## Preferred IDE
37+
38+
Please use an IDE with [EditorConfig](http://editorconfig.org/) support.
39+
40+
Things like using 120 character ruler, addition of end-of-file newline, cleaning up of trailing whitespace have been
41+
configured in this project using `.editorconfig`.
42+
43+
## Commit Guidelines
44+
45+
The following best practices, coupled with a pinch of common-sense will keep the repository clean and usable in future.
46+
The idea is that everything that goes into the repository is not for an individual, but someone else who will be
47+
directly or indirectly affected by it.
48+
49+
### Check for errors before committing
50+
51+
Checking for errors should be done for each commit whether it is being pushed to remote or not.
52+
53+
First, you don't want to submit any whitespace errors. Git provides an easy way to check for this — before you commit,
54+
run `git diff --check`, which identifies possible whitespace errors and lists them for you. If you run that command
55+
before committing, you can tell if you're about to commit whitespace issues that may annoy other developers.
56+
57+
Secondly, you should ensure that your commit does not break builds. Run `npm test` on the repository to execute all
58+
sanity and smoke tests. If any test fail, do not change the test to pass your commit. The tests were there with a
59+
purpose. Discuss within your team to ensure that the changes that you do to test specs are valid. If you are adding a
60+
new feature, accompanying them with new tests are a good practice.
61+
62+
### Atomic commits
63+
64+
Try to make each commit a logically separate changeset. If you can, try to make your changes digestible — don't code for
65+
a whole weekend on five different issues and then submit them all as one massive commit on Monday. Even if you don't
66+
commit during the weekend, use the staging area on Monday to split your work into at least one commit per issue, with a
67+
useful message per commit. If some of the changes modify the same file, try to use `git add --patch` to partially stage
68+
files. The project snapshot at the tip of the branch is identical whether you do one commit or five, as long as all the
69+
changes are added at some point, so try to make things easier on your fellow developers when they have to review your
70+
changes. This approach also makes it easier to pull out or revert one of the changesets if you need to later. There are
71+
a number of useful Git tricks for rewriting history and interactively staging files — use these tools to help craft a
72+
clean and understandable history.
73+
74+
### Clean commit message
75+
76+
*More detailed explanation includes your motivation for the change and contrast its implementation with previous
77+
behavior — this is a good guideline to follow.*
78+
79+
Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. As a
80+
general rule, your messages should start with a single line that’s no more than about 50 characters and that describes
81+
the changeset concisely, followed by a blank line, followed by a more detailed explanation.
82+
83+
It's also a good idea to use the imperative present tense in these messages. In other words, use commands. Instead of
84+
"I added tests for" or "Adding tests for," use "Add tests for."
85+
86+
You should see if your commit message answers the following questions:
87+
Answer the following questions:
88+
89+
1. **Why is this change necessary?**
90+
2. **How does it address the issue?**
91+
3. **What side effects does this change have?**
92+
93+
The first question tells reviewers of your pull request what to expect in the commit, allowing them to more easily
94+
identify and point out unrelated changes.
95+
96+
The second question describes, at a high level, what was done to affect change. If your change is obvious, you may be
97+
able to omit addressing this question.
98+
99+
The third is the most important question to answer, as it can point out problems where you are making too many changes
100+
in one commit or branch. One or two bullet points for related changes may be okay, but five or six are likely indicators
101+
of a commit that is doing too many things.
102+
103+
A good commit message template
104+
105+
```
106+
Short (50 chars or less) summary of changes with relevant project management issue ID.
107+
108+
More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line
109+
is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from
110+
the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two
111+
together.
112+
113+
Further paragraphs come after blank lines.
114+
115+
- Bullet points are okay, too
116+
117+
- Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but
118+
conventions vary here
119+
```
120+
121+
Run `git log --no-merges` to see what a nicely formatted project-commit history looks like.
122+
123+
## Guidelines for sending a Pull Request
124+
125+
Commit to master branch and develop branch is locked. As such, `git-flow` for feature completion and release will not
126+
work. Thus, the last steps of feature completion in `git-flow` will happen as a Pull Request from website.
127+
128+
1. Pull Request comment and commit comments should explicitly discuss what changes were made. The Pull Request reviewer
129+
should not need to communicate out of scope of issue tracker and the pull request description in order to understand
130+
what changes has been done.
131+
132+
2. Pull Request should not be accepted with a test failure. Ensure that `npm test` passes on the `head` of your feature
133+
branch.
134+
135+
3. Ensure that your feature branch has been tested and if it is associated with issues from corresponding issue-tracker,
136+
the issue must be in a "resolved" state, implying that the issue has been fully tested, and accepted for inclusion.
137+
138+
4. Pull Requests with merge conflict are very difficult to review. Ensure that the `head` of your feature branch is
139+
either already merged with `develop` or has no conflict when it is merged with `develop`.
140+
141+
5. The turn around time to close Pull Request is directly proportional to the delta of changes done - more the change in
142+
files, more time it would take. As such, if you anticipate a feature branch to have a large delta on feature
143+
completion, break it into sub-issues of the issue-tracker, test them, close them, and then send PR for that branch.
144+
145+
6. Turn around time for Pull Request would get affected if commit messages are unclear.
146+
147+
7. If you have deadlines to ensure feature completion, send Pull Request ahead of time. Better still, ensure your
148+
feature development timeline accounts for PR acceptance.
149+
150+
8. If you have mentioned issue tracker references in Pull Request description, the severity and priority of those issues
151+
will be taken into account. Otherwise, no Pull Request will take priority over others already in queue - it is
152+
first-pull first-merge!
153+
154+
## Documentation guidelines
155+
156+
~~ to be documented further ~~
157+
158+
## The CI Platform
159+
160+
The CI system is built as a bunch of bash scripts to execute a set of tasks. These scripts are meant to execute tasks
161+
that can run on every local machine. In general, knowledge about these scripts are not necessary for development.
162+
163+
**The scripts are to be only accessed using `npm run <script name>`.** This ensures that the execution point of the
164+
scripts (`pwd`) is always the repository root.
165+
166+
### Ensuring your commits will not fail build
167+
168+
> `npm test`
169+
170+
The script associated with `npm test` will run all tests that ensures that your commit does not break anything in the
171+
repository. As such run `npm test` before you push.
172+
173+
~~ to be documented further ~~
174+
175+
### Accessing build log on CI server
176+
177+
~~ to be documented further ~~
178+
179+
### Accessing your build artifacts
180+
181+
All scripts output build artifacts to `./out`
182+
183+
184+
---
185+
*Sections of this document use excerpts from various books and the Internet.
186+
[http://git-scm.com/book/](http://git-scm.com/book/) is one of the dominating influences.*

‎LICENSE.md

+176
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,176 @@
1+
Apache License
2+
Version 2.0, January 2004
3+
http://www.apache.org/licenses/
4+
5+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
6+
7+
1. Definitions.
8+
9+
"License" shall mean the terms and conditions for use, reproduction,
10+
and distribution as defined by Sections 1 through 9 of this document.
11+
12+
"Licensor" shall mean the copyright owner or entity authorized by
13+
the copyright owner that is granting the License.
14+
15+
"Legal Entity" shall mean the union of the acting entity and all
16+
other entities that control, are controlled by, or are under common
17+
control with that entity. For the purposes of this definition,
18+
"control" means (i) the power, direct or indirect, to cause the
19+
direction or management of such entity, whether by contract or
20+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
21+
outstanding shares, or (iii) beneficial ownership of such entity.
22+
23+
"You" (or "Your") shall mean an individual or Legal Entity
24+
exercising permissions granted by this License.
25+
26+
"Source" form shall mean the preferred form for making modifications,
27+
including but not limited to software source code, documentation
28+
source, and configuration files.
29+
30+
"Object" form shall mean any form resulting from mechanical
31+
transformation or translation of a Source form, including but
32+
not limited to compiled object code, generated documentation,
33+
and conversions to other media types.
34+
35+
"Work" shall mean the work of authorship, whether in Source or
36+
Object form, made available under the License, as indicated by a
37+
copyright notice that is included in or attached to the work
38+
(an example is provided in the Appendix below).
39+
40+
"Derivative Works" shall mean any work, whether in Source or Object
41+
form, that is based on (or derived from) the Work and for which the
42+
editorial revisions, annotations, elaborations, or other modifications
43+
represent, as a whole, an original work of authorship. For the purposes
44+
of this License, Derivative Works shall not include works that remain
45+
separable from, or merely link (or bind by name) to the interfaces of,
46+
the Work and Derivative Works thereof.
47+
48+
"Contribution" shall mean any work of authorship, including
49+
the original version of the Work and any modifications or additions
50+
to that Work or Derivative Works thereof, that is intentionally
51+
submitted to Licensor for inclusion in the Work by the copyright owner
52+
or by an individual or Legal Entity authorized to submit on behalf of
53+
the copyright owner. For the purposes of this definition, "submitted"
54+
means any form of electronic, verbal, or written communication sent
55+
to the Licensor or its representatives, including but not limited to
56+
communication on electronic mailing lists, source code control systems,
57+
and issue tracking systems that are managed by, or on behalf of, the
58+
Licensor for the purpose of discussing and improving the Work, but
59+
excluding communication that is conspicuously marked or otherwise
60+
designated in writing by the copyright owner as "Not a Contribution."
61+
62+
"Contributor" shall mean Licensor and any individual or Legal Entity
63+
on behalf of whom a Contribution has been received by Licensor and
64+
subsequently incorporated within the Work.
65+
66+
2. Grant of Copyright License. Subject to the terms and conditions of
67+
this License, each Contributor hereby grants to You a perpetual,
68+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
69+
copyright license to reproduce, prepare Derivative Works of,
70+
publicly display, publicly perform, sublicense, and distribute the
71+
Work and such Derivative Works in Source or Object form.
72+
73+
3. Grant of Patent License. Subject to the terms and conditions of
74+
this License, each Contributor hereby grants to You a perpetual,
75+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
76+
(except as stated in this section) patent license to make, have made,
77+
use, offer to sell, sell, import, and otherwise transfer the Work,
78+
where such license applies only to those patent claims licensable
79+
by such Contributor that are necessarily infringed by their
80+
Contribution(s) alone or by combination of their Contribution(s)
81+
with the Work to which such Contribution(s) was submitted. If You
82+
institute patent litigation against any entity (including a
83+
cross-claim or counterclaim in a lawsuit) alleging that the Work
84+
or a Contribution incorporated within the Work constitutes direct
85+
or contributory patent infringement, then any patent licenses
86+
granted to You under this License for that Work shall terminate
87+
as of the date such litigation is filed.
88+
89+
4. Redistribution. You may reproduce and distribute copies of the
90+
Work or Derivative Works thereof in any medium, with or without
91+
modifications, and in Source or Object form, provided that You
92+
meet the following conditions:
93+
94+
(a) You must give any other recipients of the Work or
95+
Derivative Works a copy of this License; and
96+
97+
(b) You must cause any modified files to carry prominent notices
98+
stating that You changed the files; and
99+
100+
(c) You must retain, in the Source form of any Derivative Works
101+
that You distribute, all copyright, patent, trademark, and
102+
attribution notices from the Source form of the Work,
103+
excluding those notices that do not pertain to any part of
104+
the Derivative Works; and
105+
106+
(d) If the Work includes a "NOTICE" text file as part of its
107+
distribution, then any Derivative Works that You distribute must
108+
include a readable copy of the attribution notices contained
109+
within such NOTICE file, excluding those notices that do not
110+
pertain to any part of the Derivative Works, in at least one
111+
of the following places: within a NOTICE text file distributed
112+
as part of the Derivative Works; within the Source form or
113+
documentation, if provided along with the Derivative Works; or,
114+
within a display generated by the Derivative Works, if and
115+
wherever such third-party notices normally appear. The contents
116+
of the NOTICE file are for informational purposes only and
117+
do not modify the License. You may add Your own attribution
118+
notices within Derivative Works that You distribute, alongside
119+
or as an addendum to the NOTICE text from the Work, provided
120+
that such additional attribution notices cannot be construed
121+
as modifying the License.
122+
123+
You may add Your own copyright statement to Your modifications and
124+
may provide additional or different license terms and conditions
125+
for use, reproduction, or distribution of Your modifications, or
126+
for any such Derivative Works as a whole, provided Your use,
127+
reproduction, and distribution of the Work otherwise complies with
128+
the conditions stated in this License.
129+
130+
5. Submission of Contributions. Unless You explicitly state otherwise,
131+
any Contribution intentionally submitted for inclusion in the Work
132+
by You to the Licensor shall be under the terms and conditions of
133+
this License, without any additional terms or conditions.
134+
Notwithstanding the above, nothing herein shall supersede or modify
135+
the terms of any separate license agreement you may have executed
136+
with Licensor regarding such Contributions.
137+
138+
6. Trademarks. This License does not grant permission to use the trade
139+
names, trademarks, service marks, or product names of the Licensor,
140+
except as required for reasonable and customary use in describing the
141+
origin of the Work and reproducing the content of the NOTICE file.
142+
143+
7. Disclaimer of Warranty. Unless required by applicable law or
144+
agreed to in writing, Licensor provides the Work (and each
145+
Contributor provides its Contributions) on an "AS IS" BASIS,
146+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
147+
implied, including, without limitation, any warranties or conditions
148+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
149+
PARTICULAR PURPOSE. You are solely responsible for determining the
150+
appropriateness of using or redistributing the Work and assume any
151+
risks associated with Your exercise of permissions under this License.
152+
153+
8. Limitation of Liability. In no event and under no legal theory,
154+
whether in tort (including negligence), contract, or otherwise,
155+
unless required by applicable law (such as deliberate and grossly
156+
negligent acts) or agreed to in writing, shall any Contributor be
157+
liable to You for damages, including any direct, indirect, special,
158+
incidental, or consequential damages of any character arising as a
159+
result of this License or out of the use or inability to use the
160+
Work (including but not limited to damages for loss of goodwill,
161+
work stoppage, computer failure or malfunction, or any and all
162+
other commercial damages or losses), even if such Contributor
163+
has been advised of the possibility of such damages.
164+
165+
9. Accepting Warranty or Additional Liability. While redistributing
166+
the Work or Derivative Works thereof, You may choose to offer,
167+
and charge a fee for, acceptance of support, warranty, indemnity,
168+
or other liability obligations and/or rights consistent with this
169+
License. However, in accepting such obligations, You may act only
170+
on Your own behalf and on Your sole responsibility, not on behalf
171+
of any other Contributor, and only if You agree to indemnify,
172+
defend, and hold each Contributor harmless for any liability
173+
incurred by, or claims asserted against, such Contributor by reason
174+
of your accepting any such warranty or additional liability.
175+
176+
END OF TERMS AND CONDITIONS

0 commit comments

Comments
 (0)