diff --git a/.gitignore b/.gitignore index fa6f8ca32a..058ab6905b 100644 --- a/.gitignore +++ b/.gitignore @@ -125,7 +125,9 @@ $RECYCLE.BIN/ # Windows shortcuts *.lnk -# End of https://www.gitignore.io/api/macos,windows,linux,node - +# Lockfiles package-lock.json yarn.lock + +# Gitbook +_book diff --git a/README.md b/README.md index 4b4b73c97c..0a3107b9d2 100644 --- a/README.md +++ b/README.md @@ -1,17 +1,34 @@ -# :package::rocket: semantic-release - -Fully automated version management and package publishing. - -[![Gitter](https://badges.gitter.im/semantic-release/semantic-release.svg)](https://gitter.im/semantic-release/semantic-release?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge) -[![Travis](https://img.shields.io/travis/semantic-release/semantic-release/caribou.svg)](https://travis-ci.org/semantic-release/semantic-release) -[![Codecov](https://img.shields.io/codecov/c/github/semantic-release/semantic-release/caribou.svg)](https://codecov.io/gh/semantic-release/semantic-release) -[![Greenkeeper badge](https://badges.greenkeeper.io/semantic-release/semantic-release.svg)](https://greenkeeper.io/) -[![semantic-release](https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg)](https://github.com/semantic-release/semantic-release) - -[![npm](https://img.shields.io/npm/v/semantic-release/latest.svg)](https://www.npmjs.com/package/semantic-release) -[![npm](https://img.shields.io/npm/v/semantic-release/next.svg)](https://www.npmjs.com/package/semantic-release) - -semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package. This removes the immediate connection between human emotions and version numbers, strictly following the [Semantic Versioning](http://semver.org) specification. +

📩🚀 semantic-release

+

Fully automated version management and package publishing

+

+ + Gitter + + + Travis + + + Codecov + + + Greenkeeper + + + semantic-release + +

+

+ + npm latest version + + + npm next version + +

+ +**semantic-release** automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package. + +This removes the immediate connection between human emotions and version numbers, strictly following the [Semantic Versioning](http://semver.org) specification. > Trust us, this will change your workflow for the better. – [egghead.io](https://egghead.io/lessons/javascript-how-to-write-a-javascript-library-automating-releases-with-semantic-release) @@ -23,30 +40,16 @@ semantic-release automates the whole package release workflow including: determi - Use formalized commit message convention to document changes in the codebase - Integrate with your [continuous integration workflow](docs/recipes/README.md#ci-configurations) - Avoid potential errors associated with manual releases -- Support any [package managers and languages](docs/recipes/README.md#package-managers-and-languages) via [plugins](#plugins) -- Simple and reusable configuration via [shareable configurations](#shareable-configurations) - -## Table of Contents - -- [How does it work?](#how-does-it-work) -- [Installation and Usage](#installation-and-usage) -- [Plugins](#plugins) -- [Shareable configurations](#shareable-configurations) -- [Recipes](#recipes) -- [Frequently Asked Questions](#frequently-asked-questions) -- [Resources](#resources) -- [Support](#support) -- [Badge](#badge) -- [Node Support Policy](#node-support-policy) -- [Team](#team) +- Support any [package managers and languages](docs/recipes/README.md#package-managers-and-languages) via [plugins](docs/usage/plugins.md) +- Simple and reusable configuration via [shareable configurations](docs/usage/shareable-configurations.md) ## How does it work? ### Commit message format -semantic-release uses the commit messages to determine the type of changes in the codebase. Following formalized conventions for commit messages, semantic-release automatically determines the next [semantic version](https://semver.org) number, generates a changelog and publish the release. +**semantic-release** uses the commit messages to determine the type of changes in the codebase. Following formalized conventions for commit messages, **semantic-release** automatically determines the next [semantic version](https://semver.org) number, generates a changelog and publish the release. -By default semantic-release uses [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines). The commit message format that can changed with the [`preset` or `config` options](#options) of the [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer#options) and [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator#options) plugins. +By default **semantic-release** uses [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines). The commit message format that can changed with the [`preset` or `config` options](docs/usage/configuration.md#options) of the [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer#options) and [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator#options) plugins. Tools such as [commitizen](https://github.com/commitizen/cz-cli), [commitlint](https://github.com/marionebl/commitlint) or [semantic-git-commit-cli](https://github.com/JPeer264/node-semantic-git-commit-cli) can be used to help contributor and enforce valid commits message. @@ -60,7 +63,7 @@ Here is an example of the release type that will be done based on a commit messa ### Automation with CI -semantic-release is meant to be executed on the CI environment after every successful build on the release branch. This way no human is directly involved in the release process and the releases are guaranteed to be [unromantic and unsentimental](http://sentimentalversioning.org). +**semantic-release** is meant to be executed on the CI environment after every successful build on the release branch. This way no human is directly involved in the release process and the releases are guaranteed to be [unromantic and unsentimental](http://sentimentalversioning.org). ### Triggering a release @@ -68,533 +71,49 @@ When pushing new commits to the release branch (i.e. `master`) with `git push` o By default a release will be done for each push to the release branch that contains relevant code changes. If you need more control over the timing of releases you have a couple of options: - Publish releases on a distribution channel (for example npm’s [dist-tags](https://docs.npmjs.com/cli/dist-tag)). This way you can keep control over what your users end up using by default, and you can decide when to make an automatically released version available to the stable channel, and promote it. -- Develop on a `dev` branch and merge it to the release branch (i.e. `master`) once you are ready to publish. semantic-release will run only on pushes to the release branch. +- Develop on a `dev` branch and merge it to the release branch (i.e. `master`) once you are ready to publish. **semantic-release** will run only on pushes to the release branch. ### Release steps After running the tests the command `semantic-release` will execute the following steps: -| Step | Description | -|-------------------|--------------------------------------------------------------------------------------------------------------------------------------------------| -| Verify Conditions | Verify all the conditions to proceed with the release with the [verify conditions plugins](#verifyconditions-plugin). | -| Get last release | Obtain last release with the [get last release plugin](#getlastrelease-plugin). | -| Analyze commits | Determine the type of release to do with the [analyze commits plugin](#analyzecommits-plugin) based on the commits added since the last release. | -| Verify release | Verify the release conformity with the [verify release plugins](#verifyrelease-plugin). | -| Generate notes | Generate release notes with the [generate notes plugin](#generatenotes-plugin) for the commits added since the last release. | -| Publish | Publish the release with the [publish plugins](#publish-plugin). | - -## Installation and Usage - -### Local installation - -For [Node modules projects](https://docs.npmjs.com/getting-started/creating-node-modules) we recommend to install semantic-release locally and to run the `semantic-release` command with a [npm script](https://docs.npmjs.com/misc/scripts): - -```bash -$ npm install --save-dev semantic-release -``` - -In your `package.json`: - -```json -"scripts": { - "semantic-release": "semantic-release" -} -``` - -Then in the CI environment: - -```bash -$ npm run semantic-release -``` - -### Global installation - -For other type of projects we recommend to install semantic-release globally directly in the CI environment: - -```bash -$ npm install -g semantic-release -$ semantic-release -``` - -### CI configuration - -#### 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), [Wercker Workflows](http://devcenter.wercker.com/docs/workflows), [GoCD Pipelines](https://docs.gocd.org/current/introduction/concepts_in_go.html#pipeline) or specific tools like [`travis-deploy-once`](https://github.com/semantic-release/travis-deploy-once). - -See [CI configuration recipes](docs/recipes/README.md#ci-configurations) for more details. - -#### Authentication - -Most semantic-release [plugins](#plugins) require to set up authentication in order to publish to your package manager's registry or to access your project's Git hosted service. The authentication token/credentials have to be made available in the CI serice via environment variables. - -See each plugin documentation for the environment variable to set up. - -The default [npm](https://github.com/semantic-release/npm#environment-variables) and [github](https://github.com/semantic-release/github#environment-variables) plugins require the following environment variables: - -| Variable | Description | -|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `NPM_TOKEN` | npm token created via [npm token create](https://docs.npmjs.com/getting-started/working_with_tokens#how-to-create-new-tokens).
**Note**: Only the `auth-only` [level of npm two-factor authentication](https://docs.npmjs.com/getting-started/using-two-factor-authentication#levels-of-authentication) is supported. | -| `GH_TOKEN` | GitHub authentication token.
**Note**: Only the [personal token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line) authentication is supported. | - -See [CI configuration recipes](docs/recipes/README.md#ci-configurations) for more details on how to configure environment variables in your CI service. - -### Automatic setup with `semantic-release-cli` - -[`semantic-release-cli`](https://github.com/semantic-release/cli) allow to easily [install](#installation-and-usage) semantic-release in your Node project and set up the [CI configuration](#ci-configuration): - -```bash -npm install -g semantic-release-cli - -cd your-module -semantic-release-cli setup -``` - -![dialogue](media/semantic-release-cli.png) - -See the [semantic-release-cli](https://github.com/semantic-release/cli#what-it-does) documentation for more details. - -### Configuration - -In order to customize semantic-release’s behavior, [options](#options) and [plugins](#plugins) can be set via: -- 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` key in the project's `package.json` file -- CLI arguments - -The following two examples are the same. - -Via CLI argument: - -```bash -$ semantic-release --branch next -``` - -Via `release` key in the project's `package.json` file: - -```json -"release": { - "branch": "next" -} -``` -```bash -$ semantic-release -``` - -**Note**: CLI arguments take precedence over options configured in the configuration file. - -**Note**: Plugins options cannot be defined via CLI arguments and must be defined in the configuration file. - -### Options - -#### extends - -Type: `Array`, `String` - -CLI arguments: `-e`, `--extends` - -List of modules or file paths containing a [shareable configuration](#shareable-configurations). If multiple shareable configuration are set, they will be imported in the order defined with each configuration option taking precedence over the options defined in a previous shareable configuration. - -**Note**: Options defined via CLI arguments or in the configuration file will take precedence over the ones defined in any shareable configuration. - -#### branch - -Type: `String` - -Default: `master` - -CLI arguments: `-b`, `--branch` - -The branch on which releases should happen. - -#### repositoryUrl - -Type: `String` - -Default: `repository` property in `package.json` or [git origin url](https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes) - -CLI arguments: `-r`, `--repository-url` - -The git repository URL - -Any valid git url format is supported (See [Git protocols](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols)). - -**Note**: If the [Github plugin](https://github.com/semantic-release/github) is used the URL must be a valid Github URL that include the `owner`, the `repository` name and the `host`. **The Github shorthand URL is not supported.** - -#### dryRun - -Type: `Boolean` - -Default: `false` if running in a CI environment, `false` otherwise - -CLI arguments: `-d`, `--dry-run` - -Dry-run mode, skip publishing, print next version and release notes. - -#### noCi - -Type: `Boolean` - -Default: `false` - -CLI arguments: `--no-ci` - -Skip Continuous Integration environment verifications, allowing to make releases from a local machine. - -#### debug - -Type: `Boolean` - -Default: `false` - -CLI argument: `--debug` - -Output debugging information. It can also be enabled by set the `DEBUG` environment variable to `semantic-release`. - -#### verifyConditions - -Type: `Array`, `String`, `Object` - -Default: `['@semantic-release/npm', '@semantic-release/github']` - -CLI argument: `--verify-conditions` - -Define the list of [verify conditions plugins](#verifyconditions-plugin). Plugins will run in series, in the order defined in the `Array`. - -See [Plugins configuration](#plugins-configuration) for more details. - -#### getLastRelease - -Type: `String`, `Object` - -Default: `['@semantic-release/npm']` - -CLI argument: `--get-last-release` - -Define the [get last release plugin](#getlastrelease-plugin). - -See [Plugins configuration](#plugins-configuration) for more details. - -#### analyzeCommits - -Type: `String`, `Object` - -Default: `['@semantic-release/commit-analyzer']` - -CLI argument: `--analyze-commits` - -Define the [analyze commits plugin](#analyzecommits-plugin). - -See [Plugins configuration](#plugins-configuration) for more details. - -#### verifyRelease - -Type: `Array`, `String`, `Object` - -Default: `[]` - -CLI argument: `--verify-release` - -Define the list of [verify release plugins](#verifyrelease-plugin). Plugins will run in series, in the order defined in the `Array`. - -See [Plugins configuration](#plugins-configuration) for more details. - -#### generateNotes - -Type: `String`, `Object` - -Default: `['@semantic-release/release-notes-generator']` - -CLI argument: `--generate-notes` - -Define the [generate notes plugin](#generatenotes-plugin). - -See [Plugins configuration](#plugins-configuration) for more details. - -#### publish - -Type: `Array`, `String`, `Object` - -Default: `['@semantic-release/npm', '@semantic-release/github']` - -CLI argument: `--publish` - -Define the list of [publish plugins](#publish-plugin). Plugins will run in series, in the order defined in the `Array`. - -See [Plugins configuration](#plugins-configuration) for more details. - -## Plugins - -Each [release steps](#release-steps) is implemented within a plugin or a list of plugins that can be configured, allowing to support different [commit message format](#commit-message-format), release not generator and publishing platforms. - -See [List of semantic-release plugins](docs/plugins.md#semantic-release-plugins). - -See [Plugin developer Guide](docs/developer-guide/plugin.md#semantic-release-plugin-development) for more information on how to develop a plugin. - -### 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](https://github.com/semantic-release/npm#verifyconditions) and [github](https://github.com/semantic-release/github#verifyconditions). - -#### getLastRelease plugin - -Plugin responsible for determining the version of the package last release. - -Default implementation: [@semantic-release/npm](https://github.com/semantic-release/npm#getlastrelease). - -#### analyzeCommits plugin - -Plugin responsible for determining the type of the next release (`major`, `minor` or `patch`). - -Default implementation: [@semantic-release/commit-analyzer](https://github.com/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](https://github.com/semantic-release/cracks) 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](https://github.com/semantic-release/release-notes-generator). - -#### publish plugin - -Plugin responsible for publishing the release. - -Default implementation: [npm](https://github.com/semantic-release/npm#publish) and [github](https://github.com/semantic-release/github#publish). - -### Plugins 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](#options) or within the plugin `Object`. Plugins options defined along the other semantic-release [options](#options) will apply to all plugins, while the one defined within the plugin `Object` will apply only to this specific plugin. - -For example: -```json -{ - "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: -- the `custom-plugin` npm module will be used to [analyze commits](#analyzecommits-plugin) -- the `./build/my-plugin.js` script will be used to [generate release notes](#generatenotes-plugin) -- the [`@semantic-release/exec`](https://github.com/semantic-release/exec), [`@semantic-release/npm`](https://github.com/semantic-release/npm) and [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugins will be used to [verify conditions](#verifyconditions-plugin) -- the [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin will be used to [verify the release](#verifyrelease-plugin) -- the `cmd` option will be set to `verify-conditions.sh` only for the [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin used to [verify conditions](#verifyconditions-plugin) -- the `cmd` option will be set to `verify-release.sh` only for the [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin used to [verify the release](#verifyrelease-plugin) -- the `githubUrl` and `githubApiPathPrefix` options will be set to respectively `https://my-ghe.com` and `/api-prefix` for all plugins - -## Shareable configurations - -A sharable configuration is an [npm](https://www.npmjs.com/) package that exports a semantic-release configuration object. It allows to easily use the same configuration across several projects. - -The shareable configurations to use can be set with the [extends](#extends) option. - -See [List of semantic-release shareable configuration](docs/shareable-configurations.md#semantic-release-shareable-configurations). - -See [Shareable configuration developer Guide](docs/developer-guide/shareable-configuration.md#semantic-release-shareable-config-development) for more information on how to develop a shareable configuration. - -## Recipes - -- [CI configurations](docs/recipes/README.md#ci-configurations) -- [Package managers and languages](docs/recipes/README.md#package-managers-and-languages) - -## Frequently Asked Questions - -### Why is the `package.json`’s version not updated in my repository? - -semantic-release takes care of updating the `package.json`’s version before publishing to [npm](https://www.npmjs.com). - -By default, only the published package will contains the version, which is the only place where it is *really* required, but the updated `package.json` will not be pushed to the Git repository - -However, the [`@semantic-release/git`](https://github.com/semantic-release/git) plugin can be used to push the updated `package.json` as well as other files to the Git repository. - -### How can I use a npm build script that requires the `package.json`’s version ? - -The `package.json`’s version will be updated by the `semantic-release` command just before publishing to [npm](https://www.npmjs.com), therefore it won't be available for scripts ran before the `semantic-release` command. - -As semantic-release uses the [npm CLI](https://docs.npmjs.com/cli/npm) to publish, all [npm hook scripts](https://docs.npmjs.com/misc/scripts#hook-scripts) will be executed. Therefore you can run your build script in the [`prepublishOnly`](https://docs.npmjs.com/misc/scripts#prepublish-and-prepare) hook. It will be executed after the `semantic-release` command update the `package.json`’s version and before publishing. - -### Is there a way to preview which version would currently get published? - -Yes with the [dry-run options](#dryrun) which prints to the console the next version to be published and the release notes. - -### Can I use semantic-release with Yarn? - -If you are using a [local semantic-release installation](#local-installation) and run multiple CI jobs with different versions, the `yarn install` command will fail with Node < 8 as semantic-release require [Node >= 8](#why-does-semantic-release-require-node-version--8). See [yarnpkg/rfcs#69](https://github.com/yarnpkg/rfcs/pull/69). - -In order to run semantic-release with [Yarn](https://yarnpkg.com) you would need to: -- Use a [global semantic-release installation](#global-installation) -- Make sure to install and run the `semantic-release` command only in a CI jobs running with [Node >= 8](#why-does-semantic-release-require-node-version--8) - -If your CI environment provides [nvm](https://github.com/creationix/nvm) you can switch to Node 8 before installing and running the `semantic-release` command: - -```bash -$ nvm install 8 && yarn install -g semantic-release && semantic-release -``` - -See the [CI configuration recipes](docs/recipes/README.md#ci-configurations) for more details on specific CI environments. - -### Can I use semantic-release to publish non-JavaScript packages? - -Yes, semantic-release is a Node CLI application but it can be used to publish any type of packages. - -To publish a non-JavaScript package you would need to: -- Use a [global semantic-release installation](#global-installation) -- Set [semantic-release options](#options) via [CLI arguments or rc file](#configuration) -- Make sure your CI job executing the `semantic-release` command has access to [Node >= 8](#why-does-semantic-release-require-node-version--8) to execute the `semantic-release` command - -See the [CI configuration recipes](docs/recipes/README.md#ci-configurations) for more details on specific CI environments. - -### Can I use semantic-release with any CI service? - -Yes, semantic-release can be used with any CI service, as long as it provides: -- A way to set [authentication](#authentication) via environment variables -- A way to guarantee that the `semantic-release` command is [executed only after all the tests of all the jobs in the CI build pass](#run-semantic-release-only-after-all-tests-succeeded) - -See the [CI configuration recipes](docs/recipes/README.md#ci-configurations) for more details on specific CI environments. - -### Can I run semantic-release on my local machine rather than on a CI server? - -Yes, you can by explicitly setting the [`--no-ci` CLI option](#options) option. You will also have to set the required [authentication](#authentication) via environment variables on your local machine, for example: - -```bash -$ NPM_TOKEN= GH_TOKEN= npm run semantic-release --no-ci -``` - -However this is not the recommended approach, as running unit and integration tests on an independent machine before publishing software is a crucial part of the release workflow. - -### Can I use semantic-release with GitLab? - -Yes, with the [`@semantic-release/gitlab-config`](https://github.com/semantic-release/gitlab-config) shareable configuration. - -See the [GitLab CI recipes](docs/recipes/gitlab-ci.md#using-semantic-release-with-gitlab-ci) for the CI configuration. - -### Can I use semantic-release with any Git hosted environment? - -By default semantic-release uses the [`@semantic-release/github`](https://github.com/semantic-release/github) plugin to publish a [GitHub release](https://help.github.com/articles/about-releases). For other Git hosted environment the [`@semantic-release/git`](https://github.com/semantic-release/git) and [`@semantic-release/changelog`](https://github.com/semantic-release/changelog) plugins can be used via [plugins configuration](#plugins-configuration). - -See the [`@semantic-release/git`](https://github.com/semantic-release/git#semantic-releasegit) [`@semantic-release/changelog`](https://github.com/semantic-release/changelog#semantic-releasechangelog) plugins documentation for more details. - -### Can I skip the release to the npm registry? - -Yes, the publishing to the npm registry can be disabled with the [`npmPublish`](https://github.com/semantic-release/npm#options) option of the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin. In addition the [`tarballDir`](https://github.com/semantic-release/npm#options) option allow to generate the package tarball in order to publish it to your repository with the [`@semantic-release/git`](https://github.com/semantic-release/git) or to a [GitHub release](https://help.github.com/articles/about-releases) with the [`@semantic-release/github`](https://github.com/semantic-release/github) plugin. - -See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#semantic-releasenpm) plugin documentation for more details. - -### Can I use `.npmrc` options? - -Yes, all the [npm configuration options](https://docs.npmjs.com/misc/config) are supported via the [`.npmrc`](https://docs.npmjs.com/files/npmrc) file at the root of your repository. - -See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#npm-configuration) plugin documentation for more details. - -### How can I set the access level of the published npm package? - -The [npm `access` option](https://docs.npmjs.com/misc/config#access) can be set in the [`.npmrc`](https://docs.npmjs.com/files/npmrc) file at the root of your repository: - -```rc -access=public -``` - -Or with the `publishConfig.access` key in your project's `package.json`: - -```json -{ - "publishConfig": { - "access": "public" - } -} -``` - -### Can I use semantic-release to publish a package on Artifactory? - -Any npm compatible registry is supported with the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin. For Artifactory versions prior to 5.4, the legacy authentication has to be used (with `NPM_USERNAME`, `NPM_PASSWORD` and `NPM_EMAIL` [environment variables](https://github.com/semantic-release/npm#environment-variables)). - -See [npm registry authentication](https://github.com/semantic-release/npm#npm-registry-authentication) for more details. - -See [Artifactory - npm Registry](https://www.jfrog.com/confluence/display/RTF/Npm+Registry#NpmRegistry-AuthenticatingthenpmClient) documentation for Artifactiry configuration. - -### Can I manually trigger the release of a specific version? - -You can trigger a release by pushing to your Git repository. You deliberately cannot trigger a *specific* version release, because this is the whole point of semantic-release. - -### Is it *really* a good idea to release on every push? - -It is indeed a great idea because it *forces* you to follow best practices. If you don’t feel comfortable releasing every feature or fix on your `master` you might not treat your `master` branch as intended. - -From [Understanding the GitHub Flow](https://guides.github.com/introduction/flow/index.html): - -> Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There's only one rule: anything in the master branch is always deployable. - -If you need more control over the timing of releases, see [Triggering a release](#triggering-a-release) for different options. - -### Can I set the initial release version of my package to `0.0.1`? - -This is not supported by semantic-release as it's not considered a good practice, mostly because [Semantic Versioning](https://semver.org) rules applies differently to major version zero. - -In early development phase when your package is not ready for production yet we recommend to publish releases on a distribution channel (for example npm’s [dist-tags](https://docs.npmjs.com/cli/dist-tag)) or to develop on a `dev` branch and merge it to `master` periodically. See [Triggering a release](#triggering-a-release) for more details on those solutions. - -See [“Introduction to SemVer” - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2) for more details on [Semantic Versioning](https://semver.org) and the recommendation to start at version `1.0.0`. - -### Can I trust semantic-release with my releases? - -semantic-release has a full unit and integration test suite that tests `npm` publishes against the [npm-registry-couchapp](https://github.com/npm/npm-registry-couchapp). - -In addition the [verify conditions step](#release-steps) verifies that all necessary conditions for proceeding with a release are met, and a new release will be performed [only if all your tests pass](#run-semantic-release-only-after-all-tests-succeeded). - -### Why does semantic-release require Node version >= 8? - -semantic-release is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which **requires Node version 8 or higher**. - -See [Node version requirement](docs/node-version.md#node-version-requirement) for more details and solutions. - -## Resources - -### Videos - -- ["Introducing Reliable Dependency and Release Management for npm Packages" - Gregor Martynus](https://www.youtube.com/watch?v=R2RJWLcfzwc) -- ["Kill all humans" - Jan Lehnardt](https://www.youtube.com/watch?v=ZXyx_1kN1L8&t=2s) -- [Publishing JavaScript Packages" - JavaScript Air](https://javascriptair.com/episodes/2016-07-20) -- ["Managing Dependencies like a boss 😎" - JavaScript Air](https://javascriptair.com/episodes/2016-08-17) -- ["Dependency Hell Just Froze Over" - Stephan Bönnemann](https://www.youtube.com/watch?v=PA139CERNbc) -- [“semantic-release Q&A with Kent C. Dodds”](https://www.youtube.com/watch?v=g6y3DnhkjrI) -- [“We fail to follow SemVer – and why it needn’t matter” - Stephan Bönnemann](https://www.youtube.com/watch?v=tc2UgG5L7WM) - -### Articles - -- [“Introduction to SemVer” - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2) - -### Tutorials - -- [“How to Write a JavaScript Library - Automating Releases with semantic-release” – egghead.io](https://egghead.io/lessons/javascript-automating-releases-with-semantic-release) - -## Support +| Step | Description | +|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Verify Conditions | Verify all the conditions to proceed with the release with the [verify conditions plugins](docs/usage/plugins.md#verifyconditions-plugin). | +| Get last release | Obtain last release with the [get last release plugin](docs/usage/plugins.md#getlastrelease-plugin). | +| Analyze commits | Determine the type of release to do with the [analyze commits plugin](docs/usage/plugins.md#analyzecommits-plugin) based on the commits added since the last release. | +| Verify release | Verify the release conformity with the [verify release plugins](docs/usage/plugins.md#verifyrelease-plugin). | +| Generate notes | Generate release notes with the [generate notes plugin](docs/usage/plugins.md#generatenotes-plugin) for the commits added since the last release. | +| Publish | Publish the release with the [publish plugins](docs/usage/plugins.md#publish-plugin). | + +## Documentation + +- Usage + - [Installation](docs/usage/installation.md#installation) + - [CI Configuration](docs/usage/ci-configuration.md#ci-configuration) + - [Configuration](docs/usage/configuration.md#configuration) + - [Plugins](docs/usage/plugins.md) + - [Shareable configurations](docs/usage/shareable-configurations.md) +- Extending + - [Plugins](docs/extending/plugins-list.md) + - [Shareable configuration](docs/extending/shareable-configurations-list.md) +- Recipes + - [CI configurations](docs/recipes/README.md) + - [Package managers and languages](docs/recipes/README.md) +- Developer guide + - [Plugins](docs/developer-guide/plugin.md) + - [Shareable configuration](docs/developer-guide/shareable-configuration.md) +- Resources + - [Videos](docs/resources.md#videos) + - [Articles](docs/resources.md#articles) + - [Tutorials](docs/resources.md#tutorials) +- Support + - [Frequently Asked Questions](docs/support/FAQ.md) + - [Troubleshooting](docs/support/troubleshooting.md) + - [Node version requirement](docs/support/node-version.md) + - [Node Support Policy](docs/support/node-support-policy.md) + +## Get help - [Stack Overflow](https://stackoverflow.com/questions/tagged/semantic-release) - [Gitter chat](https://gitter.im/semantic-release/semantic-release) @@ -602,7 +121,7 @@ See [Node version requirement](docs/node-version.md#node-version-requirement) fo ## Badge -Let people know that your package is published using semantic-release by including this badge in your readme. +Let people know that your package is published using **semantic-release** by including this badge in your readme. [![semantic-release](https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg)](https://github.com/semantic-release/semantic-release) @@ -610,24 +129,12 @@ Let people know that your package is published using semantic-release by includi [![semantic-release](https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg)](https://github.com/semantic-release/semantic-release) ``` -## Node Support Policy - -We only support [Long-Term Support](https://github.com/nodejs/Release) versions of Node starting with [Node 8.9.0 (LTS)](https://nodejs.org/en/blog/release/v8.9.0). - -We specifically limit our support to LTS versions of Node, not because this package won't work on other versions, but because we have a limited amount of time, and supporting LTS offers the greatest return on that investment. - -It's possible this package will work correctly on newer versions of Node. It may even be possible to use this package on older versions of Node, though that's more unlikely as we'll make every effort to take advantage of features available in the oldest LTS version we support. - -As each Node LTS version reaches its end-of-life we will remove that version from the node engines property of our package's package.json file. Removing a Node version is considered a breaking change and will entail the publishing of a new major version of this package. We will not accept any requests to support an end-of-life version of Node. Any merge requests or issues supporting an end-of-life version of Node will be closed. - -We will accept code that allows this package to run on newer, non-LTS, versions of Node. Furthermore, we will attempt to ensure our own changes work on the latest version of Node. To help in that commitment, our continuous integration setup runs against all LTS versions of Node in addition the most recent Node release; called current. - -JavaScript package managers should allow you to install this package with any version of Node, with, at most, a warning if your version of Node does not fall within the range specified by our node engines property. If you encounter issues installing this package, please report the issue to your package manager. - ## Team | [![Stephan Bönnemann](https://github.com/boennemann.png?size=100)](https://github.com/boennemann) | [![Rolf Erik Lekang](https://github.com/relekang.png?size=100)](https://github.com/relekang) | [![Johannes Jörg Schmidt](https://github.com/jo.png?size=100)](https://github.com/jo) | [![Gregor Martynus](https://github.com/gr2m.png?size=100)](https://github.com/gr2m) | [![Pierre Vanduynslager](https://github.com/finnp.png?size=100)](https://github.com/finnp) | [![Pierre Vanduynslager](https://github.com/pvdlg.png?size=100)](https://github.com/pvdlg) | [![Christoph Witzko](https://github.com/christophwitzko.png?size=100)](https://github.com/christophwitzko) | |---------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------| | [Stephan Bönnemann](https://github.com/boennemann) | [Rolf Erik Lekang](https://github.com/relekang) | [Johannes Jörg Schmidt](https://github.com/jo) | [Gregor Martynus](https://github.com/gr2m) | [Finn Pauls](https://github.com/finnp) | [Pierre Vanduynslager](https://github.com/pvdlg) | [Christoph Witzko](https://github.com/christophwitzko) | -[![](https://cloud.githubusercontent.com/assets/908178/6091690/cc86f58c-aeb8-11e4-94cb-15f15f486cde.png)](https://twitter.com/trodrigues/status/509301317467373571) +

+ Kill all humans +

diff --git a/SUMMARY.md b/SUMMARY.md new file mode 100644 index 0000000000..8f20c5d31d --- /dev/null +++ b/SUMMARY.md @@ -0,0 +1,39 @@ +# Summary + +## About +- [Highlights](README.md#highlights) +- [How does it work?](README.md#how-does-it-work) + +## Usage +- [Installation](docs/usage/installation.md#installation) +- [CI Configuration](docs/usage/ci-configuration.md#ci-configuration) +- [Configuration](docs/usage/configuration.md#configuration) +- [Plugins](docs/usage/plugins.md) +- [Shareable configurations](docs/usage/shareable-configurations.md) + +## Extending +- [Plugins](docs/extending/plugins-list.md) +- [Shareable configuration](docs/extending/shareable-configurations-list.md) + +## Recipes +- [CI configurations](docs/recipes/README.md) + - [CircleCI 2.0 workflows](docs/recipes/circleci-workflows.md) + - [Travis CI](docs/recipes/travis.md) + - [Travis CI with build stages](docs/recipes/travis-build-stages.md) + - [GitLab CI](docs/recipes/gitlab-ci.md) +- [Package managers and languages](docs/recipes/README.md) + +## Developer guide +- [Plugin](docs/developer-guide/plugin.md) +- [Shareable configuration](docs/developer-guide/shareable-configuration.md) + +## Resources +- [Videos](docs/resources.md#videos) +- [Articles](docs/resources.md#articles) +- [Tutorials](docs/resources.md#tutorials) + +## Support +- [Frequently Asked Questions](docs/support/FAQ.md) +- [Troubleshooting](docs/support/troubleshooting.md) +- [Node version requirement](docs/support/node-version.md) +- [Node Support Policy](docs/support/node-support-policy.md) diff --git a/bin/semantic-release.js b/bin/semantic-release.js index 8e6f606ef2..0502490816 100755 --- a/bin/semantic-release.js +++ b/bin/semantic-release.js @@ -12,7 +12,7 @@ if (!semver.satisfies(process.version, pkg.engines.node)) { console.error( `[semantic-release]: node version ${pkg.engines.node} is required. Found ${process.version}. -See https://github.com/semantic-release/semantic-release/blob/caribou/docs/node-version.md for more details and solutions.` +See https://github.com/semantic-release/semantic-release/blob/caribou/docs/support/node-version.md for more details and solutions.` ); process.exit(1); } diff --git a/book.json b/book.json new file mode 100644 index 0000000000..dd3c652e87 --- /dev/null +++ b/book.json @@ -0,0 +1,8 @@ +{ + "plugins" : ["github"], + "pluginsConfig": { + "github": { + "url": "https://github.com/semantic-release/semantic-release" + } + } +} diff --git a/docs/README.md b/docs/README.md index 01bb606816..b2189449f8 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,7 +1,8 @@ # semantic-release documentation -- [Plugins](plugins.md#semantic-release-plugins) - List of semantic-release plugins -- [Shareable configurations](shareable-configurations.md#semantic-release-shareable-configurations) - List of semantic-release shareable configs -- [Developer Guide](developer-guide/README.md#semantic-release-developer-guide) - The essentials of writing a semantic-release plugin or shareable config -- [Recipes](recipes/README.md#semantic-release-recipes) - Community written recipes for common semantic-release use-cases -- [Troubleshooting](troubleshooting.md#troubleshooting-semantic-release) - Community written troubleshooting guide to help with common semantic-release issues +- [Usage](usage/README.md) - **semantic-release** installation and configuration +- [Extending][extending/README.md]- Extending **semantic-release** with plugins and shareable configurations +- [Recipes](recipes/README.md) - Community written recipes for common **semantic-release** use-cases +- [Developer Guide](developer-guide/README.md) - The essentials of writing a **semantic-release** plugin or shareable configurations +- [Resources](resources.md) - Videos, articles and tutorials +- [Support](support/README.md) - FAQ and troubleshooting diff --git a/docs/developer-guide/README.md b/docs/developer-guide/README.md index e795865ba5..afd97c5de6 100644 --- a/docs/developer-guide/README.md +++ b/docs/developer-guide/README.md @@ -1 +1,4 @@ -# semantic-release Developer Guide +# Developer guide + +- [Plugins](plugin.md) +- [Shareable configuration](shareable-configuration.md) diff --git a/docs/developer-guide/plugin.md b/docs/developer-guide/plugin.md index c3ff79ed9e..1fd31e5ea9 100644 --- a/docs/developer-guide/plugin.md +++ b/docs/developer-guide/plugin.md @@ -1 +1 @@ -# semantic-release plugin development +# Plugin developer guide diff --git a/docs/developer-guide/shareable-configuration.md b/docs/developer-guide/shareable-configuration.md index 6aa0db8cb2..e38eecf83e 100644 --- a/docs/developer-guide/shareable-configuration.md +++ b/docs/developer-guide/shareable-configuration.md @@ -1 +1 @@ -# semantic-release shareable config development +# Shareable configuration developer guide diff --git a/docs/extending/README.md b/docs/extending/README.md new file mode 100644 index 0000000000..2ccdc147bc --- /dev/null +++ b/docs/extending/README.md @@ -0,0 +1,4 @@ +# Extending semantic-release + +- [Plugins list](plugins-list.md) +- [Shareable configuration list](shareable-configurations-list.md) diff --git a/docs/extending/plugins-list.md b/docs/extending/plugins-list.md new file mode 100644 index 0000000000..6886758b75 --- /dev/null +++ b/docs/extending/plugins-list.md @@ -0,0 +1,33 @@ +# Plugins list + +## Default plugins + +- [@semantic-release/github](https://github.com/semantic-release/github) + - [verifyConditions](https://github.com/semantic-release/github#verifyconditions): Verify the presence and the validity of the GitHub authentication and release configuration + - [publish](https://github.com/semantic-release/github#publish): Publish a [GitHub release](https://help.github.com/articles/about-releases) +- [@semantic-release/npm](https://github.com/semantic-release/npm) + - [verifyConditions](https://github.com/semantic-release/npm#verifyconditions): Verify the presence and the validity of the npm authentication and release configuration + - [getLastRelease](https://github.com/semantic-release/npm#getlastrelease): Determine the last release of the package on the npm registry + - [publish](https://github.com/semantic-release/npm#publish): Publish the package on the npm registry + +## Official plugins + +- [@semantic-release/gitlab](https://github.com/semantic-release/gitlab) + - [verifyConditions](https://github.com/semantic-release/gitlab#verifyconditions): Verify the presence and the validity of the GitLab authentication and release configuration + - [publish](https://github.com/semantic-release/gitlab#publish): Publish a [GitLab release](https://docs.gitlab.com/ce/workflow/releases.html) +- [@semantic-release/git](https://github.com/semantic-release/git) + - [verifyConditions](https://github.com/semantic-release/git#verifyconditions): Verify the presence and the validity of the Git authentication and release configuration + - [getLastRelease](https://github.com/semantic-release/git#getlastrelease): Determine the last release via Git tags on the repository + - [publish](https://github.com/semantic-release/git#publish): Push a release commit and tag, including configurable files +- [@semantic-release/changelog](https://github.com/semantic-release/changelog) + - [verifyConditions](https://github.com/semantic-release/changelog#verifyconditions): Verify the presence and the validity of the configuration + - [publish](https://github.com/semantic-release/changelog#publish): Create or update the changelog file in the local project repository +- [@semantic-release/exec](https://github.com/semantic-release/exec) + - [verifyConditions](https://github.com/semantic-release/exec#verifyconditions): Execute a shell command to verify if the release should happen + - [getLastRelease](https://github.com/semantic-release/exec#getlastrelease): Execute a shell command to determine the last release + - [analyzeCommits](https://github.com/semantic-release/exec#analyzecommits): Execute a shell command to determine the type of release + - [verifyRelease](https://github.com/semantic-release/exec#verifyrelease): Execute a shell command to verifying a release that was determined before and is about to be published. + - [generateNotes](https://github.com/semantic-release/exec#analyzecommits): Execute a shell command to generate the release note + - [publish](https://github.com/semantic-release/exec#publish): Execute a shell command to publish the release. + +## Community plugins diff --git a/docs/shareable-configurations.md b/docs/extending/shareable-configurations-list.md similarity index 52% rename from docs/shareable-configurations.md rename to docs/extending/shareable-configurations-list.md index 2f4d60c9d2..d115a5d825 100644 --- a/docs/shareable-configurations.md +++ b/docs/extending/shareable-configurations-list.md @@ -1,7 +1,7 @@ -# semantic-release shareable configurations +# Shareable configurations list ## Official configurations -- [@semantic-release/apm-config](https://github.com/semantic-release/apm-config) - :atom: semantic-release shareable config for releasing atom packages -- [@semantic-release/gitlab-config](https://github.com/semantic-release/gitlab-config) - :fox_face: semantic-release shareable config for GitLab +- [@semantic-release/apm-config](https://github.com/semantic-release/apm-config) - semantic-release shareable configuration for releasing atom packages +- [@semantic-release/gitlab-config](https://github.com/semantic-release/gitlab-config) - semantic-release shareable configuration for GitLab ## Community configurations diff --git a/docs/plugins.md b/docs/plugins.md deleted file mode 100644 index e76efa1cbb..0000000000 --- a/docs/plugins.md +++ /dev/null @@ -1,37 +0,0 @@ -# semantic-release plugins - -## Default plugins - - - [@semantic-release/github](https://github.com/semantic-release/github) - - [verifyConditions](https://github.com/semantic-release/github#verifyconditions): Verify the presence and the validity of the GitHub authentication and release configuration - - [publish](https://github.com/semantic-release/github#publish): Publish a [GitHub release](https://help.github.com/articles/about-releases) - - - [@semantic-release/npm](https://github.com/semantic-release/npm) - - [verifyConditions](https://github.com/semantic-release/npm#verifyconditions): Verify the presence and the validity of the npm authentication and release configuration - - [getLastRelease](https://github.com/semantic-release/npm#getlastrelease): Determine the last release of the package on the npm registry - - [publish](https://github.com/semantic-release/npm#publish): Publish the package on the npm registry - -## Official plugins - - - [@semantic-release/gitlab](https://github.com/semantic-release/gitlab) - - [verifyConditions](https://github.com/semantic-release/gitlab#verifyconditions): Verify the presence and the validity of the GitLab authentication and release configuration - - [publish](https://github.com/semantic-release/gitlab#publish): Publish a [GitLab release](https://docs.gitlab.com/ce/workflow/releases.html) - - - [@semantic-release/git](https://github.com/semantic-release/git) - - [verifyConditions](https://github.com/semantic-release/git#verifyconditions): Verify the presence and the validity of the Git authentication and release configuration - - [getLastRelease](https://github.com/semantic-release/git#getlastrelease): Determine the last release via Git tags on the repository - - [publish](https://github.com/semantic-release/git#publish): Push a release commit and tag, including configurable files - - - [@semantic-release/changelog](https://github.com/semantic-release/changelog) - - [verifyConditions](https://github.com/semantic-release/changelog#verifyconditions): Verify the presence and the validity of the configuration - - [publish](https://github.com/semantic-release/changelog#publish): Create or update the changelog file in the local project repository - - - [@semantic-release/exec](https://github.com/semantic-release/exec) - - [verifyConditions](https://github.com/semantic-release/exec#verifyconditions): Execute a shell command to verify if the release should happen - - [getLastRelease](https://github.com/semantic-release/exec#getlastrelease): Execute a shell command to determine the last release - - [analyzeCommits](https://github.com/semantic-release/exec#analyzecommits): Execute a shell command to determine the type of release - - [verifyRelease](https://github.com/semantic-release/exec#verifyrelease): Execute a shell command to verifying a release that was determined before and is about to be published. - - [generateNotes](https://github.com/semantic-release/exec#analyzecommits): Execute a shell command to generate the release note - - [publish](https://github.com/semantic-release/exec#publish): Execute a shell command to publish the release. - -## Community plugins diff --git a/docs/recipes/README.md b/docs/recipes/README.md index e64de03d08..6e32caffb5 100644 --- a/docs/recipes/README.md +++ b/docs/recipes/README.md @@ -1,4 +1,4 @@ -# semantic-release recipes +# Recipes ## CI configurations - [CircleCI 2.0 workflows](circleci-workflows.md) diff --git a/docs/recipes/gitlab-ci.md b/docs/recipes/gitlab-ci.md index 0d99f1c965..742c426aeb 100644 --- a/docs/recipes/gitlab-ci.md +++ b/docs/recipes/gitlab-ci.md @@ -2,19 +2,19 @@ ## Environment variables -The [Authentication](../../README.md#authentication) environment variables can be configured with [Secret variables](https://docs.gitlab.com/ce/ci/variables/README.html#secret-variables). +The [Authentication](../usage/ci-configuration.md#authentication) environment variables can be configured with [Secret variables](https://docs.gitlab.com/ce/ci/variables/README.html#secret-variables). ## Node project configuration GitLab CI supports [Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html) allowing to test on multiple Node versions and publishing a release only when all test pass. -**Note**: The publish pipeline must run a [Node >= 8 version](../../README.md#why-does-semantic-release-require-node-version--8). +**Note**: The publish pipeline must run a [Node >= 8 version](../support/FAQ.md#why-does-semantic-release-require-node-version--8). ### `.gitlab-ci.yml` configuration for Node projects -This example is a minimal configuration for semantic-release with a build running Node 4, 6 and 8 on Linux. See [GitLab CI - Configuration of your jobs with .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options. +This example is a minimal configuration for **semantic-release** with a build running Node 4, 6 and 8 on Linux. See [GitLab CI - Configuration of your jobs with .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options. -**Note**: The`semantic-release` execution command varies depending if you are using a [local](../../README.md#local-installation) or [global](../../README.md#global-installation) semantic-release installation. +**Note**: The`semantic-release` execution command varies depending if you are using a [local](../usage/installation.md#local-installation) or [global](../usage/installation.md#global-installation) **semantic-release** installation. ```yaml # The release pipeline will run only if all jobs in the test pipeline are successful @@ -57,7 +57,7 @@ publish: ### `package.json` configuration -A `package.json` is required only for [local semantic-release installations](../../README.md#local-installation). +A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation. ```json { diff --git a/docs/recipes/travis.md b/docs/recipes/travis.md index 695f0cb0b4..bf73200c64 100644 --- a/docs/recipes/travis.md +++ b/docs/recipes/travis.md @@ -2,15 +2,15 @@ ## Environment variables -The [Authentication](../../README.md#authentication) environment variables can be configured in [Travis Repository Settings](https://docs.travis-ci.com/user/environment-variables/#defining-variables-in-repository-Settings) or with the [travis env set CLI](https://github.com/travis-ci/travis.rb#env). +The [Authentication](../usage/ci-configuration.md#authentication) environment variables can be configured in [Travis Repository Settings](https://docs.travis-ci.com/user/environment-variables/#defining-variables-in-repository-Settings) or with the [travis env set CLI](https://github.com/travis-ci/travis.rb#env). -Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../../README.md#automatic-setup-with-semantic-release-cli). +Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../usage/ci-configuration.md#automatic-setup-with-semantic-release-cli). ## Single Node job configuration For projects that require to be tested only with a single [Node version](https://docs.travis-ci.com/user/getting-started/#Selecting-a-different-programming-language) on [one Operating System](https://docs.travis-ci.com/user/getting-started/#Selecting-infrastructure-(optional)). -**Note**: [Node 8 is the minimal version required](../../README.md#why-does-semantic-release-require-node-version--8). +**Note**: [Node 8 is the minimal version required](../support/FAQ.md#why-does-semantic-release-require-node-version--8). ### `.travis.yml` configuration for single Node job @@ -18,7 +18,7 @@ This example is a minimal configuration for semantic-release with a build runnin It's recommended to run the `semantic-release` command in the [Travis `script` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error happen the build will fail and Travis will send a notification. -**Note**: The`semantic-release` execution command varies depending if you are using a [local](../../README.md#local-installation) or [global](../../README.md#global-installation) semantic-release installation. +**Note**: The`semantic-release` execution command varies depending if you are using a [local](../usage/installation.md#local-installation) or [global](../usage/installation.md#global-installation) semantic-release installation. ```yaml language: node_js @@ -39,7 +39,7 @@ script: ### `package.json` configuration for single Node job -A `package.json` is required only for [local semantic-release installations](../../README.md#local-installation). +A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation. ```json { @@ -56,17 +56,17 @@ A `package.json` is required only for [local semantic-release installations](../ For projects that require to be tested with multiple [Node versions](https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#Specifying-Node.js-versions) and/or on multiple [Operating Systems](https://docs.travis-ci.com/user/multi-os). -**Note**: At least one job must run a [Node >= 8 version](../../README.md#why-does-semantic-release-require-node-version--8). +**Note**: At least one job must run a [Node >= 8 version](../support/FAQ.md#why-does-semantic-release-require-node-version--8). ### `.travis.yml` configuration for multiple Node jobs -This example is a minimal configuration for semantic-release with a build running Node 4, 6 and 8 on Linux and OSX. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options. +This example is a minimal configuration for **semantic-release** with a build running Node 4, 6 and 8 on Linux and OSX. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options. -This example uses [`travis-deploy-once`](https://github.com/semantic-release/travis-deploy-once) in order to command [Run `semantic-release` only after all tests succeeded](../../README.md#run-semantic-release-only-after-all-tests-succeeded). Alternatively you can use [Travis CI Build Stages recipe](travis-build-stages.md). +This example uses [`travis-deploy-once`](https://github.com/semantic-release/travis-deploy-once) in order to command [Run `semantic-release` only after all tests succeeded](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded). Alternatively you can use [Travis CI Build Stages recipe](travis-build-stages.md). It's recommended to run the `semantic-release` command in the [Travis `script` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error happen the build will fail and Travis will send a notification. -**Note**: The`semantic-release` execution command varies depending if you are using a [local](../../README.md#local-installation) or [global](../../README.md#global-installation) semantic-release installation. +**Note**: The`semantic-release` execution command varies depending if you are using a [local](../usage/installation.md#local-installation) or [global](../usage/installation.md#global-installation) **semantic-release** installation. ```yaml language: node_js @@ -96,7 +96,7 @@ script: ### `package.json` configuration for multiple Node jobs -A `package.json` is required only for [local semantic-release installations](../../README.md#local-installation). +A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation. ```json { @@ -115,13 +115,13 @@ A `package.json` is required only for [local semantic-release installations](../ For projects that require to be tested with one or multiple version of a Non-JavaScript [language](https://docs.travis-ci.com/user/languages), optionally on multiple [Operating Systems](https://docs.travis-ci.com/user/multi-os). -This recipe cover the Travis specifics only. See [Non JavaScript projects recipe](../../README.md#can-i-use-semantic-release-to-publish-non-javascript-packages) for more information on the semantic-release configuration. +This recipe cover the Travis specifics only. See [Non JavaScript projects recipe](../support/FAQ.md#can-i-use-semantic-release-to-publish-non-javascript-packages) for more information on the **semantic-release** configuration. ### `.travis.yml` configuration for non-JavaScript projects This example is a minimal configuration for semantic-release with a build running [Go 1.6 and 1.7](https://docs.travis-ci.com/user/languages/go) on Linux and OSX. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options. -This example uses [`travis-deploy-once`](https://github.com/semantic-release/travis-deploy-once) in order to [run `semantic-release` only after all tests succeeded](../../README.md#run-semantic-release-only-after-all-tests-succeeded). Alternatively you can use [Travis CI Build Stages recipe](travis-build-stages.md). +This example uses [`travis-deploy-once`](https://github.com/semantic-release/travis-deploy-once) in order to [run `semantic-release` only after all tests succeeded](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded). Alternatively you can use [Travis CI Build Stages recipe](travis-build-stages.md). It's recommended to run the `semantic-release` command in the [Travis `script` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error happen the build will fail and Travis will send a notification. diff --git a/docs/resources.md b/docs/resources.md new file mode 100644 index 0000000000..fd08e68c34 --- /dev/null +++ b/docs/resources.md @@ -0,0 +1,19 @@ +# Resources + +## Videos + +- ["Introducing Reliable Dependency and Release Management for npm Packages" - Gregor Martynus](https://www.youtube.com/watch?v=R2RJWLcfzwc) +- ["Kill all humans" - Jan Lehnardt](https://www.youtube.com/watch?v=ZXyx_1kN1L8&t=2s) +- [Publishing JavaScript Packages" - JavaScript Air](https://javascriptair.com/episodes/2016-07-20) +- ["Managing Dependencies like a boss 😎" - JavaScript Air](https://javascriptair.com/episodes/2016-08-17) +- ["Dependency Hell Just Froze Over" - Stephan Bönnemann](https://www.youtube.com/watch?v=PA139CERNbc) +- [“semantic-release Q&A with Kent C. Dodds”](https://www.youtube.com/watch?v=g6y3DnhkjrI) +- [“We fail to follow SemVer – and why it needn’t matter” - Stephan Bönnemann](https://www.youtube.com/watch?v=tc2UgG5L7WM) + +## Articles + +- [“Introduction to SemVer” - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2) + +## Tutorials + +- [“How to Write a JavaScript Library - Automating Releases with semantic-release” – egghead.io](https://egghead.io/lessons/javascript-automating-releases-with-semantic-release) diff --git a/docs/support/FAQ.md b/docs/support/FAQ.md new file mode 100644 index 0000000000..355d1b925d --- /dev/null +++ b/docs/support/FAQ.md @@ -0,0 +1,148 @@ +# Frequently Asked Questions + +## Why is the `package.json`’s version not updated in my repository? + +**semantic-release** takes care of updating the `package.json`’s version before publishing to [npm](https://www.npmjs.com). + +By default, only the published package will contains the version, which is the only place where it is *really* required, but the updated `package.json` will not be pushed to the Git repository + +However, the [`@semantic-release/git`](https://github.com/semantic-release/git) plugin can be used to push the updated `package.json` as well as other files to the Git repository. + +## How can I use a npm build script that requires the `package.json`’s version ? + +The `package.json`’s version will be updated by the `semantic-release` command just before publishing to [npm](https://www.npmjs.com), therefore it won't be available for scripts ran before the `semantic-release` command. + +As semantic-release uses the [npm CLI](https://docs.npmjs.com/cli/npm) to publish, all [npm hook scripts](https://docs.npmjs.com/misc/scripts#hook-scripts) will be executed. Therefore you can run your build script in the [`prepublishOnly`](https://docs.npmjs.com/misc/scripts#prepublish-and-prepare) hook. It will be executed after the `semantic-release` command update the `package.json`’s version and before publishing. + +## Is there a way to preview which version would currently get published? + +Yes with the [dry-run options](../usage/configuration.md#dryrun) which prints to the console the next version to be published and the release notes. + +## Can I use semantic-release with Yarn? + +If you are using a [local](../usage/installation.md#local-installation) **semantic-release** installation and run multiple CI jobs with different versions, the `yarn install` command will fail with Node < 8 as **semantic-release** require [Node >= 8](#why-does-semantic-release-require-node-version--8). See [yarnpkg/rfcs#69](https://github.com/yarnpkg/rfcs/pull/69). + +In order to run **semantic-release** with [Yarn](https://yarnpkg.com) you would need to: +- Use a [global](../usage/installation.md#global-installation) **semantic-release** installation +- Make sure to install and run the `semantic-release` command only in a CI jobs running with [Node >= 8](#why-does-semantic-release-require-node-version--8) + +If your CI environment provides [nvm](https://github.com/creationix/nvm) you can switch to Node 8 before installing and running the `semantic-release` command: + +```bash +$ nvm install 8 && yarn install -g semantic-release && semantic-release +``` + +See the [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on specific CI environments. + +## Can I use semantic-release to publish non-JavaScript packages? + +Yes, **semantic-release** is a Node CLI application but it can be used to publish any type of packages. + +To publish a non-JavaScript package you would need to: +- Use a [global](../usage/installation.md#global-installation) **semantic-release** installation +- Set **semantic-release** [options](../usage/configuration.md#options) via [CLI arguments or rc file](../usage/configuration.md#configuration) +- Make sure your CI job executing the `semantic-release` command has access to [Node >= 8](#why-does-semantic-release-require-node-version--8) to execute the `semantic-release` command + +See the [CI configuration recipes](../usage/ci-configuration.md) for more details on specific CI environments. + +## Can I use semantic-release with any CI service? + +Yes, **semantic-release** can be used with any CI service, as long as it provides: +- A way to set [authentication](../usage/ci-configuration.md#authentication) via environment variables +- A way to guarantee that the `semantic-release` command is [executed only after all the tests of all the jobs in the CI build pass](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded) + +See the [CI configuration recipes](../usage/ci-configuration.md) for more details on specific CI environments. + +## Can I run semantic-release on my local machine rather than on a CI server? + +Yes, you can by explicitly setting the [`--no-ci` CLI option](../usage/configuration.md#options) option. You will also have to set the required [authentication](../usage/ci-configuration.md#authentication) via environment variables on your local machine, for example: + +```bash +$ NPM_TOKEN= GH_TOKEN= npm run semantic-release --no-ci +``` + +However this is not the recommended approach, as running unit and integration tests on an independent machine before publishing software is a crucial part of the release workflow. + +## Can I use semantic-release with GitLab? + +Yes, with the [`@semantic-release/gitlab-config`](https://github.com/semantic-release/gitlab-config) shareable configuration. + +See the [GitLab CI recipes](../recipes/gitlab-ci.md#using-semantic-release-with-gitlab-ci) for the CI configuration. + +## Can I use semantic-release with any Git hosted environment? + +By default **semantic-release** uses the [`@semantic-release/github`](https://github.com/semantic-release/github) plugin to publish a [GitHub release](https://help.github.com/articles/about-releases). For other Git hosted environment the [`@semantic-release/git`](https://github.com/semantic-release/git) and [`@semantic-release/changelog`](https://github.com/semantic-release/changelog) plugins can be used via [plugins configuration](../usage/plugins.md#configuration). + +See the [`@semantic-release/git`](https://github.com/semantic-release/git#semantic-releasegit) [`@semantic-release/changelog`](https://github.com/semantic-release/changelog#semantic-releasechangelog) plugins documentation for more details. + +## Can I skip the release to the npm registry? + +Yes, the publishing to the npm registry can be disabled with the [`npmPublish`](https://github.com/semantic-release/npm#options) option of the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin. In addition the [`tarballDir`](https://github.com/semantic-release/npm#options) option allow to generate the package tarball in order to publish it to your repository with the [`@semantic-release/git`](https://github.com/semantic-release/git) or to a [GitHub release](https://help.github.com/articles/about-releases) with the [`@semantic-release/github`](https://github.com/semantic-release/github) plugin. + +See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#semantic-releasenpm) plugin documentation for more details. + +## Can I use `.npmrc` options? + +Yes, all the [npm configuration options](https://docs.npmjs.com/misc/config) are supported via the [`.npmrc`](https://docs.npmjs.com/files/npmrc) file at the root of your repository. + +See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#npm-configuration) plugin documentation for more details. + +## How can I set the access level of the published npm package? + +The [npm `access` option](https://docs.npmjs.com/misc/config#access) can be set in the [`.npmrc`](https://docs.npmjs.com/files/npmrc) file at the root of your repository: + +```rc +access=public +``` + +Or with the `publishConfig.access` key in your project's `package.json`: + +```json +{ + "publishConfig": { + "access": "public" + } +} +``` + +## Can I use semantic-release to publish a package on Artifactory? + +Any npm compatible registry is supported with the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin. For Artifactory versions prior to 5.4, the legacy authentication has to be used (with `NPM_USERNAME`, `NPM_PASSWORD` and `NPM_EMAIL` [environment variables](https://github.com/semantic-release/npm#environment-variables)). + +See [npm registry authentication](https://github.com/semantic-release/npm#npm-registry-authentication) for more details. + +See [Artifactory - npm Registry](https://www.jfrog.com/confluence/display/RTF/Npm+Registry#NpmRegistry-AuthenticatingthenpmClient) documentation for Artifactiry configuration. + +## Can I manually trigger the release of a specific version? + +You can trigger a release by pushing to your Git repository. You deliberately cannot trigger a *specific* version release, because this is the whole point of semantic-release. + +## Is it *really* a good idea to release on every push? + +It is indeed a great idea because it *forces* you to follow best practices. If you don’t feel comfortable releasing every feature or fix on your `master` you might not treat your `master` branch as intended. + +From [Understanding the GitHub Flow](https://guides.github.com/introduction/flow/index.html): + +> Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There's only one rule: anything in the master branch is always deployable. + +If you need more control over the timing of releases, see [Triggering a release](../../README.md#triggering-a-release) for different options. + +## Can I set the initial release version of my package to `0.0.1`? + +This is not supported by **semantic-release** as it's not considered a good practice, mostly because [Semantic Versioning](https://semver.org) rules applies differently to major version zero. + +In early development phase when your package is not ready for production yet we recommend to publish releases on a distribution channel (for example npm’s [dist-tags](https://docs.npmjs.com/cli/dist-tag)) or to develop on a `dev` branch and merge it to `master` periodically. See [Triggering a release](../../README.md#triggering-a-release) for more details on those solutions. + +See [“Introduction to SemVer” - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2) for more details on [Semantic Versioning](https://semver.org) and the recommendation to start at version `1.0.0`. + +## Can I trust semantic-release with my releases? + +**semantic-release** has a full unit and integration test suite that tests `npm` publishes against the [npm-registry-couchapp](https://github.com/npm/npm-registry-couchapp). + +In addition the [verify conditions step](../../README.md#release-steps) verifies that all necessary conditions for proceeding with a release are met, and a new release will be performed [only if all your tests pass](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded). + +## Why does semantic-release require Node version >= 8? + +**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which **requires Node version 8 or higher**. + +See [Node version requirement](../support/node-version.md#node-version-requirement) for more details and solutions. diff --git a/docs/support/README.md b/docs/support/README.md new file mode 100644 index 0000000000..37fbe27533 --- /dev/null +++ b/docs/support/README.md @@ -0,0 +1,6 @@ +# Support + +- [Frequently Asked Questions](FAQ.md) +- [Troubleshooting](troubleshooting.md) +- [Node version requirement](node-version.md) +- [Node Support Policy](node-support-policy.md) diff --git a/docs/support/node-support-policy.md b/docs/support/node-support-policy.md new file mode 100644 index 0000000000..99d9067e05 --- /dev/null +++ b/docs/support/node-support-policy.md @@ -0,0 +1,13 @@ +# Node Support Policy + +We only support [Long-Term Support](https://github.com/nodejs/Release) versions of Node starting with [Node 8.9.0 (LTS)](https://nodejs.org/en/blog/release/v8.9.0). + +We specifically limit our support to LTS versions of Node, not because this package won't work on other versions, but because we have a limited amount of time, and supporting LTS offers the greatest return on that investment. + +It's possible this package will work correctly on newer versions of Node. It may even be possible to use this package on older versions of Node, though that's more unlikely as we'll make every effort to take advantage of features available in the oldest LTS version we support. + +As each Node LTS version reaches its end-of-life we will remove that version from the node engines property of our package's package.json file. Removing a Node version is considered a breaking change and will entail the publishing of a new major version of this package. We will not accept any requests to support an end-of-life version of Node. Any merge requests or issues supporting an end-of-life version of Node will be closed. + +We will accept code that allows this package to run on newer, non-LTS, versions of Node. Furthermore, we will attempt to ensure our own changes work on the latest version of Node. To help in that commitment, our continuous integration setup runs against all LTS versions of Node in addition the most recent Node release; called current. + +JavaScript package managers should allow you to install this package with any version of Node, with, at most, a warning if your version of Node does not fall within the range specified by our node engines property. If you encounter issues installing this package, please report the issue to your package manager. diff --git a/docs/node-version.md b/docs/support/node-version.md similarity index 51% rename from docs/node-version.md rename to docs/support/node-version.md index 0de46bc49e..12cbf22508 100644 --- a/docs/node-version.md +++ b/docs/support/node-version.md @@ -1,10 +1,10 @@ # Node version requirement -semantic-release is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which requires **requires Node version 8 or higher**. +**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which requires **requires Node version 8 or higher**. -semantic-release is meant to be used in a CI environment as a development support tool, not as a production dependency. Therefore the only constraint is to run the `semantic-release` in a CI environment providing Node 8 or higher. +**semantic-release** is meant to be used in a CI environment as a development support tool, not as a production dependency. Therefore the only constraint is to run the `semantic-release` in a CI environment providing Node 8 or higher. -See our [Node Support Policy](../README.md#node-support-policy) for our long-term promise regarding Node version support. +See our [Node Support Policy](node-support-policy.md) for our long-term promise regarding Node version support. ## Recommended solution @@ -12,7 +12,7 @@ See our [Node Support Policy](../README.md#node-support-policy) for our long-ter The recommended approach is to run the `semantic-release` command from a CI job running on Node 8 or higher. This can either be a job used by your project to test on Node 8 or a dedicated job for the release steps. -See [CI configuration](../README.md#ci-configuration) and [CI configuration recipes](recipes/README.md#ci-configurations) for more details. +See [CI configuration](../usage/ci-configuration.md) and [CI configuration recipes](../recipes/README.md#ci-configurations) for more details. ## Alternative solutions @@ -22,13 +22,13 @@ See [CI configuration](../README.md#ci-configuration) and [CI configuration reci `npx` can be used to download the [Node 8 package published on npm](https://www.npmjs.com/package/node) and use it to execute the `semantic-release` command. -If you are using a [local](../README.md#local-installation) semantic-release installation: +If you are using a [local](../usage/installation.md#local-installation) **semantic-release** installation: ```bash $ npm install -g npx && npx -p node@8 -c "npm run semantic-release" ``` -If you are using a [global](../README.md#global-installation) semantic-release installation: +If you are using a [global](../usage/installation.md#global-installation) **semantic-release** installation: ```bash # For global semantic-release install @@ -39,13 +39,13 @@ $ npm install -g semantic-release npx && npx -p node@8 -c "semantic-release" If your CI environment provides [nvm](https://github.com/creationix/nvm) you can use it to switch to Node 8 before running the `semantic-release` command. -If you are using a [local](../README.md#local-installation) semantic-release installation: +If you are using a [local](../usage/installation.md#local-installation) **semantic-release** installation: ```bash $ nvm install 8 && npm run semantic-release ``` -If you are using a [global](../README.md#global-installation) semantic-release installation: +If you are using a [global](../usage/installation.md#global-installation) **semantic-release** installation: ```bash $ nvm install 8 && npm install -g semantic-release && semantic-release diff --git a/docs/troubleshooting.md b/docs/support/troubleshooting.md similarity index 97% rename from docs/troubleshooting.md rename to docs/support/troubleshooting.md index 347ff5d6b8..1e7e0489c5 100644 --- a/docs/troubleshooting.md +++ b/docs/support/troubleshooting.md @@ -1,4 +1,4 @@ -# Troubleshooting semantic-release +# Troubleshooting ### ENOTINHISTORY Commit not in history diff --git a/docs/usage/README.md b/docs/usage/README.md new file mode 100644 index 0000000000..91208c6573 --- /dev/null +++ b/docs/usage/README.md @@ -0,0 +1,7 @@ +# Usage + +- [Installation](installation.md#installation) +- [CI Configuration](ci-configuration.md#ci-configuration) +- [Configuration](configuration.md#configuration) +- [Plugins](plugins.md) +- [Shareable configurations](shareable-configurations.md) diff --git a/docs/usage/ci-configuration.md b/docs/usage/ci-configuration.md new file mode 100644 index 0000000000..3d9021246e --- /dev/null +++ b/docs/usage/ci-configuration.md @@ -0,0 +1,37 @@ +# CI configuration + +## 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), [Wercker Workflows](http://devcenter.wercker.com/docs/workflows), [GoCD Pipelines](https://docs.gocd.org/current/introduction/concepts_in_go.html#pipeline) or specific tools like [`travis-deploy-once`](https://github.com/semantic-release/travis-deploy-once). + +See [CI configuration recipes](../recipes/README.md#ci-configurations) for more details. + +## Authentication + +Most **semantic-release** [plugins](plugins.md) require to set up authentication in order to publish to your package manager's registry or to access your project's Git hosted service. The authentication token/credentials have to be made available in the CI serice via environment variables. + +See each plugin documentation for the environment variable to set up. + +The default [npm](https://github.com/semantic-release/npm#environment-variables) and [github](https://github.com/semantic-release/github#environment-variables) plugins require the following environment variables: + +| Variable | Description | +|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `NPM_TOKEN` | npm token created via [npm token create](https://docs.npmjs.com/getting-started/working_with_tokens#how-to-create-new-tokens).
**Note**: Only the `auth-only` [level of npm two-factor authentication](https://docs.npmjs.com/getting-started/using-two-factor-authentication#levels-of-authentication) is supported. | +| `GH_TOKEN` | GitHub authentication token.
**Note**: Only the [personal token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line) authentication is supported. | + +See [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on how to configure environment variables in your CI service. + +## Automatic setup with `semantic-release-cli` + +[`semantic-release-cli`](https://github.com/semantic-release/cli) allow to easily [install](installation.md) **semantic-release** in your Node project and set up the CI configuration: + +```bash +npm install -g semantic-release-cli + +cd your-module +semantic-release-cli setup +``` + +![dialogue](media/semantic-release-cli.png) + +See the [semantic-release-cli](https://github.com/semantic-release/cli#what-it-does) documentation for more details. diff --git a/docs/usage/configuration.md b/docs/usage/configuration.md new file mode 100644 index 0000000000..b12ca28505 --- /dev/null +++ b/docs/usage/configuration.md @@ -0,0 +1,168 @@ +# Configuration + +In order to customize **semantic-release**’s behavior, [options](#options) and [plugins](plugins.md) can be set via: +- 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` key in the project's `package.json` file +- CLI arguments + +The following two examples are the same. + +Via CLI argument: + +```bash +$ semantic-release --branch next +``` + +Via `release` key in the project's `package.json` file: + +```json +"release": { + "branch": "next" +} +``` +```bash +$ semantic-release +``` + +**Note**: CLI arguments take precedence over options configured in the configuration file. + +**Note**: Plugins options cannot be defined via CLI arguments and must be defined in the configuration file. + +## Options + +### extends + +Type: `Array`, `String` + +CLI arguments: `-e`, `--extends` + +List of modules or file paths containing a [shareable configuration](shareable-configurations.md). If multiple shareable configuration are set, they will be imported in the order defined with each configuration option taking precedence over the options defined in a previous shareable configuration. + +**Note**: Options defined via CLI arguments or in the configuration file will take precedence over the ones defined in any shareable configuration. + +### branch + +Type: `String` + +Default: `master` + +CLI arguments: `-b`, `--branch` + +The branch on which releases should happen. + +### repositoryUrl + +Type: `String` + +Default: `repository` property in `package.json` or [git origin url](https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes) + +CLI arguments: `-r`, `--repository-url` + +The git repository URL + +Any valid git url format is supported (See [Git protocols](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols)). + +**Note**: If the [Github plugin](https://github.com/semantic-release/github) is used the URL must be a valid Github URL that include the `owner`, the `repository` name and the `host`. **The Github shorthand URL is not supported.** + +### dryRun + +Type: `Boolean` + +Default: `false` if running in a CI environment, `false` otherwise + +CLI arguments: `-d`, `--dry-run` + +Dry-run mode, skip publishing, print next version and release notes. + +### noCi + +Type: `Boolean` + +Default: `false` + +CLI arguments: `--no-ci` + +Skip Continuous Integration environment verifications, allowing to make releases from a local machine. + +### debug + +Type: `Boolean` + +Default: `false` + +CLI argument: `--debug` + +Output debugging information. It can also be enabled by set the `DEBUG` environment variable to `semantic-release`. + +### verifyConditions + +Type: `Array`, `String`, `Object` + +Default: `['@semantic-release/npm', '@semantic-release/github']` + +CLI argument: `--verify-conditions` + +Define the list of [verify conditions plugins](plugins.md#verifyconditions-plugin). Plugins will run in series, in the order defined in the `Array`. + +See [Plugins configuration](plugins.md#configuration) for more details. + +### getLastRelease + +Type: `String`, `Object` + +Default: `['@semantic-release/npm']` + +CLI argument: `--get-last-release` + +Define the [get last release plugin](plugins.md#getlastrelease-plugin). + +See [Plugins configuration](plugins.md#configuration) for more details. + +### analyzeCommits + +Type: `String`, `Object` + +Default: `['@semantic-release/commit-analyzer']` + +CLI argument: `--analyze-commits` + +Define the [analyze commits plugin](plugins.md#analyzecommits-plugin). + +See [Plugins configuration](plugins.md#configuration) for more details. + +### verifyRelease + +Type: `Array`, `String`, `Object` + +Default: `[]` + +CLI argument: `--verify-release` + +Define the list of [verify release plugins](plugins.md#verifyrelease-plugin). Plugins will run in series, in the order defined in the `Array`. + +See [Plugins configuration](plugins.md#configuration) for more details. + +### generateNotes + +Type: `String`, `Object` + +Default: `['@semantic-release/release-notes-generator']` + +CLI argument: `--generate-notes` + +Define the [generate notes plugin](plugins.md#generatenotes-plugin). + +See [Plugins configuration](plugins.md#configuration) for more details. + +### publish + +Type: `Array`, `String`, `Object` + +Default: `['@semantic-release/npm', '@semantic-release/github']` + +CLI argument: `--publish` + +Define the list of [publish plugins](plugins.md#publish-plugin). Plugins will run in series, in the order defined in the `Array`. + +See [Plugins configuration](plugins.md#configuration) for more details. diff --git a/docs/usage/installation.md b/docs/usage/installation.md new file mode 100644 index 0000000000..ac30313bf8 --- /dev/null +++ b/docs/usage/installation.md @@ -0,0 +1,32 @@ +# Installation + +## Local installation + +For [Node modules projects](https://docs.npmjs.com/getting-started/creating-node-modules) we recommend to install **semantic-release** locally and to run the `semantic-release` command with a [npm script](https://docs.npmjs.com/misc/scripts): + +```bash +$ npm install --save-dev semantic-release +``` + +In your `package.json`: + +```json +"scripts": { + "semantic-release": "semantic-release" +} +``` + +Then in the CI environment: + +```bash +$ npm run semantic-release +``` + +## Global installation + +For other type of projects we recommend to install **semantic-release** globally directly in the CI environment: + +```bash +$ npm install -g semantic-release +$ semantic-release +``` diff --git a/docs/usage/plugins.md b/docs/usage/plugins.md new file mode 100644 index 0000000000..92cc539fcd --- /dev/null +++ b/docs/usage/plugins.md @@ -0,0 +1,82 @@ +# Plugins + +Each [release steps](../../README.md#release-steps) is implemented within a plugin or a list of plugins that can be configured, allowing to support different [commit message format](../../README.md#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](https://github.com/semantic-release/npm#verifyconditions) and [github](https://github.com/semantic-release/github#verifyconditions). + +### getLastRelease plugin + +Plugin responsible for determining the version of the package last release. + +Default implementation: [@semantic-release/npm](https://github.com/semantic-release/npm#getlastrelease). + +### analyzeCommits plugin + +Plugin responsible for determining the type of the next release (`major`, `minor` or `patch`). + +Default implementation: [@semantic-release/commit-analyzer](https://github.com/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](https://github.com/semantic-release/cracks) 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](https://github.com/semantic-release/release-notes-generator). + +### publish plugin + +Plugin responsible for publishing the release. + +Default implementation: [npm](https://github.com/semantic-release/npm#publish) and [github](https://github.com/semantic-release/github#publish). + +## 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](configuration.md#options) or within the plugin `Object`. Plugins options defined along the other **semantic-release** [options](configuration.md#options) will apply to all plugins, while the one defined within the plugin `Object` will apply only to this specific plugin. + +For example: +```json +{ + "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: +- the `custom-plugin` npm module will be used to [analyze commits](#analyzecommits-plugin) +- the `./build/my-plugin.js` script will be used to [generate release notes](#generatenotes-plugin) +- the [`@semantic-release/exec`](https://github.com/semantic-release/exec), [`@semantic-release/npm`](https://github.com/semantic-release/npm) and [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugins will be used to [verify conditions](#verifyconditions-plugin) +- the [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin will be used to [verify the release](#verifyrelease-plugin) +- the `cmd` option will be set to `verify-conditions.sh` only for the [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin used to [verify conditions](#verifyconditions-plugin) +- the `cmd` option will be set to `verify-release.sh` only for the [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin used to [verify the release](#verifyrelease-plugin) +- the `githubUrl` and `githubApiPathPrefix` options will be set to respectively `https://my-ghe.com` and `/api-prefix` for all plugins diff --git a/docs/usage/shareable-configurations.md b/docs/usage/shareable-configurations.md new file mode 100644 index 0000000000..62f87ba80e --- /dev/null +++ b/docs/usage/shareable-configurations.md @@ -0,0 +1,5 @@ +# Shareable configurations + +A sharable configuration is an [npm](https://www.npmjs.com/) package that exports a **semantic-release** configuration object. It allows to easily use the same configuration across several projects. + +The shareable configurations to use can be set with the [extends](configuration.md#extends) option. diff --git a/media/bender.png b/media/bender.png new file mode 100644 index 0000000000..abbccf2178 Binary files /dev/null and b/media/bender.png differ