semantic-release 17.4.3 → 17.4.4

package/README.md

@@ -52,7 +52,7 @@ By default **semantic-release** uses [Angular Commit Message Conventions](https:
 
 Tools such as [commitizen](https://github.com/commitizen/cz-cli) or [commitlint](https://github.com/conventional-changelog/commitlint) can be used to help contributors and enforce valid commit messages.
 
-Here is an example of the release type that will be done based on a commit messages:
+The table below shows which commit message gets you which release type when `semantic-release` runs (using the default configuration):
 
 | Commit message                                                                                                                                                                                   | Release type               |
 | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------- |

package/docs/developer-guide/plugin.md

@@ -183,9 +183,14 @@ Compared to the verifyConditions, `analyzeCommits` lifecycle context has keys
 
 Additional keys:
 
-* `nextRelease`
-  * Similar object as `lastRelease` (see above)
-
+* `nextRelease` (Object)
+  * `type` (String)
+  * `channel` (String)
+  * `gitHead` (String, Git hash)
+  * `version` (String, version without `v`)
+  * `gitTag` (String, version with `v`)
+  * `name` (String)
+    
 #### generateNotes
 
 No new content in the context.
@@ -232,3 +237,30 @@ if (env.GITHUB_TOKEN) {
   //...
 }
 ```
+
+## Execution order
+
+For the lifecycles, the list at the top of the readme contains the order. If there are multiple plugins for the same lifecycle, then the order of the plugins determines the order in which they are executed.
+
+## Handling errors
+
+In order to be able to detect and handle errors properly, the errors thrown from the must be of type [SemanticReleaseError](https://github.com/semantic-release/error) or extend it as described in the package readme. This way the errors are handled properly and plugins using the `fail` lifecycle receive the errors correctly. For any other types of errors the internal error handling does nothing, lets them through up until the final catch and does not call any `fail` plugins.
+
+## Advanced
+
+Knowledge that might be useful for plugin developers.
+
+### Multiple analyzeCommits plugins
+
+While it may be trivial that multiple analyzeCommits (or any lifecycle plugins) can be defined, it is not that self-evident that the plugins executed AFTER the first one (for example, the default one: `commit-analyzer`) can change the result. This way it is possible to create more advanced rules or situations, e.g. if none of the commits would result in new release, then a default can be defined.
+
+The commit must be a known release type, for example the commit-analyzer has the following default types:
+* major
+* premajor
+* minor
+* preminor
+* patch
+* prepatch
+* prerelease
+
+If the analyzeCommits-lifecycle plugin does not return anything, then the earlier result is used, but if it returns a supported string value, then that overrides the previous result.

package/docs/extending/plugins-list.md

@@ -52,6 +52,9 @@
 - [semantic-release-docker](https://github.com/felixfbecker/semantic-release-docker)
   - `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry.
   - `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag
+- [@semantic-release-plus/docker](https://github.com/semantic-release-plus/semantic-release-plus/tree/master/packages/plugins/docker)
+  - `verifyConditions`: Verify that all needed configuration is present and login to the configured docker registry.
+  - `publish`: Tag the image specified by `name` with the new version, push it to the configured docker registry and update the `latest`, `major`, `minor` tags based on the configuration settings.
 - [semantic-release-gcr](https://github.com/carlos-cubas/semantic-release-gcr)
   - `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry
   - `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag
@@ -127,3 +130,13 @@
   - `verifyConditions`: Validate configuration and (if present) credentials
   - `prepare`: Update version and appVersion in ```Chart.yaml```
   - `publish`: Publish the chart to a registry (if configured)
+- [semantic-release-codeartifact](https://github.com/ryansonshine/semantic-release-codeartifact)
+  - `verifyConditions`: Validate configuration, get AWS CodeArtifact authentication and repository, validate `publishConfig` or `.npmrc` (if they exist), then pass the configuration to the associated plugins.
+- [semantic-release-telegram](https://github.com/pustovitDmytro/semantic-release-telegram)
+  - `verifyConditions`: Validate configuration and verify ```TELEGRAM_BOT_ID``` and ```TELEGRAM_BOT_TOKEN```
+  - `success`: Publish a message about the successful release to a telegram chat
+  - `fail`: publish a message about failure to a telegram chat
+- [semantic-release-heroku](https://github.com/pustovitDmytro/semantic-release-heroku)
+  - `verifyConditions`: Validate configuration and verify ```HEROKU_API_KEY```
+  - `prepare`: Update the package.json version and create release tarball
+  - `publish`: Publish version to heroku

package/docs/usage/workflow-configuration.md

@@ -162,7 +162,7 @@ With the configuration `"branches": ["1.0.x", "1.x", "master"]`, if the last rel
 ### Pre-release branches
 
 A pre-release branch is a type of branch used by **semantic-release** that allows to publish releases with a [pre-release version](https://semver.org/#spec-item-9).
-Using a pre-release version allow to publish multiple releases with the same version. Those release will be differentiated via there identifiers (in `1.0.0-alpha.1` the identifier is `alpha.1`).
+Using a pre-release version allow to publish multiple releases with the same version. Those release will be differentiated via their identifiers (in `1.0.0-alpha.1` the identifier is `alpha.1`).
 This is useful when you need to work on a future major release that will include many breaking changes but you do not want to increment the version number for each breaking change commit.
 
 A pre-release branch is characterized by the `prerelease` property that defines the static part of the version released (in `1.0.0-alpha.1` the static part fo the identifier is `alpha`). The [`prerelease`](#prerelease) value of each pre-release branch must be unique across the project.

package/lib/definitions/errors.js

@@ -60,7 +60,7 @@ Your configuration for the \`tagFormat\` option is \`${stringify(tagFormat)}\`.`
     message: `The \`${type}\` plugin configuration is invalid.`,
     details: `The [${type} plugin configuration](${linkify(`docs/usage/plugins.md#${toLower(type)}-plugin`)}) ${
       required ? 'is required and ' : ''
-    } must be a single or an array of plugins definition. A plugin definition is an npm module name, optionnaly wrapped in an array with an object.
+    } must be a single or an array of plugins definition. A plugin definition is an npm module name, optionally wrapped in an array with an object.
 
 Your configuration for the \`${type}\` plugin is \`${stringify(pluginConf)}\`.`,
   }),
@@ -68,7 +68,7 @@ Your configuration for the \`${type}\` plugin is \`${stringify(pluginConf)}\`.`,
     message: 'The `plugins` configuration is invalid.',
     details: `The [plugins](${linkify(
       'docs/usage/configuration.md#plugins'
-    )}) option must be an array of plugin definions. A plugin definition is an npm module name, optionnaly wrapped in an array with an object.
+    )}) option must be an array of plugin definions. A plugin definition is an npm module name, optionally wrapped in an array with an object.
 
 The invalid configuration is \`${stringify(plugin)}\`.`,
   }),

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "semantic-release",
   "description": "Automated semver compliant package publishing",
-  "version": "17.4.3",
+  "version": "17.4.4",
   "author": "Stephan Bönnemann <stephan@boennemann.me> (http://boennemann.me)",
   "ava": {
     "files": [
@@ -52,21 +52,21 @@
   "devDependencies": {
     "ava": "3.15.0",
     "clear-module": "4.1.1",
-    "codecov": "3.8.1",
+    "codecov": "3.8.2",
     "delay": "5.0.0",
-    "dockerode": "3.2.1",
+    "dockerode": "3.3.0",
     "file-url": "3.0.0",
-    "fs-extra": "9.1.0",
+    "fs-extra": "10.0.0",
     "got": "11.8.2",
     "js-yaml": "3.14.1",
     "mockserver-client": "5.11.2",
-    "nock": "13.0.11",
+    "nock": "13.1.0",
     "nyc": "15.1.0",
     "p-retry": "4.5.0",
     "proxyquire": "2.1.3",
-    "sinon": "9.2.4",
+    "sinon": "11.1.1",
     "stream-buffers": "3.0.2",
-    "tempy": "1.0.0",
+    "tempy": "1.0.1",
     "xo": "0.29.1"
   },
   "engines": {