semantic-release 4.3.4 → 4.3.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +45 -25
- package/dist/lib/commits.js +14 -12
- package/package.json +9 -5
- package/test/mocks/child-process.js +1 -0
package/README.md
CHANGED
|
@@ -1,10 +1,15 @@
|
|
|
1
|
-
# semantic-release
|
|
1
|
+
# :package::rocket: semantic-release
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
**fully automated package publishing**
|
|
4
|
+
|
|
5
|
+
> **Trust us, this will change your workflow for the better.**
|
|
6
|
+
|
|
7
|
+
> – [egghead.io](https://egghead.io/lessons/javascript-how-to-write-a-javascript-library-automating-releases-with-semantic-release)
|
|
4
8
|
|
|
5
9
|
[](https://gitter.im/semantic-release/semantic-release?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
|
|
6
10
|
[](https://github.com/semantic-release/semantic-release)
|
|
7
11
|
[](https://github.com/feross/standard)
|
|
12
|
+
[](http://commitizen.github.io/cz-cli/)
|
|
8
13
|
|
|
9
14
|
[](https://david-dm.org/semantic-release/semantic-release/badger)
|
|
10
15
|
[](https://david-dm.org/semantic-release/semantic-release/badger#info=devDependencies)
|
|
@@ -23,12 +28,27 @@ Out of the box this is just about _commit-messages_, but you can do so much more
|
|
|
23
28
|
|
|
24
29
|
| Commands | Comment
|
|
25
30
|
--- | --- | ---
|
|
26
|
-
| **manual** | <pre><code><div>npm version major</div><div>git push origin master --tags</div><div>npm publish</div></code></pre> | You **manually decide** what the **next version** is. You have to remember what major, minor and patch means. You have to remember to push both commits and tags. You have to wait for the CI to pass. |
|
|
27
|
-
| **semantic-release** | <pre><code><div>git commit -m "fix: <message>"</div><div>git push</div></code></pre> | You **describe the changes** you’ve made. A new version is automatically published with the correct version number.
|
|
31
|
+
| **manual/before** | <pre><code><div>npm version major</div><div>git push origin master --tags</div><div>npm publish</div></code></pre> | You **manually decide** what the **next version** is. You have to remember what major, minor and patch means. You have to remember to push both commits and tags. You have to wait for the CI to pass. |
|
|
32
|
+
| **semantic-release/after** | <pre><code><div>git commit -m "fix: <message>"</div><div>git push</div></code></pre> | You **describe the changes** you’ve made. A new version is automatically published with the correct version number.
|
|
28
33
|
|
|
29
34
|
This removes the immediate connection between human emotions and version numbers, so strictly following the [SemVer](http://semver.org/) spec is not a problem anymore – and that’s ultimately `semantic-release`’s goal.
|
|
30
35
|
|
|
31
36
|
<table>
|
|
37
|
+
<tr>
|
|
38
|
+
<th colspan="2">
|
|
39
|
+
“How to Write a JavaScript Library - Automating Releases with semantic-release” – egghead.io
|
|
40
|
+
</th>
|
|
41
|
+
</tr>
|
|
42
|
+
<tr>
|
|
43
|
+
<td colspan="2">
|
|
44
|
+
<a href="https://egghead.io/lessons/javascript-how-to-write-a-javascript-library-automating-releases-with-semantic-release"><img src="https://cloud.githubusercontent.com/assets/908178/9730739/7b1da5d8-5610-11e5-88b6-5c75fdda7ee2.png" alt="egghead.io session"></a>
|
|
45
|
+
</td>
|
|
46
|
+
</tr>
|
|
47
|
+
<tr>
|
|
48
|
+
<td colspan="2">
|
|
49
|
+
A free egghead.io tutorial series on how to write an open source library featuring semantic-release.
|
|
50
|
+
</td>
|
|
51
|
+
</tr>
|
|
32
52
|
<tr>
|
|
33
53
|
<th>
|
|
34
54
|
“We fail to follow SemVer – and why it needn’t matter”
|
|
@@ -59,14 +79,26 @@ This removes the immediate connection between human emotions and version numbers
|
|
|
59
79
|
|
|
60
80
|
Instead of writing [meaningless commit messages](http://whatthecommit.com/), we can take our time to think about the changes in the codebase and write them down. Following formalized conventions it this then possible to generate a helpful changelog and to derive the next semantic version number from them.
|
|
61
81
|
|
|
62
|
-
|
|
82
|
+
When `semantic-release` got setup it will do that after every successful continuous integration build of your master branch (or any other branch you specify) and publish the new version for you. That way no human is directly involved in the release process and your releases are guaranteed to be [unromantic and unsentimental](http://sentimentalversioning.org/).
|
|
83
|
+
|
|
84
|
+
If you fear the loss of control over timing and marketing implications of software releases you should know that `semantic-release` supports [release channels](https://github.com/npm/npm/issues/2718) using `npm`’s [dist-tags](https://docs.npmjs.com/cli/tag). This way you can keep control over what your users end up using by default, you can decide when to promote an automatically released version to the stable channel and you can choose which versions to write blogposts and tweets about. You can use the same mechanism to [support older versions of your software](https://gist.github.com/boennemann/54042374e49c7ade8910), for example with important security fixes.
|
|
85
|
+
|
|
86
|
+
This is what happens in series:
|
|
87
|
+
|
|
88
|
+
| 1. `git push` | 2. `semantic-release pre` | 3. `npm publish` | 4. `semantic-release post` |
|
|
89
|
+
| :--- | :--- | :--- | :---- |
|
|
90
|
+
| New code is pushed and triggers a CI build. | Based on all commits that happened since the last release, the new version number gets written to the `package.json`. | The new version gets published to `npm`. | A changelog gets generated and a [release](https://help.github.com/articles/about-releases/) (including a git tag) on GitHub gets created. |
|
|
91
|
+
|
|
92
|
+
_Note:_ The current release/tag implementation is tied to GitHub, but could be opened up to Bitbucket, GitLab, et al. Feel free to send PRs for these services.
|
|
93
|
+
|
|
94
|
+
## Default Commit Message Format
|
|
63
95
|
|
|
64
|
-
|
|
96
|
+
This module ships with the [AngularJS Commit Message Conventions](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit) and changelog generator, but you can [define your own](#plugins) style.
|
|
65
97
|
|
|
66
|
-
|
|
98
|
+
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
|
|
67
99
|
format that includes a **type**, a **scope** and a **subject**:
|
|
68
100
|
|
|
69
|
-
|
|
101
|
+
```
|
|
70
102
|
<type>(<scope>): <subject>
|
|
71
103
|
<BLANK LINE>
|
|
72
104
|
<body>
|
|
@@ -74,19 +106,7 @@ format that includes a **type**, a **scope** and a **subject**:
|
|
|
74
106
|
<footer>
|
|
75
107
|
```
|
|
76
108
|
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
When `semantic-release` got setup it will do that after every successful continuous integration build of your master branch (or any other branch you specify) and publish the new version for you. That way no human is directly involved in the release process and your releases are guaranteed to be [unromantic and unsentimental](http://sentimentalversioning.org/).
|
|
80
|
-
|
|
81
|
-
If you fear the loss of control over timing and marketing implications of software releases you should know that `semantic-release` supports [release channels](https://github.com/npm/npm/issues/2718) using `npm`’s [dist-tags](https://docs.npmjs.com/cli/tag). This way you can keep control over what your users end up using by default, you can decide when to promote an automatically released version to the stable channel and you can choose which versions to write blogposts and tweets about. You can use the same mechanism to support older versions of your software, for example with important security fixes.
|
|
82
|
-
|
|
83
|
-
This is what happens in series:
|
|
84
|
-
|
|
85
|
-
| 1. `git push` | 2. `semantic-release pre` | 3. `npm publish` | 4. `semantic-release post` |
|
|
86
|
-
| :--- | :--- | :--- | :---- |
|
|
87
|
-
| New code is pushed and triggers a CI build. | Based on all commits that happened since the last release, the new version number gets written to the `package.json`. | The new version gets published to `npm`. | A changelog gets generated and a [release](https://help.github.com/articles/about-releases/) (including a git tag) on GitHub gets created. |
|
|
88
|
-
|
|
89
|
-
_Note:_ The current release/tag implementation is tied to GitHub, but could be opened up to Bitbucket, GitLab, et al. Feel free to send PRs for these services.
|
|
109
|
+
[Full explanation](https://github.com/ajoslin/conventional-changelog/blob/master/conventions/angular.md)
|
|
90
110
|
|
|
91
111
|
## Setup
|
|
92
112
|
|
|
@@ -113,7 +133,7 @@ You can pass options either via command line (in [kebab-case](https://lodash.com
|
|
|
113
133
|
|
|
114
134
|
|
|
115
135
|
These options are currently available:
|
|
116
|
-
- `branch`: The branch on which releases should happen. Default:
|
|
136
|
+
- `branch`: The branch on which releases should happen. Default: `'master'`
|
|
117
137
|
- `debug`: If true doesn’t actually publish to npm or write things to file. Default: `!process.env.CI`
|
|
118
138
|
- `githubToken`: The token used to authenticate with GitHub. Default: `process.env.GH_TOKEN`
|
|
119
139
|
- `githubUrl`: Optional. Pass your GitHub Enterprise endpoint.
|
|
@@ -121,9 +141,9 @@ These options are currently available:
|
|
|
121
141
|
_A few notes on `npm` config_:
|
|
122
142
|
1. The `npm` token can only be defined in the environment as `NPM_TOKEN`, because that’s where `npm` itself is going to read it from.
|
|
123
143
|
|
|
124
|
-
2. In order to publish to a different `npm` registry you can
|
|
144
|
+
2. In order to publish to a different `npm` registry you can specify that inside the `package.json`’s [`publishConfig`](https://docs.npmjs.com/files/package.json#publishconfig) field.
|
|
125
145
|
|
|
126
|
-
3. If you want to use another dist-tag for your publishes than
|
|
146
|
+
3. If you want to use another dist-tag for your publishes than `'latest'` you can specify that inside the `package.json`’s [`publishConfig`](https://docs.npmjs.com/files/package.json#publishconfig) field.
|
|
127
147
|
|
|
128
148
|
4. `semantic-release` generally tries to orientate itself towards `npm` – it inherits the loglevel for example.
|
|
129
149
|
|
|
@@ -248,4 +268,4 @@ Use this in one of your projects? Include one of these badges in your README.md
|
|
|
248
268
|
MIT License
|
|
249
269
|
2015 © Stephan Bönnemann and [contributors](https://github.com/semantic-release/semantic-release/graphs/contributors)
|
|
250
270
|
|
|
251
|
-
](https://twitter.com/trodrigues/status/509301317467373571)
|
package/dist/lib/commits.js
CHANGED
|
@@ -19,21 +19,23 @@ module.exports = function (_ref, cb) {
|
|
|
19
19
|
if (!from) return extract();
|
|
20
20
|
|
|
21
21
|
exec('git branch --contains ' + from, function (err, stdout) {
|
|
22
|
-
if (err) return cb(err);
|
|
23
22
|
var inHistory = false;
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
23
|
+
var branches = undefined;
|
|
24
|
+
|
|
25
|
+
if (!err && stdout) {
|
|
26
|
+
branches = stdout.split('\n').map(function (result) {
|
|
27
|
+
if (branch === result.replace('*', '').trim()) {
|
|
28
|
+
inHistory = true;
|
|
29
|
+
return null;
|
|
30
|
+
}
|
|
31
|
+
return result.trim();
|
|
32
|
+
}).filter(function (branch) {
|
|
33
|
+
return !!branch;
|
|
34
|
+
});
|
|
35
|
+
}
|
|
34
36
|
|
|
35
37
|
if (!inHistory) {
|
|
36
|
-
log.error('commits', 'The commit the last release of this package was derived from is
|
|
38
|
+
log.error('commits', 'The commit the last release of this package was derived from is not in the direct history of the "' + branch + '" branch.\nThis means semantic-release can not extract the commits between now and then.\nThis is usually caused by force pushing, releasing from an unrelated branch, or using an already existing package name.\nYou can recover from this error by publishing manually or restoring the commit "' + from + '".' + (branches && branches.length ? '\nHere is a list of branches that still contain the commit in question: \n * ' + branches.join('\n * ') : ''));
|
|
37
39
|
return cb(new SemanticReleaseError('Commit not in history', 'ENOTINHISTORY'));
|
|
38
40
|
}
|
|
39
41
|
|
package/package.json
CHANGED
|
@@ -8,10 +8,6 @@
|
|
|
8
8
|
"bugs": {
|
|
9
9
|
"url": "https://github.com/semantic-release/semantic-release/issues"
|
|
10
10
|
},
|
|
11
|
-
"engines": {
|
|
12
|
-
"node": ">=0.10",
|
|
13
|
-
"npm": ">=2"
|
|
14
|
-
},
|
|
15
11
|
"config": {
|
|
16
12
|
"nyc": {
|
|
17
13
|
"exclude": [
|
|
@@ -20,6 +16,9 @@
|
|
|
20
16
|
]
|
|
21
17
|
}
|
|
22
18
|
},
|
|
19
|
+
"czConfig": {
|
|
20
|
+
"path": "node_modules/cz-conventional-changelog/"
|
|
21
|
+
},
|
|
23
22
|
"dependencies": {
|
|
24
23
|
"@semantic-release/commit-analyzer": "^2.0.0",
|
|
25
24
|
"@semantic-release/condition-travis": "^4.1.2",
|
|
@@ -42,6 +41,7 @@
|
|
|
42
41
|
"devDependencies": {
|
|
43
42
|
"babel": "^5.5.8",
|
|
44
43
|
"coveralls": "^2.11.2",
|
|
44
|
+
"cz-conventional-changelog": "^1.1.0",
|
|
45
45
|
"mkdirp": "^0.5.1",
|
|
46
46
|
"nixt": "^0.4.1",
|
|
47
47
|
"nock": "^2.5.0",
|
|
@@ -52,6 +52,10 @@
|
|
|
52
52
|
"standard": "^5.0.2",
|
|
53
53
|
"tap": "^1.3.1"
|
|
54
54
|
},
|
|
55
|
+
"engines": {
|
|
56
|
+
"node": ">=0.10",
|
|
57
|
+
"npm": ">=2"
|
|
58
|
+
},
|
|
55
59
|
"homepage": "https://github.com/semantic-release/semantic-release/tree/next#readme",
|
|
56
60
|
"keywords": [
|
|
57
61
|
"author",
|
|
@@ -87,5 +91,5 @@
|
|
|
87
91
|
"test:style": "standard",
|
|
88
92
|
"test:unit": "nyc tap --no-cov .test/specs/*.js"
|
|
89
93
|
},
|
|
90
|
-
"version": "4.3.
|
|
94
|
+
"version": "4.3.5"
|
|
91
95
|
}
|