simon/semantic-release
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: various clarifications and language improvvements

Browse Source
This commit is contained in:
Pierre Vanduynslager 2019-08-22 14:20:34 -04:00
parent 9fd93ac37a
commit 6f33c76fde
5 changed files with 39 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/usage/ci-configuration.md
View File

@ -2,12 +2,22 @@
## Run `semantic-release` only after all tests succeeded ## Run `semantic-release` only after all tests succeeded
The `semantic-release` command must be executed only after all the tests in the CI build pass. If the build runs multiple jobs (for example to test on multiple Operating Systems or Node versions) the CI has to be configured to guarantee that the `semantic-release` command is executed only after all jobs are successful. This can be achieved with [Travis Build Stages](https://docs.travis-ci.com/user/build-stages), [CircleCI Workflows](https://circleci.com/docs/2.0/workflows), [Codeship Deployment Pipelines](https://documentation.codeship.com/basic/builds-and-configuration/deployment-pipelines), [GitLab Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html#introduction-to-pipelines-and-jobs), [Codefresh Pipelines](https://codefresh.io/docs/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines), [Wercker Workflows](http://devcenter.wercker.com/docs/workflows) or [GoCD Pipelines](https://docs.gocd.org/current/introduction/concepts_in_go.html#pipeline). The `semantic-release` command must be executed only after all the tests in the CI build pass. If the build runs multiple jobs (for example to test on multiple Operating Systems or Node versions) the CI has to be configured to guarantee that the `semantic-release` command is executed only after all jobs are successful.
Here is a few example of the CI services that can be used to achieve this:
- [Travis Build Stages](https://docs.travis-ci.com/user/build-stages)
- [CircleCI Workflows](https://circleci.com/docs/2.0/workflows)
- [Codeship Deployment Pipelines](https://documentation.codeship.com/basic/builds-and-configuration/deployment-pipelines)
- [GitLab Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html#introduction-to-pipelines-and-jobs)
- [Codefresh Pipelines](https://codefresh.io/docs/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines)
- [Wercker Workflows](http://devcenter.wercker.com/docs/workflows)
- [GoCD Pipelines](https://docs.gocd.org/current/introduction/concepts_in_go.html#pipeline).
See [CI configuration recipes](../recipes/README.md#ci-configurations) for more details. See [CI configuration recipes](../recipes/README.md#ci-configurations) for more details.
## Authentication ## Authentication
### Push access to the remote repository
**semantic-release** requires push access to the project Git repository in order to create [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging). The Git authentication can be set with one of the following environment variables: **semantic-release** requires push access to the project Git repository in order to create [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging). The Git authentication can be set with one of the following environment variables:
| Variable | Description | | Variable | Description |
@ -19,6 +29,8 @@ See [CI configuration recipes](../recipes/README.md#ci-configurations) for more
Alternatively the Git authentication can be set up via [SSH keys](../recipes/git-auth-ssh-keys.md). Alternatively the Git authentication can be set up via [SSH keys](../recipes/git-auth-ssh-keys.md).
### Authentication for plugins
Most **semantic-release** [plugins](plugins.md) require setting up authentication in order to publish to a package manager registry. The default [@semantic-release/npm](https://github.com/semantic-release/npm#environment-variables) and [@semantic-release/github](https://github.com/semantic-release/github#environment-variables) plugins require the following environment variables: Most **semantic-release** [plugins](plugins.md) require setting up authentication in order to publish to a package manager registry. The default [@semantic-release/npm](https://github.com/semantic-release/npm#environment-variables) and [@semantic-release/github](https://github.com/semantic-release/github#environment-variables) plugins require the following environment variables:
| Variable | Description | | Variable | Description |
@ -31,3 +43,5 @@ See each plugin's documentation for the environment variables required.
The authentication token/credentials have to be made available in the CI service via environment variables. The authentication token/credentials have to be made available in the CI service via environment variables.
See [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on how to configure environment variables in your CI service. See [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on how to configure environment variables in your CI service.
**Note**: The environment variables `GH_TOKEN`, `GITHUB_TOKEN`, `GL_TOKEN` and `GITLAB_TOKEN` can be used for both the Git authentication and the API authentication required by [@semantic-release/github](https://github.com/semantic-release/github) and [@semantic-release/gitlab](https://github.com/semantic-release/gitlab).

28
docs/usage/configuration.md
View File

@ -1,17 +1,17 @@
# Configuration # Configuration
**semantic-release** configuration consists of: **semantic-release** configuration consists of:
- Git repository options ([URL](#repositoryurl), [release branch](#branch) and [tag format](#tagformat)) - Git repository ([URL](#repositoryurl) and options [release branch](#branch) and [tag format](#tagformat))
- [plugins](#plugins) definition - Plugins [declaration](#plugins) and options
- run mode ([debug](#debug), [dry run](#dryrun) and [local (no CI)](#ci)) - Run mode ([debug](#debug), [dry run](#dryrun) and [local (no CI)](#ci))
All of these options can be configured directly or by extending a [shareable configuration](shareable-configurations.md). All of these options can be configured through config file, CLI arguments or by extending a [shareable configuration](shareable-configurations.md).
Additionally, metadata of Git tags generated by **semantic-release** can be customized via standard [Git environment variables](#git-environment-variables). Additionally, metadata of Git tags generated by **semantic-release** can be customized via standard [Git environment variables](#git-environment-variables).
## Configuration file ## Configuration file
**semantic-release**’s [options](#options), mode and [plugins](plugins.md) can be set via: **semantic-release**’s [options](#options), mode and [plugins](plugins.md) can be set via either:
- A `.releaserc` file, written in YAML or JSON, with optional extensions: .`yaml`/`.yml`/`.json`/`.js` - A `.releaserc` file, written in YAML or JSON, with optional extensions: .`yaml`/`.yml`/`.json`/`.js`
- A `release.config.js` file that exports an object - A `release.config.js` file that exports an object
- A `release` key in the project's `package.json` file - A `release` key in the project's `package.json` file
@ -20,8 +20,7 @@ Alternatively, some options can be set via CLI arguments.
The following three examples are the same. The following three examples are the same.
Via `release` key in the project's `package.json` file: - Via `release` key in the project's `package.json` file:
```json ```json
{ {
"release": { "release": {
@ -29,23 +28,15 @@ Via `release` key in the project's `package.json` file:
} }
} }
``` ```
```bash
$ semantic-release
```
Via `.releaserc` file:
- Via `.releaserc` file:
```json ```json
{ {
"branch": "next" "branch": "next"
} }
``` ```
```bash
$ semantic-release
```
Via CLI argument:
- Via CLI argument:
```bash ```bash
$ semantic-release --branch next $ semantic-release --branch next
``` ```
@ -146,7 +137,8 @@ Output debugging information. This can also be enabled by setting the `DEBUG` en
## Existing version tags ## Existing version tags
**semantic-release** uses [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging) to determine the commits added since the last release. If a release has been published before setting up **semantic-release** you must make sure the most recent commit included in the last published release is in the [release branch](#branch) history and is tagged with the version released, formatted according to the [tag format](#tagformat) configured (defaults to `vx.y.z`). **semantic-release** uses [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging) to determine the commits added since the last release.
If a release has been published before setting up **semantic-release** you must make sure the most recent commit included in the last published release is in the [release branch](#branch) history and is tagged with the version released, formatted according to the [tag format](#tagformat) configured (defaults to `vx.y.z`).
If the previous releases were published with [`npm publish`](https://docs.npmjs.com/cli/publish) this should already be the case. If the previous releases were published with [`npm publish`](https://docs.npmjs.com/cli/publish) this should already be the case.

8
docs/usage/getting-started.md
View File

@ -1,10 +1,10 @@
# Getting started # Getting started
In order to use **semantic-release** you must follow these steps: In order to use **semantic-release** you must follow these steps:
- [Install](./installation.md#installation) **semantic-release** in your project 1. [Install](./installation.md#installation) **semantic-release** in your project
- Configure your Continuous Integration service to [run **semantic-release**](./ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded) 2. Configure your Continuous Integration service to [run **semantic-release**](./ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded)
- Configure your Git repository and package manager repository [authentication](ci-configuration.md#authentication) in your Continuous Integration service 3. Configure your Git repository and package manager repository [authentication](ci-configuration.md#authentication) in your Continuous Integration service
- Configure **semantic-release** [options and plugins](./configuration.md#configuration) 4. Configure **semantic-release** [options and plugins](./configuration.md#configuration)
Alternatively those steps can be easily done with the [**semantic-release** interactive CLI](https://github.com/semantic-release/cli): Alternatively those steps can be easily done with the [**semantic-release** interactive CLI](https://github.com/semantic-release/cli):

4
docs/usage/installation.md
View File

@ -24,6 +24,6 @@ For other type of projects we recommend installing **semantic-release** directly
$ npx semantic-release $ npx semantic-release
``` ```
**Note:** For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with with `npx semantic-release@15`, or `npm install -g semantic-release@15`). This way your build will not automatically use the next major **semantic-release** release that could possibly break your build. You will have to upgrade manually when a new major version is released. **Note**: For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with with `npx semantic-release@15`). This way your build will not automatically use the next major **semantic-release** release that could possibly break your build. You will have to upgrade manually when a new major version is released.
**Note:** `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently install the semantic-release binary and to execute it. See [What is npx](../support/FAQ.md#what-is-npx) for more details. **Note**: `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently install the semantic-release binary and to execute it. See [What is npx](../support/FAQ.md#what-is-npx) for more details.

14
docs/usage/plugins.md
View File

@ -19,6 +19,8 @@ A plugin is a npm module that can implement one or more of the following steps:
## Plugins installation ## Plugins installation
### Default plugins
These four plugins are already part of **semantic-release** and don't have to be installed separately: These four plugins are already part of **semantic-release** and don't have to be installed separately:
``` ```
"@semantic-release/commit-analyzer" "@semantic-release/commit-analyzer"
@ -27,13 +29,15 @@ These four plugins are already part of **semantic-release** and don't have to be
"@semantic-release/release-notes-generator" "@semantic-release/release-notes-generator"
``` ```
### Additional plugins
[Additional plugins](../extending/plugins-list.md) have to be installed via npm: [Additional plugins](../extending/plugins-list.md) have to be installed via npm:
```bash ```bash
$ npm install @semantic-release/git @semantic-release/changelog -D $ npm install @semantic-release/git @semantic-release/changelog -D
``` ```
## Plugins configuration ## Plugins declaration and execution order
Each plugin must be configured with the [`plugins` options](./configuration.md#plugins) by specifying the list of plugins by npm module name. Each plugin must be configured with the [`plugins` options](./configuration.md#plugins) by specifying the list of plugins by npm module name.
@ -45,8 +49,6 @@ Each plugin must be configured with the [`plugins` options](./configuration.md#p
**Note:** If the `plugins` option is defined, it overrides the default plugin list, rather than merging with it. **Note:** If the `plugins` option is defined, it overrides the default plugin list, rather than merging with it.
## Plugin ordering
For each [release step](../../README.md#release-steps) the plugins that implement that step will be executed in the order in which they are defined. For each [release step](../../README.md#release-steps) the plugins that implement that step will be executed in the order in which they are defined.
```json ```json
@ -67,11 +69,11 @@ With this configuration **semantic-release** will:
- execute the `generateNotes` implementation of `@semantic-release/release-notes-generator` - execute the `generateNotes` implementation of `@semantic-release/release-notes-generator`
- execute the `publish` implementation of `@semantic-release/npm` - execute the `publish` implementation of `@semantic-release/npm`
## Plugin options ## Plugin options configuration
A plugin options can specified by wrapping the name and an options object in an array. Options configured this way will be passed only to that specific plugin. 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.
Global plugin options can defined at the root of the **semantic-release** configuration object. Options configured this way will be passed to all plugins. Global plugin configuration can be defined at the root of the **semantic-release** configuration object. Options configured this way will be passed to all plugins.
```json ```json
{ {