Pierre Vanduynslager d0b304e240 feat: get last release with git tags
- Remove the `getLastRelease` plugin type
- Retrieve the last release based on Git tags
- Create the next release Git tag before calling the `publish` plugins

BREAKING CHANGE: Remove the `getLastRelease` plugin type

The `getLastRelease` plugins will not be called anymore.

BREAKING CHANGE: Git repository authentication is now mandatory

The Git authentication is now mandatory and must be set via `GH_TOKEN`, `GITHUB_TOKEN`,  `GL_TOKEN`, `GITLAB_TOKEN` or `GIT_CREDENTIALS` as described in [CI configuration](https://github.com/semantic-release/semantic-release/blob/caribou/docs/usage/ci-configuration.md#authentication).
2018-01-27 16:50:29 -05:00

3.8 KiB

Plugins

Each release steps is implemented within a plugin or a list of plugins that can be configured, allowing to support different commit message format, release not generator and publishing platforms.

Plugin types

verifyConditions plugin

Plugin responsible for verifying all the conditions to proceed with the release: configuration is correct, authentication token are valid, etc...

Default implementation: npm and github.

analyzeCommits plugin

Plugin responsible for determining the type of the next release (major, minor or patch).

Default implementation: @semantic-release/commit-analyzer.

verifyRelease plugin

Plugin responsible for verifying the parameters (version, type, dist-tag etc...) of the release that is about to be published match certain expectations. For example the cracks plugin allows to verify that if a release contains breaking changes, its type must be major.

Default implementation: none.

generateNotes plugin

Plugin responsible for generating release notes.

Default implementation: @semantic-release/release-notes-generator.

publish plugin

Plugin responsible for publishing the release.

Default implementation: npm and github.

Configuration

Plugin can be configured by specifying the plugin's module name or file path directly as a String or within the path key of an Object.

Plugins specific options can be set similarly to the other semantic-release options or within the plugin Object. Plugins options defined along the other semantic-release options will apply to all plugins, while the one defined within the plugin Object will apply only to this specific plugin.

For example:

{
  "release": {
    "verifyConditions": [
      {
        "path": "@semantic-release/exec",
        "cmd": "verify-conditions.sh"
      },
      "@semantic-release/npm",
      "@semantic-release/github"
    ],
    "analyzeCommits": "custom-plugin",
    "verifyRelease": [
      {
        "path": "@semantic-release/exec",
        "cmd": "verify-release.sh"
      },
    ],
    "generateNotes": "./build/my-plugin.js",
    "githubUrl": "https://my-ghe.com",
    "githubApiPathPrefix": "/api-prefix"
  }
}

With this configuration: