semantic-release 17.4.4 → 17.4.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.
Files changed (5) hide show
  1. package/docs/recipes/circleci-workflows.md +16 -23
  2. package/docs/recipes/maintenance-releases.md +2 -2
  3. package/docs/usage/plugins.md +4 -0
  4. package/docs/usage/workflow-configuration.md +2 -2
  5. package/package.json +5 -5
package/docs/recipes/circleci-workflows.md CHANGED
@@ -10,46 +10,39 @@ Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with
10
10
 
11
11
  ### `.circleci/config.yml` configuration for multiple Node jobs
12
12
 
13
- This example is a minimal configuration for **semantic-release** with a build running Node 6 and 8. See [CircleCI documentation](https://circleci.com/docs/2.0) for additional configuration options.
13
+ This example is a minimal configuration for **semantic-release** with tests running against Node 16 and 14. See [CircleCI documentation](https://circleci.com/docs/2.0) for additional configuration options.
14
14
 
15
- This example create the workflows `test_node_4`, `test_node_6`, `test_node_8` and `release`. The release workflows will [run `semantic-release` only after the all the `test_node_*` are successful](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded).
15
+ In this example, the [`circleci/node`](https://circleci.com/developer/orbs/orb/circleci/node) orb is imported (Which makes some node operations easier), then a `release` job is defined which will run `semantic-release`.
16
+
17
+ To run our `release` job, we have created a workflow named `test_and_release` which will run two jobs, `node/test`, which comes from the node orb and will test our application, and our release job. Here, we are actually making use of [matrix jobs](https://circleci.com/blog/circleci-matrix-jobs/) so that our single `node/test` job will actually be executed twice, once for Node version 16, and once for version 14. Finally, we call our release job with a `requires` parameter so that `release` will only run after `node/test` has successfully tested against v14 and v16.
16
18
 
17
19
  ```yaml
18
- version: 2
20
+ version: 2.1
21
+ orbs:
22
+ node: circleci/node@4.5
19
23
  jobs:
20
- test_node_6:
21
- docker:
22
- - image: circleci/node:6
23
- steps:
24
- # Configure your test steps here (checkout, npm install, cache management, tests etc...)
25
-
26
- test_node_8:
27
- docker:
28
- - image: circleci/node:8
29
- steps:
30
- # Configure your test steps here (checkout, npm install, cache management, tests etc...)
31
-
32
24
  release:
33
- docker:
34
- - image: circleci/node:8
25
+ executor: node/default
35
26
  steps:
36
27
  - checkout
37
- - run: npm install
28
+ - node/install-packages # Install and automatically cache packages
38
29
  # Run optional required steps before releasing
39
30
  # - run: npm run build-script
40
31
  - run: npx semantic-release
41
32
 
42
33
  workflows:
43
- version: 2
44
34
  test_and_release:
45
35
  # Run the test jobs first, then the release only when all the test jobs are successful
46
36
  jobs:
47
- - test_node_6
48
- - test_node_8
37
+ - node/test:
38
+ matrix:
39
+ parameters:
40
+ version:
41
+ - 16.1.0
42
+ - 14.7.0
49
43
  - release:
50
44
  requires:
51
- - test_node_6
52
- - test_node_8
45
+ - node/test
53
46
  ```
54
47
 
55
48
  ### `package.json` configuration for multiple Node jobs
package/docs/recipes/maintenance-releases.md CHANGED
@@ -33,7 +33,7 @@ The Git history of the repository is now:
33
33
 
34
34
  One of our users request a new feature, however they cannot migrate to Node.js 8 or higher due to corporate policies.
35
35
 
36
- If we were to push that feature on `master` and release it, the new version would require Node.js 8 or higher as the release would also contains the commit `feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required`.
36
+ If we were to push that feature on `master` and release it, the new version would require Node.js 8 or higher as the release would also contain the commit `feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required`.
37
37
 
38
38
  Instead, we create the branch `1.x` from the tag `v1.0.0` with the command `git checkout -b 1.x v1.0.0` and we commit that feature with the message `feat: a feature` to the branch `1.x`. When pushing that commit, **semantic-release** will release the version `1.1.0` on the dist-tag `@release-1.x` so users who can't migrate to Node.js 8 or higher can benefit from it.
39
39
 
@@ -48,7 +48,7 @@ The Git history of the repository is now:
48
48
 
49
49
  ## Releasing a bug fix for version 1.0.x users
50
50
 
51
- Another user currently using version `1.0.0` reports a bug. They cannot migrate to Node.js 8 or higher and they also cannot migrate to `1.1.0` as they do not use the feature developed in `feat: a feature` and their corporate policies require to go through a costly quality insurance process for each `minor` upgrades.
51
+ Another user currently using version `1.0.0` reports a bug. They cannot migrate to Node.js 8 or higher and they also cannot migrate to `1.1.0` as they do not use the feature developed in `feat: a feature` and their corporate policies require to go through a costly quality assurance process for each `minor` upgrades.
52
52
 
53
53
  In order to deliver the bug fix in a `patch` release, we create the branch `1.0.x` from the tag `v1.0.0` with the command `git checkout -b 1.0.x v1.0.0` and we commit that fix with the message `fix: a fix` to the branch `1.0.x`. When pushing that commit, **semantic-release** will release the version `1.0.1` on the dist-tag `@release-1.0.x` so users who can't migrate to `1.1.x` or `2.x` can benefit from it.
54
54
 
package/docs/usage/plugins.md CHANGED
@@ -16,6 +16,8 @@ A plugin is a npm module that can implement one or more of the following steps:
16
16
  | `success` | No | Responsible for notifying of a new release. |
17
17
  | `fail` | No | Responsible for notifying of a failed release. |
18
18
 
19
+ Release steps will run in that order. At each step, **semantic-release** will run every plugin in the [`plugins` array](#plugins-declaration-and-execution-order), as long as the plugin implements the step.
20
+
19
21
  **Note:** If no plugin with a `analyzeCommits` step is defined `@semantic-release/commit-analyzer` will be used.
20
22
 
21
23
  ## Plugins installation
@@ -70,6 +72,8 @@ With this configuration **semantic-release** will:
70
72
  - execute the `prepare` implementation of `@semantic-release/npm` then `@semantic-release/git`
71
73
  - execute the `publish` implementation of `@semantic-release/npm`
72
74
 
75
+ Order is first determined by release steps (such as `verifyConditions` → `anayzeCommits`). At each release step, plugins are executed in the order in which they are defined.
76
+
73
77
  ## Plugin options configuration
74
78
 
75
79
  A plugin configuration can be specified by wrapping the name and an options object in an array. Options configured this way will be passed only to that specific plugin.
package/docs/usage/workflow-configuration.md CHANGED
@@ -13,7 +13,7 @@ Each branch can be defined either as a string, a [glob](https://github.com/micro
13
13
 
14
14
  A branch can defined as one of three types:
15
15
  - [release](#release-branches): to make releases on top of the last version released
16
- - [maintenance](#maintenance-branches): to make release on top of an old release
16
+ - [maintenance](#maintenance-branches): to make releases on top of an old release
17
17
  - [pre-release](#pre-release-branches): to make pre-releases
18
18
 
19
19
  The type of the branch is automatically determined based on naming convention and/or [properties](#branches-properties).
@@ -25,7 +25,7 @@ The type of the branch is automatically determined based on naming convention an
25
25
  | `name` | All | **Required.** The Git branch holding the commits to analyze and the code to release. See [name](#name). | - The value itself if defined as a `String` or the matching branches name if defined as a glob. |
26
26
  | `channel` | All | The distribution channel on which to publish releases from this branch. Set to `false` to force the default distribution channel instead of using the default. See [channel](#channel). | `undefined` for the first release branch, the value of `name` for subsequent ones. |
27
27
  | `range` | [maintenance](#maintenance-branches) only | **Required unless `name` is formatted like `N.N.x` or `N.x` (`N` is a number).** The range of [semantic versions](https://semver.org) to support on this branch. See [range](#range). | The value of `name`. |
28
- | `prerelease` | [pre-release](#pre-release-branches) only | **Required.** The pre-release detonation to append to [semantic versions](https://semver.org) released from this branch. See [prerelease](#prerelease). | - |
28
+ | `prerelease` | [pre-release](#pre-release-branches) only | **Required.** The pre-release denotation to append to [semantic versions](https://semver.org) released from this branch. See [prerelease](#prerelease). | - |
29
29
 
30
30
  ### name
31
31
 
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "semantic-release",
3
3
  "description": "Automated semver compliant package publishing",
4
- "version": "17.4.4",
4
+ "version": "17.4.5",
5
5
  "author": "Stephan Bönnemann <stephan@boennemann.me> (http://boennemann.me)",
6
6
  "ava": {
7
7
  "files": [
@@ -37,7 +37,7 @@
37
37
  "hook-std": "^2.0.0",
38
38
  "hosted-git-info": "^4.0.0",
39
39
  "lodash": "^4.17.21",
40
- "marked": "^2.0.0",
40
+ "marked": "^3.0.0",
41
41
  "marked-terminal": "^4.1.1",
42
42
  "micromatch": "^4.0.2",
43
43
  "p-each-series": "^2.1.0",
@@ -58,11 +58,11 @@
58
58
  "file-url": "3.0.0",
59
59
  "fs-extra": "10.0.0",
60
60
  "got": "11.8.2",
61
- "js-yaml": "3.14.1",
61
+ "js-yaml": "4.1.0",
62
62
  "mockserver-client": "5.11.2",
63
- "nock": "13.1.0",
63
+ "nock": "13.1.1",
64
64
  "nyc": "15.1.0",
65
- "p-retry": "4.5.0",
65
+ "p-retry": "4.6.1",
66
66
  "proxyquire": "2.1.3",
67
67
  "sinon": "11.1.1",
68
68
  "stream-buffers": "3.0.2",