Compare commits
@@ -0,0 +1,48 @@
|
||||
<!--
|
||||
Please fill the informations requested or use one of the following url:
|
||||
- Bug report: https://github.com/semantic-release/semantic-release/issues/new?template=bug-report.md
|
||||
- Feature request: https://github.com/semantic-release/semantic-release/issues/new?template=feature-request.md
|
||||
- New plugin request: https://github.com/semantic-release/semantic-release/issues/new?template=plugin-request.md
|
||||
-->
|
||||
|
||||
<!--------------------- FOR BUG REPORT ONLY --------------------->
|
||||
|
||||
## Current behavior
|
||||
|
||||
<!-- Describe how the issue manifests. -->
|
||||
|
||||
## Expected behavior
|
||||
|
||||
<!-- Describe what the desired behavior would be. -->
|
||||
|
||||
## Environment
|
||||
|
||||
- **semantic-release** version: <!-- Version set in package.json devDpendencies -->
|
||||
- CI environment: <!-- CI service name -->
|
||||
- Plugins used: <!-- List semantic-release plugin used if any -->
|
||||
- **semantic-release** configuration: <!-- link to your repository or relevant part of the semantic-release config -->
|
||||
- CI logs: <!-- link to your CI logs or semantic-release logs -->
|
||||
|
||||
<!--------------------- FOR FEATURE REQUEST ONLY --------------------->
|
||||
|
||||
## New feature motivation
|
||||
|
||||
<!-- Describe the context, the use-case and the advantages of the feature request. -->
|
||||
|
||||
## New feature description
|
||||
|
||||
<!-- Describe the functional changes that would have to be made in semantic-release or its plugins. -->
|
||||
|
||||
## New feature implementation
|
||||
|
||||
<!-- Optionally describe the technical changes to be made in semantic-release or its plugins. -->
|
||||
|
||||
<!--------------------- FOR NEW PLUGIN REQUEST ONLY --------------------->
|
||||
|
||||
## New plugin motivation
|
||||
|
||||
<!-- Describe the reasons to create a new plugin and why it's not covered by the existing ones. -->
|
||||
|
||||
## Third-party documentation
|
||||
|
||||
<!-- Provide explanation and documentation links for the platform to integrate with. -->
|
||||
@@ -0,0 +1,17 @@
|
||||
# Bug report
|
||||
|
||||
## Current behavior
|
||||
|
||||
<!-- Describe how the issue manifests. -->
|
||||
|
||||
## Expected behavior
|
||||
|
||||
<!-- Describe what the desired behavior would be. -->
|
||||
|
||||
## Environment
|
||||
|
||||
- **semantic-release** version: <!-- Version set in package.json devDpendencies -->
|
||||
- CI environment: <!-- CI service name -->
|
||||
- Plugins used: <!-- List semantic-release plugin used if any -->
|
||||
- **semantic-release** configuration: <!-- link to your repository or relevant part of the semantic-release config -->
|
||||
- CI logs: <!-- link to your CI logs or semantic-release logs -->
|
||||
@@ -0,0 +1,13 @@
|
||||
# Feature request
|
||||
|
||||
## New feature motivation
|
||||
|
||||
<!-- Describe the context, the use-case and the advantages of the feature request. -->
|
||||
|
||||
## New feature description
|
||||
|
||||
<!-- Describe the functional changes that would have to be made in semantic-release or its plugins. -->
|
||||
|
||||
## New feature implementation
|
||||
|
||||
<!-- Optionally describe the technical changes to be made in semantic-release or its plugins. -->
|
||||
@@ -0,0 +1,9 @@
|
||||
# New plugin request
|
||||
|
||||
## New plugin motivation
|
||||
|
||||
<!-- Describe the reasons to create a new plugin and why it's not covered by the existing ones. -->
|
||||
|
||||
## Third-party documentation
|
||||
|
||||
<!-- Provide explanation and documentation links for the platform to integrate with. -->
|
||||
+4
-2
@@ -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
|
||||
|
||||
+2
-1
@@ -25,4 +25,5 @@ script:
|
||||
|
||||
after_success:
|
||||
- npm run codecov
|
||||
- npm run semantic-release
|
||||
- npm install -g travis-deploy-once@4
|
||||
- travis-deploy-once "npm run semantic-release"
|
||||
|
||||
+251
@@ -0,0 +1,251 @@
|
||||
# Contributing to semantic-release
|
||||
|
||||
✨ Thanks for contributing to **semantic-release**! ✨
|
||||
|
||||
As a contributor, here are the guidelines we would like you to follow:
|
||||
- [Code of conduct](#code-of-conduct)
|
||||
- [How can I contribute?](#how-can-i-contribute)
|
||||
- [Using the issue tracker](#using-the-issue-tracker)
|
||||
- [Submitting a Pull Request](#submitting-a-pull-request)
|
||||
- [Coding rules](#coding-rules)
|
||||
- [Working with the code](#working-with-the-code)
|
||||
|
||||
We also recommend to read [How to Contribute to Open Source](https://opensource.guide/how-to-contribute).
|
||||
|
||||
## Code of conduct
|
||||
|
||||
Help us keep **semantic-release** open and inclusive. Please read and follow our [Code of conduct](CODE_OF_CONDUCT.md).
|
||||
|
||||
## How can I contribute?
|
||||
|
||||
### Improve documentation
|
||||
|
||||
As a **semantic-release** user you are the perfect candidate to help us improve our documentation: typo corrections, clarifications, more examples, new [recipes](docs/recipes/README.md) etc. Take a look at the [documentation issues that need help](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+user%3Asemantic-release+archived%3Afalse+label%3A%22help+wanted%22+label%3Adocs+).
|
||||
|
||||
Please follow the [Documentation guideline](#documentation).
|
||||
|
||||
### Give feedback on issues
|
||||
|
||||
Some issues are created without information requested in the [Bug report guideline](#bug-report). Help making them easier to resolve by adding any relevant informations.
|
||||
|
||||
Issues with the [design label](https://github.com/issues?q=is%3Aopen+is%3Aissue+user%3Asemantic-release+archived%3Afalse+label%3Adesign) are meant to discuss the implementation of new features. Participating in the discussion is a good opportunity to get involved and influence the future direction of **semantic-release**.
|
||||
|
||||
### Fix bugs and implement features
|
||||
|
||||
Confirmed bug and ready to implement features are marked with the [help wanted label](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+user%3Asemantic-release+archived%3Afalse+label%3A%22help+wanted%22). Post a comment on an issue to indicate you would like to work on it and to request help from the [@semantic-release/maintainers](https://github.com/orgs/semantic-release/teams/contributors) and the community.
|
||||
|
||||
## Using the issue tracker
|
||||
|
||||
The issue tracker is the channel for [bug reports](#bug-report), [features requests](#feature-request) and [submitting pull requests](#submitting-a-pull-request) only. Please use the [Support](docs/support/README.md) and [Get help](README.md#get-help) sections for support, troubleshooting and questions.
|
||||
|
||||
Before opening an Issue or a Pull Request, please use the [GitHub issue search](https://github.com/issues?utf8=%E2%9C%93&q=user%3Asemantic-release) to make the bug or feature request hasn't been already reported or fixed.
|
||||
|
||||
### Bug report
|
||||
|
||||
A good bug report shouldn't leave others needing to chase you up for more information. Please try to be as detailed as possible in your report and fill the information requested in the [Bug report template](https://github.com/semantic-release/semantic-release/issues/new?template=bug-report.md).
|
||||
|
||||
### Feature request
|
||||
|
||||
Feature requests are welcome. But take a moment to find out whether your idea fits with the scope and aims of the project. It's up to you to make a strong case to convince the project's developers of the merits of this feature. Please provide as much detail and context as possible and fill the information requested in the [Feature request template](https://github.com/semantic-release/semantic-release/issues/new?template=feature-request.md).
|
||||
|
||||
### New plugin request
|
||||
|
||||
[Plugins](docs/usage/plugins.md) are a great way to extend **semantic-release** capabilities, integrate with other systems and support new project type. Please provide as much detail and context as possible and fill the information requested in the [New plugin request template](https://github.com/semantic-release/semantic-release/issues/new?template=plugin-request.md).
|
||||
|
||||
## Submitting a Pull Request
|
||||
|
||||
Good pull requests whether patches, improvements or new features are a fantastic help. They should remain focused in scope and avoid containing unrelated commits.
|
||||
|
||||
**Please ask first** before embarking on any significant pull request (e.g. implementing features, refactoring code), otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project.
|
||||
|
||||
If you never created a pull request before, welcome 🎉 😄. [Here is a great tutorial](https://opensource.guide/how-to-contribute/#opening-a-pull-request) on how to send one :)
|
||||
|
||||
Here is a summary of the steps to follow:
|
||||
|
||||
1. [Set up the workspace](#set-up-the-workspace)
|
||||
2. If you cloned a while ago, get the latest changes from upstream and update dependencies:
|
||||
```bash
|
||||
$ git checkout master
|
||||
$ git pull upstream master
|
||||
$ rm -rf node_modules
|
||||
$ npm install
|
||||
```
|
||||
3. Create a new topic branch (off the main project development branch) to contain your feature, change, or fix:
|
||||
```bash
|
||||
$ git checkout -b <topic-branch-name>
|
||||
```
|
||||
4. Make your code changes, following the [Coding rules](#coding-rules)
|
||||
5. Push your topic branch up to your fork:
|
||||
```bash
|
||||
$ git push origin <topic-branch-name>
|
||||
```
|
||||
6. [Open a Pull Request](https://help.github.com/articles/creating-a-pull-request/#creating-the-pull-request) with a clear title and description.
|
||||
|
||||
**Tips**:
|
||||
- For ambitious tasks, open a Pull Request as soon as possible with the `[WIP]` prefix i nthe title, in order to get feedback and help from the community.
|
||||
- [Allow semantic-release maintainers to make changes to you Pull Request branch](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) this way we can rebase it and make some minor changes if necessary. All changes we make will be done in new commit and we'll ask for your approval before merging them.
|
||||
|
||||
## Coding rules
|
||||
|
||||
### Source code
|
||||
|
||||
To ensure consistency and quality throughout the source code, all code modification must have:
|
||||
- No [linting](#lint) errors
|
||||
- A [test](#tests) for every possible cases introduced by your code change
|
||||
- **100%** test coverage
|
||||
- [Valid commit message(s)](#commit-message-guidelines)
|
||||
- Documentation for new features
|
||||
- Updated documentation for modified features
|
||||
|
||||
### Documentation
|
||||
|
||||
To ensure consistency and quality all documentation modification must:
|
||||
- Refer to brand in [bold](https://help.github.com/articles/basic-writing-and-formatting-syntax/#styling-text) with proper capitalization, i.e. **GitHub**, **semantic-release**, **npm**
|
||||
- Prefer [tables](https://help.github.com/articles/organizing-information-with-tables) over [lists](https://help.github.com/articles/basic-writing-and-formatting-syntax/#lists) when listing key values, i.e. List of options with their description
|
||||
- Use [links](https://help.github.com/articles/basic-writing-and-formatting-syntax/#links) when, the first you are referring to:
|
||||
- a **semantic-release** concept described somewhere else in the documentation, i.e. How to [contribute](CONTRIBUTING.md)
|
||||
- a third-party product/brand/service, i.e. Integrate with [GitHub](https://github.com)
|
||||
- an external concept or feature, i.e. Create a [GitHub release](https://help.github.com/articles/creating-releases)
|
||||
- a package or module, i.e. The [`@semantic-release/github`](https://github.com/semantic-release/github) module
|
||||
- Use the the [single backtick `code` quoting](https://help.github.com/articles/basic-writing-and-formatting-syntax/#quoting-code) for:
|
||||
- commands inside sentences, i.e. the `semantic-release` command
|
||||
- programming language keywords, i.e. `function`, `async`, `String`
|
||||
- packages or modules, i.e. The [`@semantic-release/github`](https://github.com/semantic-release/github) module
|
||||
- Use the the [triple backtick `code` formatting](https://help.github.com/articles/creating-and-highlighting-code-blocks) for:
|
||||
- code examples
|
||||
- configuration examples
|
||||
- sequence of command lines
|
||||
|
||||
### Commit message guidelines
|
||||
|
||||
#### Atomic commits
|
||||
|
||||
If possible, make [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit), which means:
|
||||
- a commit should contain exactly one self-contained functional change
|
||||
- a functional change should be contained in exactly one commit
|
||||
- a commit should not create an inconsistent state (such as test errors, linting errors, partial fix, feature with documentation etc...)
|
||||
|
||||
A complex feature can be broken down into multiple commits as long as each one keep a consistent state and consist of a self-contained change.
|
||||
|
||||
#### Commit message format
|
||||
|
||||
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**:
|
||||
|
||||
```commit
|
||||
<type>(<scope>): <subject>
|
||||
<BLANK LINE>
|
||||
<body>
|
||||
<BLANK LINE>
|
||||
<footer>
|
||||
```
|
||||
|
||||
The **header** is mandatory and the **scope** of the header is optional.
|
||||
|
||||
The **footer** can contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages).
|
||||
|
||||
#### Revert
|
||||
|
||||
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
|
||||
|
||||
#### Type
|
||||
|
||||
The type must be one of the following:
|
||||
|
||||
| Type | Description |
|
||||
|--------------|-------------------------------------------------------------------------------------------------------------|
|
||||
| **build** | Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) |
|
||||
| **ci** | Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) |
|
||||
| **docs** | Documentation only changes |
|
||||
| **feat** | A new feature |
|
||||
| **fix** | A bug fix |
|
||||
| **perf** | A code change that improves performance |
|
||||
| **refactor** | A code change that neither fixes a bug nor adds a feature |
|
||||
| **style** | Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) |
|
||||
| **test** | Adding missing tests or correcting existing tests |
|
||||
|
||||
#### Subject
|
||||
|
||||
The subject contains succinct description of the change:
|
||||
|
||||
- use the imperative, present tense: "change" not "changed" nor "changes"
|
||||
- don't capitalize first letter
|
||||
- no dot (.) at the end
|
||||
|
||||
#### Body
|
||||
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
|
||||
The body should include the motivation for the change and contrast this with previous behavior.
|
||||
|
||||
#### Footer
|
||||
The footer should contain any information about **Breaking Changes** and is also the place to reference GitHub issues that this commit **Closes**.
|
||||
|
||||
**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.
|
||||
|
||||
#### Examples
|
||||
|
||||
```commit
|
||||
`fix(pencil): stop graphite breaking when too much pressure applied`
|
||||
```
|
||||
|
||||
```commit
|
||||
`feat(pencil): add 'graphiteWidth' option`
|
||||
|
||||
Fix #42
|
||||
```
|
||||
|
||||
```commit
|
||||
perf(pencil): remove graphiteWidth option`
|
||||
|
||||
BREAKING CHANGE: The graphiteWidth option has been removed.
|
||||
|
||||
The default graphite width of 10mm is always used for performance reasons.
|
||||
```
|
||||
|
||||
## Working with the code
|
||||
|
||||
### Set up the workspace
|
||||
|
||||
[Fork](https://guides.github.com/activities/forking/#fork) the project, [clone](https://guides.github.com/activities/forking/#clone) your fork, configure the remotes and install the dependencies:
|
||||
|
||||
```bash
|
||||
# Clone your fork of the repo into the current directory
|
||||
$ git clone https://github.com/semantic-release/<repo-name>
|
||||
# Navigate to the newly cloned directory
|
||||
$ cd <repo-name>
|
||||
# Assign the original repo to a remote called "upstream"
|
||||
$ git remote add upstream https://github.com/semantic-release/<repo-name>
|
||||
# Install the dependencies
|
||||
$ npm install
|
||||
```
|
||||
|
||||
### Lint
|
||||
|
||||
All the [semantic-release](https://github.com/semantic-release) repository use [XO](https://github.com/sindresorhus/xo) for linting and [Prettier](https://prettier.io) for formatting. Prettier formatting will be automatically verified and fixed by XO.
|
||||
|
||||
Before pushing your code changes make sure there is no linting errors with `npm run lint`.
|
||||
|
||||
**Tips**:
|
||||
- Most linting errors can be automatically fixed with `npm run lint --fix`.
|
||||
- Install the [XO plugin](https://github.com/sindresorhus/xo#editor-plugins) for your editor to see linting error directly in your editor and automatically fix them on save.
|
||||
|
||||
### Tests
|
||||
|
||||
Running the integration test require to install [Docker](https://docs.docker.com/engine/installation) on your machine.
|
||||
|
||||
All the [semantic-release](https://github.com/semantic-release) repository use [AVA](https://github.com/avajs/ava) for writing and running tests.
|
||||
|
||||
Before pushing your code changes make sure all **test pass** and the **coverage is 100%**:
|
||||
|
||||
```bash
|
||||
$ npm run test
|
||||
```
|
||||
|
||||
**Tips:** During development you can:
|
||||
- run only a subset of test files with `ava <glob>`, for example `ava test/mytestfile.test.js`
|
||||
- run in watch mode with `ava -w` to automatically run a test file when you modify it
|
||||
- run only the test you are working on by adding [`.only` to the test definition](https://github.com/avajs/ava#running-specific-tests)
|
||||
|
||||
### Commits
|
||||
|
||||
All the [semantic-release](https://github.com/semantic-release) repository use [Commitizen](https://github.com/commitizen/cz-cli) to help you create [valid commit messages](#commit-message-guidelines).
|
||||
|
||||
After staging your changes with `git add`, run `npm run cm` to start the interactive commit message CLI.
|
||||
@@ -1,301 +1,127 @@
|
||||
# :package::rocket: semantic-release
|
||||
<h1 align="center" style="border-bottom: none;">📦🚀 semantic-release</h1>
|
||||
<h3 align="center">Fully automated version management and package publishing</h3>
|
||||
<p align="center">
|
||||
<a href="https://gitter.im/semantic-release/semantic-release">
|
||||
<img alt="Gitter" src="https://badges.gitter.im/semantic-release/semantic-release.svg">
|
||||
</a>
|
||||
<a href="https://travis-ci.org/semantic-release/semantic-release">
|
||||
<img alt="Travis" src="https://img.shields.io/travis/semantic-release/semantic-release/caribou.svg">
|
||||
</a>
|
||||
<a href="https://codecov.io/gh/semantic-release/semantic-release">
|
||||
<img alt="Codecov" src="https://img.shields.io/codecov/c/github/semantic-release/semantic-release/caribou.svg">
|
||||
</a>
|
||||
<a href="https://greenkeeper.io">
|
||||
<img alt="Greenkeeper" src="https://badges.greenkeeper.io/semantic-release/semantic-release.svg">
|
||||
</a>
|
||||
<a href="#badge">
|
||||
<img alt="semantic-release" src="https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg">
|
||||
</a>
|
||||
</p>
|
||||
<p align="center">
|
||||
<a href="https://www.npmjs.com/package/semantic-release">
|
||||
<img alt="npm latest version" src="https://img.shields.io/npm/v/semantic-release/latest.svg">
|
||||
</a>
|
||||
<a href="https://www.npmjs.com/package/semantic-release">
|
||||
<img alt="npm next version" src="https://img.shields.io/npm/v/semantic-release/next.svg">
|
||||
</a>
|
||||
</p>
|
||||
|
||||
**fully automated package publishing**
|
||||
**semantic-release** automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.
|
||||
|
||||
> **Trust us, this will change your workflow for the better.**
|
||||
This removes the immediate connection between human emotions and version numbers, strictly following the [Semantic Versioning](http://semver.org) specification.
|
||||
|
||||
> – [egghead.io](https://egghead.io/lessons/javascript-how-to-write-a-javascript-library-automating-releases-with-semantic-release)
|
||||
> 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)
|
||||
|
||||
[](https://gitter.im/semantic-release/semantic-release?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
|
||||
[](https://www.npmjs.com/package/semantic-release)
|
||||
[](https://greenkeeper.io/)
|
||||
[](https://github.com/semantic-release/semantic-release/blob/master/LICENSE)
|
||||
[](https://github.com/prettier/prettier)
|
||||
[](https://github.com/semantic-release/semantic-release)
|
||||
[](http://commitizen.github.io/cz-cli/)
|
||||
## Highlights
|
||||
|
||||
[](https://travis-ci.org/semantic-release/semantic-release)
|
||||
[](https://codecov.io/gh/semantic-release/semantic-release)
|
||||
|
||||
Out of the box this is just about _commit-messages_, but you can do so much more.
|
||||
|
||||
* **Detect breaking changes** using the test suite of your last release: [cracks](https://github.com/semantic-release/cracks)
|
||||
* Detect breaking changes using your dependents’ test suites: [Help out! Implement the **dont-break** plugin](https://github.com/semantic-release/semantic-release/issues/65)
|
||||
* Detect breaking changes diffing your JSDoc interface: [Help out! Implement the **india** plugin](https://github.com/semantic-release/semantic-release/issues/66)
|
||||
* Abort releases with **insufficient test coverage**: [Help out! Implement the **istanbul** plugin](https://github.com/semantic-release/semantic-release/issues/68)
|
||||
* Abort releases with **vulnerable dependencies** in the tree: [Help out! Implement the **nsp** plugin](https://github.com/semantic-release/semantic-release/issues/67)
|
||||
* Everything you can imagine: [Build Plugins!](https://github.com/semantic-release/semantic-release#plugins)
|
||||
|
||||
| Commands | Comment
|
||||
--- | --- | ---
|
||||
| **manual/before** | <pre><code><div>npm version major</div><div>git push origin master --tags</div><div>npm publish</div></code></pre> | You **manually decide** what the **next version** is. You have to remember what major, minor and patch means. You have to remember to push both commits and tags. You have to wait for the CI to pass. |
|
||||
| **semantic-release/after** | <pre><code><div>git commit -m "fix: <message>"</div><div>git push</div></code></pre> | You **describe the changes** you’ve made. A new version is automatically published with the correct version number.
|
||||
|
||||
This removes the immediate connection between human emotions and version numbers, so strictly following the [SemVer](http://semver.org/) spec is not a problem anymore – and that’s ultimately `semantic-release`’s goal.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th colspan="2">
|
||||
“How to Write a JavaScript Library - Automating Releases with semantic-release” – egghead.io
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="2">
|
||||
<a href="https://egghead.io/lessons/javascript-how-to-write-a-javascript-library-automating-releases-with-semantic-release"><img src="https://cloud.githubusercontent.com/assets/908178/9730739/7b1da5d8-5610-11e5-88b6-5c75fdda7ee2.png" alt="egghead.io session"></a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="2">
|
||||
A free egghead.io tutorial series on how to write an open source library featuring semantic-release.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>
|
||||
“We fail to follow SemVer – and why it needn’t matter”
|
||||
</th>
|
||||
<th>
|
||||
“semantic-release Q&A with Kent C. Dodds”
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<a href="https://www.youtube.com/watch?v=tc2UgG5L7WM&index=6&list=PLFZ5NyC0xHDaaTy6tY9p0C0jd_rRRl5Zm"><img alt="JSConfBP Talk" src="https://cloud.githubusercontent.com/assets/908178/9428178/c337ed26-49a2-11e5-8ad0-a602500a65bf.png"></a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://www.youtube.com/watch?v=g6y3DnhkjrI"><img alt="Hangout on Air with Kent C. Dodds" src="https://cloud.githubusercontent.com/assets/908178/9428179/c3387318-49a2-11e5-9f5f-dccd3fbb0c1d.png"></a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
This talk gives you a complete introduction to the underlying concepts of this module. 38:30
|
||||
</td>
|
||||
<td>
|
||||
A “Hangouts on Air” conversation with hands on questions and answers about how to use semantic-release. 53:52
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
- Fully automated release
|
||||
- Enforce [Semantic Versioning](https://semver.org) specification
|
||||
- New features and fixes are immediately available to users
|
||||
- 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](docs/usage/plugins.md)
|
||||
- Simple and reusable configuration via [shareable configurations](docs/usage/shareable-configurations.md)
|
||||
|
||||
## How does it work?
|
||||
|
||||
Instead of writing [meaningless commit messages](http://whatthecommit.com/), we can take our time to think about the changes in the codebase and write them down. Following formalized conventions it is then possible to generate a helpful changelog and to derive the next semantic version number from them.
|
||||
|
||||
When `semantic-release` is set up it will do that after every successful continuous integration build of your master branch (or any other branch you specify) and publish the new version for you. This way no human is directly involved in the release process and your releases are guaranteed to be [unromantic and unsentimental](http://sentimentalversioning.org/).
|
||||
|
||||
If you fear the loss of control over timing and marketing implications of software releases you should know that `semantic-release` supports [release channels](https://github.com/npm/npm/issues/2718) using `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, you can decide when to promote an automatically released version to the stable channel, and you can choose which versions to write blogposts and tweets about. You can use the same mechanism to [support older versions of your software](https://gist.github.com/boennemann/54042374e49c7ade8910), for example with important security fixes.
|
||||
|
||||
When pushing new commits with `git push` a CI build is triggered. After running the tests the command `semantic-release` will execute the following tasks in series:
|
||||
|
||||
| Step | Description |
|
||||
| ------------------ | ------------------------------------------------------------------------------------------- |
|
||||
| Verify Conditions | Run the [verifyConditions](#verifyconditions) plugin |
|
||||
| Get last release | Obtain last release with the [getLastRelease](#getlastrelease) plugin |
|
||||
| Analyze commits | Determine the type of release to do with the [analyzeCommits](#analyzecommits) plugin |
|
||||
| Verify release | Call the [verifyRelease](#verifyrelease) plugin |
|
||||
| Generate notes | Generate release notes with plugin [generateNotes](#generatenotes) |
|
||||
| Publish | Call the [publish](#publish) plugin |
|
||||
|
||||
## Default Commit Message Format
|
||||
|
||||
This module ships with the [AngularJS Commit Message Conventions](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit) and changelog generator, but you can [define your own](#plugins) style.
|
||||
|
||||
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
|
||||
format that includes a **type**, a **scope** and a **subject** ([full explanation](https://github.com/stevemao/conventional-changelog-angular/blob/master/convention.md)):
|
||||
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
<BLANK LINE>
|
||||
<body>
|
||||
<BLANK LINE>
|
||||
<footer>
|
||||
```
|
||||
|
||||
You can simplify using this convention for yourself and contributors by using [commitizen](https://github.com/commitizen/cz-cli) and [commitlint](https://github.com/marionebl/commitlint) or [semantic-git-commit-cli](https://github.com/JPeer264/node-semantic-git-commit-cli).
|
||||
|
||||
### Patch Release
|
||||
|
||||
```
|
||||
fix(pencil): stop graphite breaking when too much pressure applied
|
||||
```
|
||||
|
||||
### ~~Minor~~ Feature Release
|
||||
|
||||
```
|
||||
feat(pencil): add 'graphiteWidth' option
|
||||
```
|
||||
|
||||
### ~~Major~~ Breaking Release
|
||||
|
||||
```
|
||||
perf(pencil): remove graphiteWidth option
|
||||
|
||||
BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reasons.
|
||||
```
|
||||
|
||||
## Setup
|
||||
|
||||
[](https://nodei.co/npm/semantic-release/)
|
||||
|
||||
```bash
|
||||
npm install -g semantic-release-cli
|
||||
|
||||
cd your-module
|
||||
semantic-release-cli setup
|
||||
```
|
||||
|
||||
|
||||
|
||||
_[This is what happens under the hood.](https://github.com/semantic-release/cli#what-it-does)_
|
||||
|
||||
## Options
|
||||
|
||||
You can pass options either via command line (in [kebab-case](https://lodash.com/docs#kebabCase)) or in the `release` field of your `package.json` (in [camelCase](https://lodash.com/docs#camelCase)). Alternatively the configuration can also be defined in `.releaserc.yml`, `.releaserc.js`, `.releaserc.js` or `release.config.js`.
|
||||
|
||||
The following two examples are the same, but CLI arguments take precedence.
|
||||
|
||||
##### CLI
|
||||
```bash
|
||||
semantic-release --branch next
|
||||
```
|
||||
|
||||
##### package.json
|
||||
```json
|
||||
"release": {
|
||||
"branch": "next"
|
||||
}
|
||||
```
|
||||
```bash
|
||||
semantic-release
|
||||
```
|
||||
|
||||
These options are currently available:
|
||||
- `branch`: The branch on which releases should happen. Default: `'master'`
|
||||
- `repositoryUrl`: The git repository URL. Default: `repository` property in `package.json` or git origin url. Any valid git url format is supported (See [Git protocols](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols)). 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.
|
||||
- `dry-run`: Dry-run mode, skipping verifyConditions, publishing and release, printing next version and release notes
|
||||
- `extends`: Array of module or files path containing a shareable configuration. Options defined via CLI or in the `release` property will take precedence over the one defined in a shareable configuration.
|
||||
- `debug`: Output debugging information
|
||||
|
||||
_A few notes on `npm` config_:
|
||||
1. The `npm` token can only be defined in the environment as `NPM_TOKEN`, because that’s where `npm` itself is going to read it from.
|
||||
2. In order to publish to a different `npm` registry you can specify that inside the `package.json`’s [`publishConfig`](https://docs.npmjs.com/files/package.json#publishconfig) field.
|
||||
3. If you want to use another dist-tag for your publishes than `'latest'` you can specify that inside the `package.json`’s [`publishConfig`](https://docs.npmjs.com/files/package.json#publishconfig) field.
|
||||
|
||||
## Plugins
|
||||
|
||||
There are numerous steps where you can customize `semantic-release`’s behavior using plugins. A plugin is a regular [option](#options), but passed inside the `release` block of `package.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"release": {
|
||||
"analyzeCommits": "npm-module-name",
|
||||
"generateNotes": "./path/to/a/local/module",
|
||||
"verifyConditions": {
|
||||
"path": "./path/to/a/module",
|
||||
"additional": "config"
|
||||
},
|
||||
"globalPluginOptions": "globalConfig"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```bash
|
||||
semantic-release --analyze-commits="npm-module-name"
|
||||
```
|
||||
|
||||
**Note**: The plugin CLI arguments can be only used to override the plugins to use. Plugins options cannot be defined via CLI arguments and must be defined in the main configuration file or in a shareable config.
|
||||
|
||||
A plugin itself is an async function that always receives three arguments.
|
||||
|
||||
```js
|
||||
module.exports = function (pluginConfig, config, callback) {}
|
||||
```
|
||||
|
||||
- `pluginConfig`: If the user of your plugin specifies additional plugin config in the `package.json` (see the `verifyConditions` example above) then it’s this object. Options defined directly under `release` will be passed to each plugins. Options defined within a plugin will passed only to that instance of the plugin.
|
||||
- `config`: A config object containing a lot of information to act upon.
|
||||
- `options`: `semantic-release` options like `repositoryUrl`, or `branch`
|
||||
- For certain plugins the `config` object contains even more information. See below.
|
||||
|
||||
### `analyzeCommits`
|
||||
|
||||
This plugin is responsible for determining the type of the next release. It additionally receives a `commits` array inside `config`. One commit is an object with a `message` and `hash` property. Call the callback with `'major'`, `'premajor'`, `'minor'`, `'preminor'`, `'patch'`, `'prepatch'`, `'prerelease'`, or `null` if nothing changed.
|
||||
|
||||
While it may be tempting to use `'prepatch'`, `'preminor'` & `'prerelease'` as part of a release process, this is strongly discouraged. A better approach is to use [dist-tags](https://docs.npmjs.com/cli/dist-tag) to create release channels (such as 'latest', 'next', 'stable') and to return only `'major'`, `'premajor'` and `'minor'` from the commit analyzer.
|
||||
|
||||
Have a look at the [default implementation](https://github.com/semantic-release/commit-analyzer/).
|
||||
|
||||
### `verifyConditions`
|
||||
|
||||
This plugins is responsible for verifying that a release should happen in the first place.
|
||||
The default implementations are:
|
||||
- [travis](https://github.com/semantic-release/condition-travis/): verifies that the publish is happening on Travis, that it’s the right branch, and that all other build jobs succeeded.
|
||||
- [github](https://github.com/semantic-release/github/): verifies a Github authentication is set and valid.
|
||||
- [npm](https://github.com/semantic-release/npm/): verifies an npm authentication is set and valid.
|
||||
|
||||
Passing an array of plugins will run them in series.
|
||||
|
||||
### `verifyRelease`
|
||||
|
||||
This plugin is responsible for verifying a release that was determined before and is about to be published. There is no default implementation. It additionally receives `nextRelease`, `lastRelease` and `commits` inside `config`. While `commits` is the same as with analyzeCommits, `nextRelease` contains a `type` (e.g. `'major'`) and the new version (e.g. `'1.0.0'`) and `lastRelease` contains the old `version`, the `gitHead` at the time of the release and the npm dist-`tag` (e.g. `'latest'`). Using this information you could [detect breaking changes](https://github.com/semantic-release/cracks) or hold back certain types of releases. Again: Be creative.
|
||||
|
||||
Passing an array of plugins will run them in series.
|
||||
|
||||
### `getLastRelease`
|
||||
|
||||
This plugin is responsible for determining a package’s last release version. The [default implementation](https://github.com/semantic-release/last-release-npm) uses the last published version on a npm registry.
|
||||
|
||||
### `generateNotes`
|
||||
|
||||
This plugin is responsible for generating release notes. Call the callback with the notes as a string. Have a look at the [default implementation](https://github.com/semantic-release/release-notes-generator/).
|
||||
It receives a `commits` array, the `lastRelease` and `nextRelease` inside `config`.
|
||||
|
||||
### `publish`
|
||||
|
||||
This plugins is responsible for publishing the release. The default implementations publish on [npm](https://github.com/semantic-release/npm) and [github](https://github.com/semantic-release/github).
|
||||
|
||||
Passing an array of plugins will run them in series.
|
||||
|
||||
## ITYM*FAQ*LT
|
||||
> I think you might frequently ask questions like these
|
||||
|
||||
### Why is the `package.json`’s version not updated in my repository?
|
||||
|
||||
The `npm` docs even state:
|
||||
|
||||
> The most important things in your package.json are the name and version fields. Those are actually required, and your package won’t install without them.
|
||||
> – [npm docs](https://docs.npmjs.com/files/package.json#version)
|
||||
|
||||
While this entirely true the version number doesn’t have to be checked into source control. `semantic-release` takes care of the version field right before `npm publish` uses it – and this is the only point where it _really_ is required.
|
||||
|
||||
### Is there a way to preview which version would currently get published?
|
||||
|
||||
If you run `npm run semantic-release` locally a dry run gets performed, which logs the version that would currently get published.
|
||||
|
||||
### Can I run this on my own machine rather than on a CI server?
|
||||
|
||||
Of course you can, but this doesn’t necessarily mean you should. Running your tests on an independent machine before releasing software is a crucial part of this workflow. Also it is a pain to set this up locally, with tokens lying around and everything. That said, you can run the scripts with `--debug=false` explicitly. You have to export `GH_TOKEN=<your_token>` and `NPM_TOKEN=<your_other_token>`.
|
||||
|
||||
### Can I manually trigger the release of a specific version?
|
||||
|
||||
You can trigger a release by pushing to your GitHub repository. You deliberately cannot trigger a _specific_ version release, because this is the whole point of `semantic-release`. Start your packages with `1.0.0` and semver on.
|
||||
|
||||
### 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 making every passing feature or fix on your master branch addressable via `npm` you might not treat your master right. Have a look at [branch workflows](https://guides.github.com/introduction/flow/index.html). If you still think you should have control over the exact point in time of your release, e.g. because you are following a release schedule, you can release only on the `production`/`deploy`/`release` branch and push your code there in certain intervals, or better yet use [dist-tags](https://docs.npmjs.com/cli/dist-tag).
|
||||
|
||||
### Why should I trust `semantic-release` with my releases?
|
||||
|
||||
`semantic-release` has a full unit- and integration-test-suite that tests _actual_ `npm` publishes against the [npm-registry-couchapp](https://github.com/npm/npm-registry-couchapp/). A new version won’t get published if it doesn’t pass on all these engines.
|
||||
|
||||
### Why does `semantic-release` require node version >= 8
|
||||
|
||||
Being able to write code for just the most recent node versions greatly simplifies development. More language features are available, no transpilation is required, less test builds are to be run, awaited and debugged.
|
||||
|
||||
For a special purpose tool like `semantic-release`, that's only meant to be used in controlled CI environments, we think it's okay to have such a high version requirement. As `semantic-release` handles package publishing we expect almost every project to have at least one build job running node 8 already – and that's all it takes. Even if that's not that case `semantic-release` can still be executed with the help of [npx](https://www.npmjs.com/package/npx) (`npx -p node@8 npm run semantic-release`).
|
||||
|
||||
Please see our [Node Support Policy](#node-support-policy) for our long-term promise for supporting Node.
|
||||
### 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.
|
||||
|
||||
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 can be 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.
|
||||
|
||||
Here is an example of the release type that will be done based on a commit messages:
|
||||
|
||||
| Commit message | Release type |
|
||||
|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------|
|
||||
| `fix(pencil): stop graphite breaking when too much pressure applied` | Patch Release |
|
||||
| `feat(pencil): add 'graphiteWidth' option` | ~~Minor~~ Feature Release |
|
||||
| `perf(pencil): remove graphiteWidth option`<br><br>`BREAKING CHANGE: The graphiteWidth option has been removed.`<br>`The default graphite width of 10mm is always used for performance reasons.` | ~~Major~~ Breaking Release |
|
||||
|
||||
### 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).
|
||||
|
||||
### Triggering a release
|
||||
|
||||
When pushing new commits to the release branch (i.e. `master`) with `git push` or by merging a pull request or merging from another branch, a CI build is triggered and runs the `semantic-release` command to make a release if there is relevant codebase changes since the last release.
|
||||
|
||||
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.
|
||||
|
||||
### 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](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)
|
||||
- [Twitter](https://twitter.com/SemanticRelease)
|
||||
|
||||
## Badge
|
||||
|
||||
Use this in one of your projects? Include one of these badges in your README.md to let people know that your package is published using `semantic-release`.
|
||||
Let people know that your package is published using **semantic-release** by including this badge in your readme.
|
||||
|
||||
[](https://github.com/semantic-release/semantic-release)
|
||||
|
||||
@@ -303,35 +129,12 @@ Use this in one of your projects? Include one of these badges in your README.md
|
||||
[](https://github.com/semantic-release/semantic-release)
|
||||
```
|
||||
|
||||
[](https://github.com/semantic-release/semantic-release)
|
||||
## Team
|
||||
|
||||
```md
|
||||
[](https://github.com/semantic-release/semantic-release)
|
||||
```
|
||||
| [](https://github.com/boennemann) | [](https://github.com/relekang) | [](https://github.com/jo) | [](https://github.com/gr2m) | [](https://github.com/finnp) | [](https://github.com/pvdlg) | [](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://github.com/semantic-release/semantic-release)
|
||||
|
||||
```md
|
||||
[](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.
|
||||
|
||||
## License
|
||||
|
||||
MIT License
|
||||
2015 © Stephan Bönnemann and [contributors](https://github.com/semantic-release/semantic-release/graphs/contributors)
|
||||
|
||||
[](https://twitter.com/trodrigues/status/509301317467373571)
|
||||
<p align="center">
|
||||
<img alt="Kill all humans" src="media/bender.png">
|
||||
</p>
|
||||
|
||||
+39
@@ -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)
|
||||
@@ -1,34 +0,0 @@
|
||||
# Troubleshooting semantic-release
|
||||
|
||||
### ENOTINHISTORY Commit not in history
|
||||
|
||||
```
|
||||
semantic-release ERR! commits The commit the last release of this package was derived from is not in the direct history of the "master" branch.
|
||||
semantic-release ERR! commits This means semantic-release can not extract the commits between now and then.
|
||||
semantic-release ERR! commits This is usually caused by force pushing, releasing from an unrelated branch, or using an already existing package name.
|
||||
semantic-release ERR! commits You can recover from this error by publishing manually or restoring the commit "123".
|
||||
semantic-release ERR! pre Failed to determine new version.
|
||||
semantic-release ERR! pre ENOTINHISTORY Commit not in history
|
||||
```
|
||||
|
||||
To restore semantic-release, follow these steps:
|
||||
|
||||
```
|
||||
git pull
|
||||
git reset --hard origin/master
|
||||
npm version x.y.z # check your current version and set this based on semver rules manually
|
||||
|
||||
# if you have a PR workflow, create a new branch, otherwise commit to master
|
||||
|
||||
git checkout -B chore/release
|
||||
git commit -am 'chore: release'
|
||||
git push
|
||||
|
||||
# merge (not squash-merge) on github (this is important before running git push). This is only required when you work with branches
|
||||
git checkout master
|
||||
|
||||
# definitely required
|
||||
git pull
|
||||
git push --tags
|
||||
npm publish
|
||||
```
|
||||
+6
-12
@@ -3,22 +3,16 @@
|
||||
// Bad news: We have to write plain ES5 in this file
|
||||
// Good news: It's the only file of the entire project
|
||||
|
||||
// eslint-disable-next-line no-var
|
||||
/* eslint-disable no-var */
|
||||
|
||||
var semver = require('semver');
|
||||
var pkg = require('../package.json');
|
||||
|
||||
if (semver.lt(process.version, '8.0.0')) {
|
||||
if (!semver.satisfies(process.version, pkg.engines.node)) {
|
||||
console.error(
|
||||
`semantic-release: node version >= 8 is required. Found ${process.version}.
|
||||
`[semantic-release]: node version ${pkg.engines.node} is required. Found ${process.version}.
|
||||
|
||||
If there is another job running on node version >= 8, it will be picked as
|
||||
the build leader and you can safely ignore this message.
|
||||
|
||||
If you don't have node 8 in your build matrix you can use "npx" to restore
|
||||
compatibility with minimal overhead:
|
||||
|
||||
$ npx -p node@8 npm run semantic-release
|
||||
|
||||
npx is bundled with npm >= 5.4, or available via npm. More info: npm.im/npx`
|
||||
See https://github.com/semantic-release/semantic-release/blob/caribou/docs/support/node-version.md for more details and solutions.`
|
||||
);
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"plugins" : ["github", "anchors"],
|
||||
"pluginsConfig": {
|
||||
"github": {
|
||||
"url": "https://github.com/semantic-release/semantic-release"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -27,6 +27,10 @@ module.exports = async () => {
|
||||
)
|
||||
.option('--generate-notes <path>', 'Path or package name for the generateNotes plugin')
|
||||
.option('--publish <paths>', 'Comma separated list of paths or packages name for the publish plugin(s)', list)
|
||||
.option(
|
||||
'--no-ci',
|
||||
'Skip Continuous Integration environment verifications, allowing to make releases from a local machine'
|
||||
)
|
||||
.option('--debug', 'Output debugging information')
|
||||
.option(
|
||||
'-d, --dry-run',
|
||||
@@ -48,12 +52,10 @@ module.exports = async () => {
|
||||
await require('.')(pickBy(program.opts(), value => !isUndefined(value)));
|
||||
}
|
||||
} catch (err) {
|
||||
// If error is a SemanticReleaseError then it's an expected exception case (no release to be done, running on a PR etc..) and the cli will return with 0
|
||||
// Otherwise it's an unexpected error (configuration issue, code issue, plugin issue etc...) and the cli will return 1
|
||||
process.exitCode = 1;
|
||||
if (err.semanticRelease) {
|
||||
logger.log(`%s ${err.message}`, err.code);
|
||||
} else {
|
||||
process.exitCode = 1;
|
||||
logger.error('An error occurred while running semantic-release: %O', err);
|
||||
}
|
||||
}
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
# semantic-release documentation
|
||||
|
||||
- [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
|
||||
@@ -0,0 +1,4 @@
|
||||
# Developer guide
|
||||
|
||||
- [Plugins](plugin.md)
|
||||
- [Shareable configuration](shareable-configuration.md)
|
||||
@@ -0,0 +1 @@
|
||||
# Plugin developer guide
|
||||
@@ -0,0 +1 @@
|
||||
# Shareable configuration developer guide
|
||||
@@ -0,0 +1,4 @@
|
||||
# Extending semantic-release
|
||||
|
||||
- [Plugins list](plugins-list.md)
|
||||
- [Shareable configuration list](shareable-configurations-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
|
||||
@@ -0,0 +1,7 @@
|
||||
# Shareable configurations list
|
||||
|
||||
## Official configurations
|
||||
- [@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
|
||||
@@ -0,0 +1,9 @@
|
||||
# Recipes
|
||||
|
||||
## CI configurations
|
||||
- [CircleCI 2.0 workflows](circleci-workflows.md)
|
||||
- [Travis CI](travis.md)
|
||||
- [Travis CI with build stages](travis-build-stages.md)
|
||||
- [GitLab CI](gitlab-ci.md)
|
||||
|
||||
## Package managers and languages
|
||||
@@ -0,0 +1 @@
|
||||
# CircleCI 2.0 workflows
|
||||
@@ -0,0 +1,71 @@
|
||||
# Using semantic-release with [GitLab CI](https://about.gitlab.com/features/gitlab-ci-cd)
|
||||
|
||||
## Environment 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](../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.
|
||||
|
||||
**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
|
||||
stages:
|
||||
- test
|
||||
- release
|
||||
|
||||
before_script:
|
||||
- npm install
|
||||
|
||||
node:4:
|
||||
image: node:4
|
||||
stage: test
|
||||
script:
|
||||
- npm test
|
||||
|
||||
node:6:
|
||||
image: node:6
|
||||
stage: test
|
||||
script:
|
||||
- npm test
|
||||
|
||||
node:8:
|
||||
image: node:8
|
||||
stage: test
|
||||
script:
|
||||
- npm test
|
||||
|
||||
publish:
|
||||
image: node:8
|
||||
stage: release
|
||||
script:
|
||||
# Only for a local semantic-release installation
|
||||
- npm run semantic-release
|
||||
|
||||
# Only for a global semantic-release installation
|
||||
- npm install -g semantic-release
|
||||
- semantic-release
|
||||
```
|
||||
|
||||
### `package.json` configuration
|
||||
|
||||
A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation.
|
||||
|
||||
```json
|
||||
{
|
||||
"devDependencies": {
|
||||
"semantic-release": "^12.0.0"
|
||||
},
|
||||
"scripts": {
|
||||
"semantic-release": "semantic-release"
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1 @@
|
||||
# Using semantic-release with [Travis CI build stages](https://docs.travis-ci.com/user/build-stages)
|
||||
@@ -0,0 +1,151 @@
|
||||
# Using semantic-release with [Travis CI](https://travis-ci.org)
|
||||
|
||||
## Environment variables
|
||||
|
||||
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](../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](../support/FAQ.md#why-does-semantic-release-require-node-version--8).
|
||||
|
||||
### `.travis.yml` configuration for single Node job
|
||||
|
||||
This example is a minimal configuration for semantic-release with a build running Node 8 on Linux. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
|
||||
|
||||
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](../usage/installation.md#local-installation) or [global](../usage/installation.md#global-installation) semantic-release installation.
|
||||
|
||||
```yaml
|
||||
language: node_js
|
||||
|
||||
node_js: 8
|
||||
|
||||
script:
|
||||
# Run tests
|
||||
- npm run test
|
||||
|
||||
# Only for a local semantic-release installation
|
||||
- npm run semantic-release
|
||||
|
||||
# Only for a global semantic-release installation
|
||||
- npm install -g semantic-release
|
||||
- semantic-release
|
||||
```
|
||||
|
||||
### `package.json` configuration for single Node job
|
||||
|
||||
A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation.
|
||||
|
||||
```json
|
||||
{
|
||||
"devDependencies": {
|
||||
"semantic-release": "^11.0.0"
|
||||
},
|
||||
"scripts": {
|
||||
"semantic-release": "semantic-release"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Multiple Node jobs configuration
|
||||
|
||||
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](../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 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](../usage/installation.md#local-installation) or [global](../usage/installation.md#global-installation) **semantic-release** installation.
|
||||
|
||||
```yaml
|
||||
language: node_js
|
||||
|
||||
node_js:
|
||||
- 8
|
||||
- 6
|
||||
- 4
|
||||
|
||||
os:
|
||||
- linux
|
||||
- osx
|
||||
|
||||
script:
|
||||
# Run tests
|
||||
- npm run test
|
||||
|
||||
# Only for a local semantic-release installation
|
||||
- npm run travis-deploy-once "npm run semantic-release"
|
||||
|
||||
# Only for a global semantic-release installation
|
||||
- npm install -g travis-deploy-once semantic-release
|
||||
- travis-deploy-once "semantic-release"
|
||||
```
|
||||
|
||||
**Note**: See the `travis-deploy-once` [`pro`](https://github.com/semantic-release/travis-deploy-once#-p---pro) and [`travis-url`](https://github.com/semantic-release/travis-deploy-once#-u---travis-url) options for using with [Travis Pro](https://docs.travis-ci.com/user/travis-pro) and [Travis Enterprise](https://enterprise.travis-ci.com).
|
||||
|
||||
### `package.json` configuration for multiple Node jobs
|
||||
|
||||
A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation.
|
||||
|
||||
```json
|
||||
{
|
||||
"devDependencies": {
|
||||
"semantic-release": "^12.0.0",
|
||||
"travis-deploy-once": "^4.0.0"
|
||||
},
|
||||
"scripts": {
|
||||
"semantic-release": "semantic-release",
|
||||
"travis-deploy-once": "travis-deploy-once"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Non-JavaScript projects configuration
|
||||
|
||||
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](../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](../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.
|
||||
|
||||
```yaml
|
||||
language: go
|
||||
|
||||
go:
|
||||
- 1.6
|
||||
- 1.7
|
||||
|
||||
os:
|
||||
- linux
|
||||
- osx
|
||||
|
||||
script:
|
||||
# Run tests
|
||||
- go test -v ./...
|
||||
|
||||
# Use nvm to install and use the Node LTS version (nvm is installed on Travis images)
|
||||
- nvm install lts/*
|
||||
# Install travis-deploy-once and semantic-release
|
||||
- npm install -g travis-deploy-once semantic-release
|
||||
# Run semantic-release only on job, after all other are successful
|
||||
- travis-deploy-once "semantic-release"
|
||||
```
|
||||
|
||||
**Note**: See the `travis-deploy-once` [`pro`](https://github.com/semantic-release/travis-deploy-once#-p---pro) and [`travis-url`](https://github.com/semantic-release/travis-deploy-once#-u---travis-url) options for using with [Travis Pro](https://docs.travis-ci.com/user/travis-pro) and [Travis Enterprise](https://enterprise.travis-ci.com).
|
||||
@@ -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)
|
||||
@@ -0,0 +1,158 @@
|
||||
# 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 on jobs running with Node < 8 as **semantic-release** requires [Node >= 8.3](#why-does-semantic-release-require-node-version--83) and specifies it in its `package.json`s [`engines`](https://docs.npmjs.com/files/package.json#engines) key.
|
||||
|
||||
The recommended solution is to use the [Yarn](https://yarnpkg.com) [--ignore-engines](https://yarnpkg.com/en/docs/cli/install#toc-yarn-install-ignore-engines) option to install the project dependencies on the CI environment, so Yarn will ignore the **semantic-release**'s `engines` key:
|
||||
|
||||
```bash
|
||||
$ yarn install --ignore-engines
|
||||
```
|
||||
|
||||
**Note**: Several CI services use Yarn by default if your repository contains a `yarn.lock` file. So you should override the install step to specify `yarn install --ignore-engines`.
|
||||
|
||||
Alternatively you can use a [global](../usage/installation.md#global-installation) **semantic-release** installation and make sure to install and run the `semantic-release` command only in a CI jobs running with Node >= 8.3.
|
||||
|
||||
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-Node package (without a `package.json`) 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--83) 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=<your_npm_token> GH_TOKEN=<your_github_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.
|
||||
|
||||
### Can I exclude commits from the analysis?
|
||||
|
||||
Yes, every commits that contains `[skip release]` or `[release skip]` in their message will be excluded from the commit analysis and won't participate in the release type determination.
|
||||
|
||||
## 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.3?
|
||||
|
||||
**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.3 or higher**.
|
||||
|
||||
See [Node version requirement](../support/node-version.md#node-version-requirement) for more details and solutions.
|
||||
@@ -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)
|
||||
@@ -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.
|
||||
@@ -0,0 +1,52 @@
|
||||
# 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.3 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](node-support-policy.md) for our long-term promise regarding Node version support.
|
||||
|
||||
## Recommended solution
|
||||
|
||||
### Run at least one CI job with Node >= 8.3
|
||||
|
||||
The recommended approach is to run the `semantic-release` command from a CI job running on Node 8.3 or higher. This can either be a job used by your project to test on Node >= 8.3 or a dedicated job for the release steps.
|
||||
|
||||
See [CI configuration](../usage/ci-configuration.md) and [CI configuration recipes](../recipes/README.md#ci-configurations) for more details.
|
||||
|
||||
## Alternative solutions
|
||||
|
||||
### Use `npx`
|
||||
|
||||
[`npx`](https://github.com/zkat/npx) is a CLI to execute npm binaries. It is bundled with [npm](https://www.npmjs.com/package/npm) >= 5.4, or can be installed via `npm install -g npx`.
|
||||
|
||||
`npx` can be used to download the latest [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](../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](../usage/installation.md#global-installation) **semantic-release** installation:
|
||||
|
||||
```bash
|
||||
# For global semantic-release install
|
||||
$ npm install -g semantic-release npx && npx -p node@8 -c "semantic-release"
|
||||
```
|
||||
|
||||
### Use `nvm`
|
||||
|
||||
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](../usage/installation.md#local-installation) **semantic-release** installation:
|
||||
|
||||
```bash
|
||||
$ nvm install 8 && npm run semantic-release
|
||||
```
|
||||
|
||||
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
|
||||
```
|
||||
@@ -0,0 +1,31 @@
|
||||
# Troubleshooting
|
||||
|
||||
## ENOTINHISTORY Commit not in history
|
||||
|
||||
This error happens when the commit associated with the last release cannot be found in the branch history.
|
||||
|
||||
Multiple situation can cause this issue:
|
||||
- The package name configured in your `package.json` already exists and **semantic-release** obtains the last release of that package, which is unrelated to yours
|
||||
- The commit history has been rewritten since the last release (with `git rebase` and `git push -f`)
|
||||
|
||||
If the package name configured in your `package.json` already exits, you should change it, and commit the `package.json`. Then **semantic-release** will proceed normally and make the initial release.
|
||||
|
||||
If you can identify the commit in your branch history that should be associated with the release version mentioned in the error message you can recover by tagging this commit:
|
||||
|
||||
```bash
|
||||
$ git tag -f v<version of the last release> <commit sha1 corresponding to last release>
|
||||
$ git push -f --tags origin <your release branch>
|
||||
```
|
||||
|
||||
## ENOGITHEAD There is no commit associated with last release
|
||||
|
||||
This error happens when there is no commit associated with the last release that can be found in the package metadata on the npm registry.
|
||||
|
||||
This usually happen when the last release has been made without access to the git repository informations.
|
||||
|
||||
You can recover from that issue by identifying the commit in your branch history that should have been associated with the release version mentioned in the error message and tagging this commit:
|
||||
|
||||
```bash
|
||||
$ git tag -f v<version of the last release> <commit sha1 corresponding to last release>
|
||||
$ git push -f --tags origin <your release branch>
|
||||
```
|
||||
@@ -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)
|
||||
@@ -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).<br/>**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.<br/>**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
|
||||
```
|
||||
|
||||
|
||||
|
||||
See the [semantic-release-cli](https://github.com/semantic-release/cli#what-it-does) documentation for more details.
|
||||
@@ -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.
|
||||
@@ -0,0 +1,33 @@
|
||||
# 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
|
||||
```
|
||||
**Note:**: For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with with `npm install -g semantic-release@12`). This way your build will not automatically use the next major **semantic-release** release that could possibly break your build. You will have to upgrade manually when a new major version is released.
|
||||
@@ -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
|
||||
@@ -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.
|
||||
@@ -1,6 +1,6 @@
|
||||
const marked = require('marked');
|
||||
const TerminalRenderer = require('marked-terminal');
|
||||
const SemanticReleaseError = require('@semantic-release/error');
|
||||
const envCi = require('env-ci');
|
||||
const getConfig = require('./lib/get-config');
|
||||
const getNextVersion = require('./lib/get-next-version');
|
||||
const getCommits = require('./lib/get-commits');
|
||||
@@ -8,19 +8,39 @@ const logger = require('./lib/logger');
|
||||
const {gitHead: getGitHead, isGitRepo} = require('./lib/git');
|
||||
|
||||
module.exports = async opts => {
|
||||
const {isCi, branch, isPr} = envCi();
|
||||
|
||||
if (!isCi && !opts.dryRun && !opts.noCi) {
|
||||
logger.log('This run was not triggered in a known CI environment, running in dry-run mode.');
|
||||
opts.dryRun = true;
|
||||
}
|
||||
|
||||
if (isCi && isPr && !opts.noCi) {
|
||||
logger.log("This run was triggered by a pull request and therefore a new version won't be published.");
|
||||
return;
|
||||
}
|
||||
|
||||
if (!await isGitRepo()) {
|
||||
throw new SemanticReleaseError('Semantic-release must run from a git repository', 'ENOGITREPO');
|
||||
logger.error('Semantic-release must run from a git repository.');
|
||||
return;
|
||||
}
|
||||
|
||||
const config = await getConfig(opts, logger);
|
||||
const {plugins, options} = config;
|
||||
|
||||
if (branch !== options.branch) {
|
||||
logger.log(
|
||||
`This test run was triggered on the branch ${branch}, while semantic-release is configured to only publish from ${
|
||||
options.branch
|
||||
}, therefore a new version won’t be published.`
|
||||
);
|
||||
return;
|
||||
}
|
||||
|
||||
logger.log('Run automated release from branch %s', options.branch);
|
||||
|
||||
if (!options.dryRun) {
|
||||
logger.log('Call plugin %s', 'verify-conditions');
|
||||
await plugins.verifyConditions({options, logger});
|
||||
}
|
||||
logger.log('Call plugin %s', 'verify-conditions');
|
||||
await plugins.verifyConditions({options, logger});
|
||||
|
||||
logger.log('Call plugin %s', 'get-last-release');
|
||||
const {commits, lastRelease} = await getCommits(
|
||||
@@ -30,9 +50,15 @@ module.exports = async opts => {
|
||||
);
|
||||
|
||||
logger.log('Call plugin %s', 'analyze-commits');
|
||||
const type = await plugins.analyzeCommits({options, logger, lastRelease, commits});
|
||||
const type = await plugins.analyzeCommits({
|
||||
options,
|
||||
logger,
|
||||
lastRelease,
|
||||
commits: commits.filter(commit => !/\[skip\s+release\]|\[release\s+skip\]/i.test(commit.message)),
|
||||
});
|
||||
if (!type) {
|
||||
throw new SemanticReleaseError('There are no relevant changes, so no new version is released.', 'ENOCHANGE');
|
||||
logger.log('There are no relevant changes, so no new version is released.');
|
||||
return;
|
||||
}
|
||||
const version = getNextVersion(type, lastRelease, logger);
|
||||
const nextRelease = {type, version, gitHead: await getGitHead(), gitTag: `v${version}`};
|
||||
@@ -67,4 +93,5 @@ module.exports = async opts => {
|
||||
});
|
||||
logger.log('Published release: %s', nextRelease.version);
|
||||
}
|
||||
return true;
|
||||
};
|
||||
|
||||
+22
-27
@@ -1,8 +1,8 @@
|
||||
const gitLogParser = require('git-log-parser');
|
||||
const getStream = require('get-stream');
|
||||
const debug = require('debug')('semantic-release:get-commits');
|
||||
const {unshallow} = require('./git');
|
||||
const getVersionHead = require('./get-version-head');
|
||||
const SemanticReleaseError = require('@semantic-release/error');
|
||||
const {unshallow, gitCommitTag, gitTagHead, isCommitInHistory} = require('./git');
|
||||
|
||||
/**
|
||||
* Commit message.
|
||||
@@ -44,22 +44,28 @@ const getVersionHead = require('./get-version-head');
|
||||
* @return {Promise<Result>} The list of commits on the branch `branch` since the last release and the updated lastRelease with the gitHead used to retrieve the commits.
|
||||
*
|
||||
* @throws {SemanticReleaseError} with code `ENOTINHISTORY` if `lastRelease.gitHead` or the commit sha derived from `config.lastRelease.version` is not in the direct history of `branch`.
|
||||
* @throws {SemanticReleaseError} with code `ENOGITHEAD` if `lastRelease.gitHead` is undefined and no commit sha can be found for the `config.lastRelease.version`.
|
||||
*/
|
||||
module.exports = async ({version, gitHead} = {}, branch, logger) => {
|
||||
let gitTag;
|
||||
if (gitHead || version) {
|
||||
try {
|
||||
({gitHead, gitTag} = await getVersionHead(gitHead, version, branch));
|
||||
} catch (err) {
|
||||
if (err.code === 'ENOTINHISTORY') {
|
||||
logger.error(notInHistoryMessage(err.gitHead, branch, version));
|
||||
} else {
|
||||
logger.error(noGitHeadMessage(branch, version));
|
||||
}
|
||||
throw err;
|
||||
if (gitHead) {
|
||||
// If gitHead doesn't exists in release branch
|
||||
if (!await isCommitInHistory(gitHead)) {
|
||||
// Unshallow the repository
|
||||
await unshallow();
|
||||
}
|
||||
logger.log('Retrieving commits since %s, corresponding to version %s', gitHead, version);
|
||||
// If gitHead still doesn't exists in release branch
|
||||
if (!await isCommitInHistory(gitHead)) {
|
||||
// Try to find the commit corresponding to the version, using got tags
|
||||
const tagHead = (await gitTagHead(`v${version}`)) || (await gitTagHead(version));
|
||||
|
||||
// If tagHead doesn't exists in release branch
|
||||
if (!tagHead || !await isCommitInHistory(tagHead)) {
|
||||
// Then the commit corresponding to the version cannot be found in the bracnh hsitory
|
||||
logger.error(notInHistoryMessage(gitHead, branch, version));
|
||||
throw new SemanticReleaseError('Commit not in history', 'ENOTINHISTORY');
|
||||
}
|
||||
gitHead = tagHead;
|
||||
}
|
||||
debug('Use gitHead: %s', gitHead);
|
||||
} else {
|
||||
logger.log('No previous release found, retrieving all commits');
|
||||
// If there is no gitHead nor a version, there is no previous release. Unshallow the repo in order to retrieve all commits
|
||||
@@ -76,20 +82,9 @@ module.exports = async ({version, gitHead} = {}, branch, logger) => {
|
||||
);
|
||||
logger.log('Found %s commits since last release', commits.length);
|
||||
debug('Parsed commits: %o', commits);
|
||||
return {commits, lastRelease: {version, gitHead, gitTag}};
|
||||
return {commits, lastRelease: {version, gitHead, gitTag: await gitCommitTag(gitHead)}};
|
||||
};
|
||||
|
||||
function noGitHeadMessage(branch, version) {
|
||||
return `The commit the last release of this package was derived from cannot be determined from the release metadata nor from the repository tags.
|
||||
This means semantic-release can not extract the commits between now and then.
|
||||
This is usually caused by releasing from outside the repository directory or with innaccessible git metadata.
|
||||
|
||||
You can recover from this error by creating a tag for the version "${version}" on the commit corresponding to this release:
|
||||
$ git tag -f v${version} <commit sha1 corresponding to last release>
|
||||
$ git push -f --tags origin ${branch}
|
||||
`;
|
||||
}
|
||||
|
||||
function notInHistoryMessage(gitHead, branch, version) {
|
||||
return `The commit the last release of this package was derived from is not in the direct history of the "${branch}" branch.
|
||||
This means semantic-release can not extract the commits between now and then.
|
||||
|
||||
@@ -1,52 +0,0 @@
|
||||
const debug = require('debug')('semantic-release:get-version-head');
|
||||
const SemanticReleaseError = require('@semantic-release/error');
|
||||
const {gitTagHead, gitCommitTag, isCommitInHistory, unshallow} = require('./git');
|
||||
|
||||
/**
|
||||
* Get the commit sha for a given version, if it's contained in the given branch.
|
||||
*
|
||||
* @param {string} gitHead The commit sha to look for.
|
||||
* @param {string} version The version corresponding to the commit sha to look for. Used to search in git tags.
|
||||
*
|
||||
* @return {Promise<Object>} A Promise that resolves to an object with the `gitHead` and `gitTag` for the the `version`.
|
||||
*
|
||||
* @throws {SemanticReleaseError} with code `ENOTINHISTORY` if `gitHead` or the commit sha dereived from `version` is not in the direct history of `branch`.
|
||||
* @throws {SemanticReleaseError} with code `ENOGITHEAD` if `gitHead` is undefined and no commit sha can be found for the `version`.
|
||||
*/
|
||||
module.exports = async (gitHead, version) => {
|
||||
// Check if gitHead is defined and exists in release branch
|
||||
if (gitHead && (await isCommitInHistory(gitHead))) {
|
||||
debug('Use gitHead: %s', gitHead);
|
||||
return {gitHead, gitTag: await gitCommitTag(gitHead)};
|
||||
}
|
||||
|
||||
await unshallow();
|
||||
|
||||
// Check if gitHead is defined and exists in release branch again
|
||||
if (gitHead && (await isCommitInHistory(gitHead))) {
|
||||
debug('Use gitHead: %s', gitHead);
|
||||
return {gitHead, gitTag: await gitCommitTag(gitHead)};
|
||||
}
|
||||
|
||||
let tagHead;
|
||||
if (version) {
|
||||
// If a version is defined search a corresponding tag
|
||||
tagHead = (await gitTagHead(`v${version}`)) || (await gitTagHead(version));
|
||||
|
||||
// Check if tagHead is found and exists in release branch again
|
||||
if (tagHead && (await isCommitInHistory(tagHead))) {
|
||||
debug('Use tagHead: %s', tagHead);
|
||||
return {gitHead: tagHead, gitTag: await gitCommitTag(tagHead)};
|
||||
}
|
||||
}
|
||||
|
||||
// Either gitHead is defined or a tagHead has been found but none is in the branch history
|
||||
if (gitHead || tagHead) {
|
||||
const error = new SemanticReleaseError('Commit not in history', 'ENOTINHISTORY');
|
||||
error.gitHead = gitHead || tagHead;
|
||||
throw error;
|
||||
}
|
||||
|
||||
// There is no gitHead in the last release and there is no tags correponsing to the last release version
|
||||
throw new SemanticReleaseError('There is no commit associated with last release', 'ENOGITHEAD');
|
||||
};
|
||||
+2
-2
@@ -25,7 +25,7 @@ async function gitTagHead(tagName) {
|
||||
*
|
||||
* @param {string} gitHead The commit sha for which to retrieve the associated tag.
|
||||
*
|
||||
* @return {string} The tag associatedwith the sha in parameter or `null`.
|
||||
* @return {string} The tag associatedwith the sha in parameter or `undefined`.
|
||||
*/
|
||||
async function gitCommitTag(gitHead) {
|
||||
try {
|
||||
@@ -34,7 +34,7 @@ async function gitCommitTag(gitHead) {
|
||||
return shell.stdout;
|
||||
} catch (err) {
|
||||
debug(err);
|
||||
return null;
|
||||
return undefined;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ const validatePluginConfig = conf => isString(conf) || isString(conf.path) || is
|
||||
|
||||
module.exports = {
|
||||
verifyConditions: {
|
||||
default: ['@semantic-release/npm', '@semantic-release/github', '@semantic-release/condition-travis'],
|
||||
default: ['@semantic-release/npm', '@semantic-release/github'],
|
||||
config: {
|
||||
validator: conf => !conf || (isArray(conf) ? conf : [conf]).every(conf => validatePluginConfig(conf)),
|
||||
message:
|
||||
@@ -24,9 +24,9 @@ module.exports = {
|
||||
validator: output =>
|
||||
!output ||
|
||||
(isObject(output) && !output.version) ||
|
||||
(isString(output.version) && Boolean(semver.valid(semver.clean(output.version)))),
|
||||
(isString(output.version) && Boolean(semver.valid(semver.clean(output.version))) && Boolean(output.gitHead)),
|
||||
message:
|
||||
'The "getLastRelease" plugin output if defined, must be an object with an optionnal valid semver version in the "version" property.',
|
||||
'The "getLastRelease" plugin output if defined, must be an object with a valid semver version in the "version" property and the corresponding git reference in "gitHead" property.',
|
||||
},
|
||||
},
|
||||
analyzeCommits: {
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 142 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 117 KiB |
+13
-9
@@ -14,22 +14,26 @@
|
||||
"path": "cz-conventional-changelog"
|
||||
}
|
||||
},
|
||||
"contributors": [
|
||||
"Gregor Martynus (https://twitter.com/gr2m)",
|
||||
"Pierre Vanduynslager (https://twitter.com/@pvdlg_)"
|
||||
],
|
||||
"dependencies": {
|
||||
"@semantic-release/commit-analyzer": "^5.0.0",
|
||||
"@semantic-release/condition-travis": "^7.0.0",
|
||||
"@semantic-release/error": "^2.1.0",
|
||||
"@semantic-release/github": "^3.0.0",
|
||||
"@semantic-release/github": "^3.0.1",
|
||||
"@semantic-release/npm": "^2.0.0",
|
||||
"@semantic-release/release-notes-generator": "^6.0.0",
|
||||
"chalk": "^2.3.0",
|
||||
"commander": "^2.11.0",
|
||||
"cosmiconfig": "^3.1.0",
|
||||
"cosmiconfig": "^4.0.0",
|
||||
"debug": "^3.1.0",
|
||||
"execa": "^0.8.0",
|
||||
"env-ci": "^1.0.0",
|
||||
"execa": "^0.9.0",
|
||||
"get-stream": "^3.0.0",
|
||||
"git-log-parser": "^1.2.0",
|
||||
"lodash": "^4.0.0",
|
||||
"marked": "^0.3.6",
|
||||
"lodash": "^4.17.4",
|
||||
"marked": "^0.3.9",
|
||||
"marked-terminal": "^2.0.0",
|
||||
"p-reduce": "^1.0.0",
|
||||
"read-pkg-up": "^3.0.0",
|
||||
@@ -53,18 +57,18 @@
|
||||
"nock": "^9.0.2",
|
||||
"nyc": "^11.2.1",
|
||||
"p-retry": "^1.0.0",
|
||||
"prettier": "~1.9.2",
|
||||
"prettier": "~1.10.0",
|
||||
"proxyquire": "^1.8.0",
|
||||
"sinon": "^4.0.0",
|
||||
"tempy": "^0.2.1",
|
||||
"xo": "^0.18.2"
|
||||
},
|
||||
"engines": {
|
||||
"node": ">=4",
|
||||
"npm": ">=2"
|
||||
"node": ">=8.3"
|
||||
},
|
||||
"files": [
|
||||
"bin",
|
||||
"docs",
|
||||
"lib",
|
||||
"index.js",
|
||||
"cli.js"
|
||||
|
||||
@@ -180,7 +180,7 @@ test.serial('Get all commits since gitHead (from tag) ', async t => {
|
||||
commits = (await gitCommits(['Second', 'Third'])).concat(commits);
|
||||
|
||||
// Retrieve the commits with the commits module, since commit 'First' (associated with tag v1.0.0)
|
||||
const result = await getCommits({version: '1.0.0'}, 'master', t.context.logger);
|
||||
const result = await getCommits({version: '1.0.0', gitHead: 'missing_ref'}, 'master', t.context.logger);
|
||||
|
||||
// Verify the commits created and retrieved by the module are identical
|
||||
t.is(result.commits.length, 2);
|
||||
@@ -214,7 +214,7 @@ test.serial('Get all commits since gitHead (from tag) on a detached head repo',
|
||||
await gitDetachedHead(repo, commits[1].hash);
|
||||
|
||||
// Retrieve the commits with the commits module, since commit 'First' (associated with tag 1.0.0)
|
||||
const result = await getCommits({version: '1.0.0'}, 'master', t.context.logger);
|
||||
const result = await getCommits({version: '1.0.0', gitHead: 'missing_ref'}, 'master', t.context.logger);
|
||||
|
||||
// Verify the module retrieved only the commit 'feat: Second' (included in the detached and after 'fix: First')
|
||||
t.is(result.commits.length, 1);
|
||||
@@ -241,7 +241,7 @@ test.serial('Get all commits since gitHead (from tag formatted like v<version>)
|
||||
commits = (await gitCommits(['Second', 'Third'])).concat(commits);
|
||||
|
||||
// Retrieve the commits with the commits module, since commit 'First' (associated with tag v1.0.0)
|
||||
const result = await getCommits({version: '1.0.0'}, 'master', t.context.logger);
|
||||
const result = await getCommits({version: '1.0.0', gitHead: 'missing_ref'}, 'master', t.context.logger);
|
||||
|
||||
// Verify the commits created and retrieved by the module are identical
|
||||
t.is(result.commits.length, 2);
|
||||
@@ -261,40 +261,7 @@ test.serial('Get all commits since gitHead (from tag formatted like v<version>)
|
||||
t.is(result.lastRelease.gitTag, 'v1.0.0');
|
||||
t.is(result.lastRelease.version, '1.0.0');
|
||||
});
|
||||
|
||||
test.serial('Get commits when last release gitHead is missing but a tag match the version', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
await gitRepo();
|
||||
// Add commits to the master branch
|
||||
let commits = await gitCommits(['First']);
|
||||
// Create the tag corresponding to version 1.0.0
|
||||
await gitTagVersion('v1.0.0');
|
||||
// Add new commits to the master branch
|
||||
commits = (await gitCommits(['Second', 'Third'])).concat(commits);
|
||||
|
||||
// Retrieve the commits with the commits module, since commit 'First' (associated with tag v1.0.0)
|
||||
const result = await getCommits({version: '1.0.0', gitHead: 'missing'}, 'master', t.context.logger);
|
||||
|
||||
// Verify the commits created and retrieved by the module are identical
|
||||
t.is(result.commits.length, 2);
|
||||
t.is(result.commits[0].hash.substring(0, 7), commits[0].hash);
|
||||
t.is(result.commits[0].message, commits[0].message);
|
||||
t.truthy(result.commits[0].committerDate);
|
||||
t.truthy(result.commits[0].author.name);
|
||||
t.truthy(result.commits[0].committer.name);
|
||||
t.is(result.commits[1].hash.substring(0, 7), commits[1].hash);
|
||||
t.is(result.commits[1].message, commits[1].message);
|
||||
t.truthy(result.commits[1].committerDate);
|
||||
t.truthy(result.commits[1].author.name);
|
||||
t.truthy(result.commits[1].committer.name);
|
||||
// Verify the last release is returned and updated
|
||||
t.truthy(result.lastRelease);
|
||||
t.is(result.lastRelease.gitHead.substring(0, 7), commits[commits.length - 1].hash);
|
||||
t.is(result.lastRelease.gitTag, 'v1.0.0');
|
||||
t.is(result.lastRelease.version, '1.0.0');
|
||||
});
|
||||
|
||||
test.serial('Get all commits since gitHead, when gitHead are mising from the shallow clone', async t => {
|
||||
test.serial('Get all commits since gitHead, when gitHead is missing from the shallow clone', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
const repo = await gitRepo();
|
||||
// Add commits to the master branch
|
||||
@@ -328,7 +295,7 @@ test.serial('Get all commits since gitHead, when gitHead are mising from the sha
|
||||
t.falsy(result.lastRelease.gitTag);
|
||||
});
|
||||
|
||||
test.serial('Get all commits since gitHead from tag, when tags are mising from the shallow clone', async t => {
|
||||
test.serial('Get all commits since gitHead from tag, when tags is missing from the shallow clone', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
const repo = await gitRepo();
|
||||
// Add commits to the master branch
|
||||
@@ -344,7 +311,7 @@ test.serial('Get all commits since gitHead from tag, when tags are mising from t
|
||||
t.is((await gitTags()).length, 0);
|
||||
|
||||
// Retrieve the commits with the commits module, since commit 'First' (associated with tag v1.0.0)
|
||||
const result = await getCommits({version: '1.0.0'}, 'master', t.context.logger);
|
||||
const result = await getCommits({version: '1.0.0', gitHead: 'missing_ref'}, 'master', t.context.logger);
|
||||
|
||||
// Verify the commits created and retrieved by the module are identical
|
||||
t.is(result.commits.length, 2);
|
||||
@@ -398,25 +365,6 @@ test.serial('Return empty array if there is no commits', async t => {
|
||||
t.falsy(result.lastRelease.version);
|
||||
});
|
||||
|
||||
test.serial('Throws ENOGITHEAD error if the gitHead of the last release cannot be found', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
await gitRepo();
|
||||
// Add commits to the master branch
|
||||
await gitCommits(['First', 'Second']);
|
||||
|
||||
// Retrieve the commits with the commits module
|
||||
const error = await t.throws(getCommits({version: '1.0.0'}, 'master', t.context.logger));
|
||||
|
||||
// Verify error code and type
|
||||
t.is(error.code, 'ENOGITHEAD');
|
||||
t.is(error.name, 'SemanticReleaseError');
|
||||
// Verify the log function has been called with a message explaining the error
|
||||
t.regex(
|
||||
t.context.error.args[0][0],
|
||||
/The commit the last release of this package was derived from cannot be determined from the release metadata nor from the repository tags/
|
||||
);
|
||||
});
|
||||
|
||||
test.serial('Throws ENOTINHISTORY error if gitHead is not in history', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
await gitRepo();
|
||||
@@ -505,7 +453,7 @@ test.serial('Throws ENOTINHISTORY error when a tag is not in branch history but
|
||||
await gitCommits(['Forth']);
|
||||
|
||||
// Retrieve the commits with the commits module
|
||||
const error = await t.throws(getCommits({version: '1.0.0'}, 'master', t.context.logger));
|
||||
const error = await t.throws(getCommits({version: '1.0.0', gitHead: shaTag}, 'master', t.context.logger));
|
||||
// Verify error code and type
|
||||
t.is(error.code, 'ENOTINHISTORY');
|
||||
t.is(error.name, 'SemanticReleaseError');
|
||||
|
||||
+275
-17
@@ -19,7 +19,6 @@ test.beforeEach(t => {
|
||||
t.context.log = stub();
|
||||
t.context.error = stub();
|
||||
t.context.logger = {log: t.context.log, error: t.context.error};
|
||||
t.context.semanticRelease = proxyquire('../index', {'./lib/logger': t.context.logger});
|
||||
});
|
||||
|
||||
test.afterEach.always(() => {
|
||||
@@ -61,7 +60,11 @@ test.serial('Plugins are called with expected values', async t => {
|
||||
publish,
|
||||
};
|
||||
|
||||
await t.context.semanticRelease(options);
|
||||
const semanticRelease = proxyquire('..', {
|
||||
'./lib/logger': t.context.logger,
|
||||
'env-ci': () => ({isCi: true, branch: 'master', isPr: false}),
|
||||
});
|
||||
t.truthy(await semanticRelease(options));
|
||||
|
||||
t.is(verifyConditions1.callCount, 1);
|
||||
t.deepEqual(verifyConditions1.args[0][0], config);
|
||||
@@ -140,7 +143,11 @@ test.serial('Use new gitHead, and recreate release notes if a publish plugin cre
|
||||
publish: [publish1, publish2],
|
||||
};
|
||||
|
||||
await t.context.semanticRelease(options);
|
||||
const semanticRelease = proxyquire('..', {
|
||||
'./lib/logger': t.context.logger,
|
||||
'env-ci': () => ({isCi: true, branch: 'master', isPr: false}),
|
||||
});
|
||||
t.truthy(await semanticRelease(options));
|
||||
|
||||
t.is(generateNotes.callCount, 2);
|
||||
t.deepEqual(generateNotes.args[0][1].nextRelease, nextRelease);
|
||||
@@ -154,7 +161,7 @@ test.serial('Use new gitHead, and recreate release notes if a publish plugin cre
|
||||
t.deepEqual(publish2.args[0][1].nextRelease, Object.assign({}, nextRelease, {notes}));
|
||||
});
|
||||
|
||||
test.serial('Dry-run skips verifyConditions and publish', async t => {
|
||||
test.serial('Dry-run skips publish', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
await gitRepo();
|
||||
// Add commits to the master branch
|
||||
@@ -187,9 +194,14 @@ test.serial('Dry-run skips verifyConditions and publish', async t => {
|
||||
publish,
|
||||
};
|
||||
|
||||
await t.context.semanticRelease(options);
|
||||
const semanticRelease = proxyquire('..', {
|
||||
'./lib/logger': t.context.logger,
|
||||
'env-ci': () => ({isCi: true, branch: 'master', isPr: false}),
|
||||
});
|
||||
t.truthy(await semanticRelease(options));
|
||||
|
||||
t.is(verifyConditions.callCount, 0);
|
||||
t.not(t.context.log.args[0][0], 'This run was not triggered in a known CI environment, running in dry-run mode.');
|
||||
t.is(verifyConditions.callCount, 1);
|
||||
t.is(getLastRelease.callCount, 1);
|
||||
t.is(analyzeCommits.callCount, 1);
|
||||
t.is(verifyRelease.callCount, 1);
|
||||
@@ -197,6 +209,106 @@ test.serial('Dry-run skips verifyConditions and publish', async t => {
|
||||
t.is(publish.callCount, 0);
|
||||
});
|
||||
|
||||
test.serial('Force a dry-run if not on a CI and ignore "noCi" is not explicitly set', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
await gitRepo();
|
||||
// Add commits to the master branch
|
||||
let commits = await gitCommits(['First']);
|
||||
// Create the tag corresponding to version 1.0.0
|
||||
await gitTagVersion('v1.0.0');
|
||||
// Add new commits to the master branch
|
||||
commits = (await gitCommits(['Second'])).concat(commits);
|
||||
|
||||
const lastRelease = {version: '1.0.0', gitHead: commits[commits.length - 1].hash, gitTag: 'v1.0.0'};
|
||||
const nextRelease = {type: 'major', version: '2.0.0', gitHead: await getGitHead(), gitTag: 'v2.0.0'};
|
||||
const notes = 'Release notes';
|
||||
|
||||
const verifyConditions = stub().resolves();
|
||||
const getLastRelease = stub().resolves(lastRelease);
|
||||
const analyzeCommits = stub().resolves(nextRelease.type);
|
||||
const verifyRelease = stub().resolves();
|
||||
const generateNotes = stub().resolves(notes);
|
||||
const publish = stub().resolves();
|
||||
|
||||
const options = {
|
||||
dryRun: false,
|
||||
branch: 'master',
|
||||
repositoryUrl: 'git@hostname.com:owner/module.git',
|
||||
verifyConditions,
|
||||
getLastRelease,
|
||||
analyzeCommits,
|
||||
verifyRelease,
|
||||
generateNotes,
|
||||
publish,
|
||||
};
|
||||
|
||||
const semanticRelease = proxyquire('..', {
|
||||
'./lib/logger': t.context.logger,
|
||||
'env-ci': () => ({isCi: false, branch: 'master'}),
|
||||
});
|
||||
t.truthy(await semanticRelease(options));
|
||||
|
||||
t.is(t.context.log.args[0][0], 'This run was not triggered in a known CI environment, running in dry-run mode.');
|
||||
t.is(verifyConditions.callCount, 1);
|
||||
t.is(getLastRelease.callCount, 1);
|
||||
t.is(analyzeCommits.callCount, 1);
|
||||
t.is(verifyRelease.callCount, 1);
|
||||
t.is(generateNotes.callCount, 1);
|
||||
t.is(publish.callCount, 0);
|
||||
});
|
||||
|
||||
test.serial('Allow local releases with "noCi" option', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
await gitRepo();
|
||||
// Add commits to the master branch
|
||||
let commits = await gitCommits(['First']);
|
||||
// Create the tag corresponding to version 1.0.0
|
||||
await gitTagVersion('v1.0.0');
|
||||
// Add new commits to the master branch
|
||||
commits = (await gitCommits(['Second'])).concat(commits);
|
||||
|
||||
const lastRelease = {version: '1.0.0', gitHead: commits[commits.length - 1].hash, gitTag: 'v1.0.0'};
|
||||
const nextRelease = {type: 'major', version: '2.0.0', gitHead: await getGitHead(), gitTag: 'v2.0.0'};
|
||||
const notes = 'Release notes';
|
||||
|
||||
const verifyConditions = stub().resolves();
|
||||
const getLastRelease = stub().resolves(lastRelease);
|
||||
const analyzeCommits = stub().resolves(nextRelease.type);
|
||||
const verifyRelease = stub().resolves();
|
||||
const generateNotes = stub().resolves(notes);
|
||||
const publish = stub().resolves();
|
||||
|
||||
const options = {
|
||||
noCi: true,
|
||||
branch: 'master',
|
||||
repositoryUrl: 'git@hostname.com:owner/module.git',
|
||||
verifyConditions,
|
||||
getLastRelease,
|
||||
analyzeCommits,
|
||||
verifyRelease,
|
||||
generateNotes,
|
||||
publish,
|
||||
};
|
||||
|
||||
const semanticRelease = proxyquire('..', {
|
||||
'./lib/logger': t.context.logger,
|
||||
'env-ci': () => ({isCi: false, branch: 'master', isPr: true}),
|
||||
});
|
||||
t.truthy(await semanticRelease(options));
|
||||
|
||||
t.not(t.context.log.args[0][0], 'This run was not triggered in a known CI environment, running in dry-run mode.');
|
||||
t.not(
|
||||
t.context.log.args[0][0],
|
||||
"This run was triggered by a pull request and therefore a new version won't be published."
|
||||
);
|
||||
t.is(verifyConditions.callCount, 1);
|
||||
t.is(getLastRelease.callCount, 1);
|
||||
t.is(analyzeCommits.callCount, 1);
|
||||
t.is(verifyRelease.callCount, 1);
|
||||
t.is(generateNotes.callCount, 1);
|
||||
t.is(publish.callCount, 1);
|
||||
});
|
||||
|
||||
test.serial('Accept "undefined" values for the "getLastRelease" and "generateNotes" plugins', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
await gitRepo();
|
||||
@@ -227,7 +339,11 @@ test.serial('Accept "undefined" values for the "getLastRelease" and "generateNot
|
||||
publish,
|
||||
};
|
||||
|
||||
await t.context.semanticRelease(options);
|
||||
const semanticRelease = proxyquire('..', {
|
||||
'./lib/logger': t.context.logger,
|
||||
'env-ci': () => ({isCi: true, branch: 'master', isPr: false}),
|
||||
});
|
||||
t.truthy(await semanticRelease(options));
|
||||
|
||||
t.is(getLastRelease.callCount, 1);
|
||||
|
||||
@@ -245,29 +361,167 @@ test.serial('Accept "undefined" values for the "getLastRelease" and "generateNot
|
||||
t.falsy(publish.args[0][1].nextRelease.notes);
|
||||
});
|
||||
|
||||
test.serial('Throw SemanticReleaseError if not running from a git repository', async t => {
|
||||
test.serial('Returns falsy value if not running from a git repository', async t => {
|
||||
// Set the current working directory to a temp directory
|
||||
process.chdir(tempy.directory());
|
||||
|
||||
const error = await t.throws(t.context.semanticRelease());
|
||||
|
||||
// Verify error code and type
|
||||
t.is(error.code, 'ENOGITREPO');
|
||||
t.is(error.name, 'SemanticReleaseError');
|
||||
const semanticRelease = proxyquire('..', {
|
||||
'./lib/logger': t.context.logger,
|
||||
'env-ci': () => ({isCi: true, branch: 'master', isPr: false}),
|
||||
});
|
||||
t.falsy(await semanticRelease());
|
||||
t.is(t.context.error.args[0][0], 'Semantic-release must run from a git repository.');
|
||||
});
|
||||
|
||||
test.serial('Throw SemanticReleaseError if repositoryUrl is not set and cannot be found', async t => {
|
||||
test.serial('Returns falsy value if triggered by a PR', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
await gitRepo();
|
||||
|
||||
const error = await t.throws(t.context.semanticRelease());
|
||||
const semanticRelease = proxyquire('..', {
|
||||
'./lib/logger': t.context.logger,
|
||||
'env-ci': () => ({isCi: true, branch: 'master', isPr: true}),
|
||||
});
|
||||
|
||||
t.falsy(await semanticRelease({repositoryUrl: 'git@hostname.com:owner/module.git'}));
|
||||
t.is(
|
||||
t.context.log.args[0][0],
|
||||
"This run was triggered by a pull request and therefore a new version won't be published."
|
||||
);
|
||||
});
|
||||
|
||||
test.serial('Returns falsy value if not running from the configured branch', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
await gitRepo();
|
||||
|
||||
const verifyConditions = stub().resolves();
|
||||
const getLastRelease = stub().resolves();
|
||||
const analyzeCommits = stub().resolves();
|
||||
const verifyRelease = stub().resolves();
|
||||
const generateNotes = stub().resolves();
|
||||
const publish = stub().resolves();
|
||||
|
||||
const options = {
|
||||
branch: 'master',
|
||||
repositoryUrl: 'git@hostname.com:owner/module.git',
|
||||
verifyConditions: [verifyConditions],
|
||||
getLastRelease,
|
||||
analyzeCommits,
|
||||
verifyRelease,
|
||||
generateNotes,
|
||||
publish,
|
||||
};
|
||||
|
||||
const semanticRelease = proxyquire('..', {
|
||||
'./lib/logger': t.context.logger,
|
||||
'env-ci': () => ({isCi: true, branch: 'other-branch', isPr: false}),
|
||||
});
|
||||
|
||||
t.falsy(await semanticRelease(options));
|
||||
t.is(
|
||||
t.context.log.args[0][0],
|
||||
'This test run was triggered on the branch other-branch, while semantic-release is configured to only publish from master, therefore a new version won’t be published.'
|
||||
);
|
||||
});
|
||||
|
||||
test.serial('Returns falsy value if there is no relevant changes', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
await gitRepo();
|
||||
// Add commits to the master branch
|
||||
await gitCommits(['First']);
|
||||
|
||||
const verifyConditions = stub().resolves();
|
||||
const getLastRelease = stub().resolves();
|
||||
const analyzeCommits = stub().resolves();
|
||||
const verifyRelease = stub().resolves();
|
||||
const generateNotes = stub().resolves();
|
||||
const publish = stub().resolves();
|
||||
|
||||
const options = {
|
||||
branch: 'master',
|
||||
repositoryUrl: 'git@hostname.com:owner/module.git',
|
||||
verifyConditions: [verifyConditions],
|
||||
getLastRelease,
|
||||
analyzeCommits,
|
||||
verifyRelease,
|
||||
generateNotes,
|
||||
publish,
|
||||
};
|
||||
|
||||
const semanticRelease = proxyquire('..', {
|
||||
'./lib/logger': t.context.logger,
|
||||
'env-ci': () => ({isCi: true, branch: 'master', isPr: false}),
|
||||
});
|
||||
|
||||
t.falsy(await semanticRelease(options));
|
||||
t.is(analyzeCommits.callCount, 1);
|
||||
t.is(verifyRelease.callCount, 0);
|
||||
t.is(generateNotes.callCount, 0);
|
||||
t.is(publish.callCount, 0);
|
||||
t.is(t.context.log.args[6][0], 'There are no relevant changes, so no new version is released.');
|
||||
});
|
||||
|
||||
test.serial('Exclude commits with [skip release] or [release skip] from analysis', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
await gitRepo();
|
||||
// Add commits to the master branch
|
||||
const commits = await gitCommits([
|
||||
'Test commit',
|
||||
'Test commit [skip release]',
|
||||
'Test commit [release skip]',
|
||||
'Test commit [Release Skip]',
|
||||
'Test commit [Skip Release]',
|
||||
'Test commit [skip release]',
|
||||
'Test commit\n\n commit body\n[skip release]',
|
||||
'Test commit\n\n commit body\n[release skip]',
|
||||
]);
|
||||
|
||||
const verifyConditions1 = stub().resolves();
|
||||
const verifyConditions2 = stub().resolves();
|
||||
const getLastRelease = stub().resolves({});
|
||||
const analyzeCommits = stub().resolves();
|
||||
const verifyRelease = stub().resolves();
|
||||
const generateNotes = stub().resolves();
|
||||
const publish = stub().resolves();
|
||||
|
||||
const config = {branch: 'master', repositoryUrl: 'git@hostname.com:owner/module.git', globalOpt: 'global'};
|
||||
const options = {
|
||||
...config,
|
||||
verifyConditions: [verifyConditions1, verifyConditions2],
|
||||
getLastRelease,
|
||||
analyzeCommits,
|
||||
verifyRelease,
|
||||
generateNotes,
|
||||
publish,
|
||||
};
|
||||
|
||||
const semanticRelease = proxyquire('..', {
|
||||
'./lib/logger': t.context.logger,
|
||||
'env-ci': () => ({isCi: true, branch: 'master', isPr: false}),
|
||||
});
|
||||
await semanticRelease(options);
|
||||
|
||||
t.is(analyzeCommits.callCount, 1);
|
||||
t.is(analyzeCommits.args[0][1].commits.length, 1);
|
||||
t.deepEqual(analyzeCommits.args[0][1].commits[0].hash.substring(0, 7), commits[commits.length - 1].hash);
|
||||
t.deepEqual(analyzeCommits.args[0][1].commits[0].message, commits[commits.length - 1].message);
|
||||
});
|
||||
|
||||
test.serial('Throw SemanticReleaseError if repositoryUrl is not set and cannot be found from repo config', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
await gitRepo();
|
||||
|
||||
const semanticRelease = proxyquire('..', {
|
||||
'./lib/logger': t.context.logger,
|
||||
'env-ci': () => ({isCi: true, branch: 'master', isPr: false}),
|
||||
});
|
||||
const error = await t.throws(semanticRelease());
|
||||
|
||||
// Verify error code and type
|
||||
t.is(error.code, 'ENOREPOURL');
|
||||
t.is(error.name, 'SemanticReleaseError');
|
||||
});
|
||||
|
||||
test.serial('Throw an Error if returns an unexpected value', async t => {
|
||||
test.serial('Throw an Error if plugin returns an unexpected value', async t => {
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
await gitRepo();
|
||||
// Add commits to the master branch
|
||||
@@ -287,7 +541,11 @@ test.serial('Throw an Error if returns an unexpected value', async t => {
|
||||
getLastRelease,
|
||||
};
|
||||
|
||||
const error = await t.throws(t.context.semanticRelease(options), Error);
|
||||
const semanticRelease = proxyquire('..', {
|
||||
'./lib/logger': t.context.logger,
|
||||
'env-ci': () => ({isCi: true, branch: 'master', isPr: false}),
|
||||
});
|
||||
const error = await t.throws(semanticRelease(options), Error);
|
||||
|
||||
// Verify error message
|
||||
t.regex(error.message, new RegExp(DEFINITIONS.getLastRelease.output.message));
|
||||
|
||||
+79
-20
@@ -53,6 +53,12 @@ test.beforeEach(() => {
|
||||
delete process.env.GITHUB_URL;
|
||||
delete process.env.GH_PREFIX;
|
||||
delete process.env.GITHUB_PREFIX;
|
||||
|
||||
process.env.TRAVIS = 'true';
|
||||
process.env.CI = 'true';
|
||||
process.env.TRAVIS_BRANCH = 'master';
|
||||
process.env.TRAVIS_PULL_REQUEST = 'false';
|
||||
|
||||
// Delete all `npm_config` environment variable set by CI as they take precedence over the `.npmrc` because the process that runs the tests is started before the `.npmrc` is created
|
||||
for (let i = 0, keys = Object.keys(process.env); i < keys.length; i++) {
|
||||
if (keys[i].startsWith('npm_config')) {
|
||||
@@ -86,7 +92,6 @@ test.serial('Release patch, minor and major versions', async t => {
|
||||
name: packageName,
|
||||
version: '0.0.0-dev',
|
||||
repository: {url: `git+https://github.com/${owner}/${packageName}`},
|
||||
release: {verifyConditions: ['@semantic-release/github', '@semantic-release/npm']},
|
||||
publishConfig: {registry: npmRegistry.url},
|
||||
});
|
||||
// Create a npm-shrinkwrap.json file
|
||||
@@ -113,6 +118,11 @@ test.serial('Release patch, minor and major versions', async t => {
|
||||
{headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
{body: {permissions: {push: true}}, method: 'GET'}
|
||||
);
|
||||
let getRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs/tags/v${version}`,
|
||||
{},
|
||||
{body: {}, statusCode: 404, method: 'GET'}
|
||||
);
|
||||
let createRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs`,
|
||||
{body: {ref: `refs/tags/v${version}`}, headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
@@ -131,7 +141,7 @@ test.serial('Release patch, minor and major versions', async t => {
|
||||
await gitCommits(['feat: Initial commit']);
|
||||
t.log('$ semantic-release');
|
||||
({stdout, code} = await execa(cli, [], {env}));
|
||||
t.regex(stdout, new RegExp(`Published Github release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Published GitHub release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Publishing version ${version} to npm registry`));
|
||||
t.is(code, 0);
|
||||
|
||||
@@ -148,6 +158,7 @@ test.serial('Release patch, minor and major versions', async t => {
|
||||
t.log(`+ released ${releasedVersion} with gitHead ${releasedGitHead}`);
|
||||
|
||||
await mockServer.verify(verifyMock);
|
||||
await mockServer.verify(getRefMock);
|
||||
await mockServer.verify(createRefMock);
|
||||
await mockServer.verify(createReleaseMock);
|
||||
|
||||
@@ -158,6 +169,11 @@ test.serial('Release patch, minor and major versions', async t => {
|
||||
{headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
{body: {permissions: {push: true}}, method: 'GET'}
|
||||
);
|
||||
getRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs/tags/v${version}`,
|
||||
{},
|
||||
{body: {}, statusCode: 404, method: 'GET'}
|
||||
);
|
||||
createRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs`,
|
||||
{body: {ref: `refs/tags/v${version}`}, headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
@@ -176,7 +192,7 @@ test.serial('Release patch, minor and major versions', async t => {
|
||||
await gitCommits(['fix: bar']);
|
||||
t.log('$ semantic-release');
|
||||
({stdout, code} = await execa(cli, [], {env}));
|
||||
t.regex(stdout, new RegExp(`Published Github release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Published GitHub release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Publishing version ${version} to npm registry`));
|
||||
t.is(code, 0);
|
||||
|
||||
@@ -193,6 +209,7 @@ test.serial('Release patch, minor and major versions', async t => {
|
||||
t.log(`+ released ${releasedVersion} with gitHead ${releasedGitHead}`);
|
||||
|
||||
await mockServer.verify(verifyMock);
|
||||
await mockServer.verify(getRefMock);
|
||||
await mockServer.verify(createRefMock);
|
||||
await mockServer.verify(createReleaseMock);
|
||||
|
||||
@@ -203,6 +220,11 @@ test.serial('Release patch, minor and major versions', async t => {
|
||||
{headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
{body: {permissions: {push: true}}, method: 'GET'}
|
||||
);
|
||||
getRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs/tags/v${version}`,
|
||||
{},
|
||||
{body: {}, statusCode: 404, method: 'GET'}
|
||||
);
|
||||
createRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs`,
|
||||
{body: {ref: `refs/tags/v${version}`}, headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
@@ -221,7 +243,7 @@ test.serial('Release patch, minor and major versions', async t => {
|
||||
await gitCommits(['feat: baz']);
|
||||
t.log('$ semantic-release');
|
||||
({stdout, code} = await execa(cli, [], {env}));
|
||||
t.regex(stdout, new RegExp(`Published Github release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Published GitHub release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Publishing version ${version} to npm registry`));
|
||||
t.is(code, 0);
|
||||
|
||||
@@ -238,6 +260,7 @@ test.serial('Release patch, minor and major versions', async t => {
|
||||
t.log(`+ released ${releasedVersion} with gitHead ${releasedGitHead}`);
|
||||
|
||||
await mockServer.verify(verifyMock);
|
||||
await mockServer.verify(getRefMock);
|
||||
await mockServer.verify(createRefMock);
|
||||
await mockServer.verify(createReleaseMock);
|
||||
|
||||
@@ -248,6 +271,11 @@ test.serial('Release patch, minor and major versions', async t => {
|
||||
{headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
{body: {permissions: {push: true}}, method: 'GET'}
|
||||
);
|
||||
getRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs/tags/v${version}`,
|
||||
{},
|
||||
{body: {}, statusCode: 404, method: 'GET'}
|
||||
);
|
||||
createRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs`,
|
||||
{body: {ref: `refs/tags/v${version}`}, headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
@@ -266,7 +294,7 @@ test.serial('Release patch, minor and major versions', async t => {
|
||||
await gitCommits(['feat: foo\n\n BREAKING CHANGE: bar']);
|
||||
t.log('$ semantic-release');
|
||||
({stdout, code} = await execa(cli, [], {env}));
|
||||
t.regex(stdout, new RegExp(`Published Github release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Published GitHub release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Publishing version ${version} to npm registry`));
|
||||
t.is(code, 0);
|
||||
|
||||
@@ -283,12 +311,13 @@ test.serial('Release patch, minor and major versions', async t => {
|
||||
t.log(`+ released ${releasedVersion} with gitHead ${releasedGitHead}`);
|
||||
|
||||
await mockServer.verify(verifyMock);
|
||||
await mockServer.verify(getRefMock);
|
||||
await mockServer.verify(createRefMock);
|
||||
await mockServer.verify(createReleaseMock);
|
||||
});
|
||||
|
||||
test.serial('Release versions from a packed git repository, using tags to determine last release gitHead', async t => {
|
||||
const packageName = 'test-git-packaed';
|
||||
const packageName = 'test-git-packed';
|
||||
const owner = 'test-repo';
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
t.log('Create git repository');
|
||||
@@ -299,7 +328,6 @@ test.serial('Release versions from a packed git repository, using tags to determ
|
||||
name: packageName,
|
||||
version: '0.0.0-dev',
|
||||
repository: {url: `git@github.com:${owner}/${packageName}.git`},
|
||||
release: {verifyConditions: ['@semantic-release/github', '@semantic-release/npm']},
|
||||
publishConfig: {registry: npmRegistry.url},
|
||||
});
|
||||
|
||||
@@ -315,6 +343,11 @@ test.serial('Release versions from a packed git repository, using tags to determ
|
||||
{body: {ref: `refs/tags/v${version}`}, headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
{body: {ref: `refs/tags/${version}`}}
|
||||
);
|
||||
let getRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs/tags/v${version}`,
|
||||
{},
|
||||
{body: {}, statusCode: 404, method: 'GET'}
|
||||
);
|
||||
let createReleaseMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/releases`,
|
||||
{
|
||||
@@ -329,7 +362,7 @@ test.serial('Release versions from a packed git repository, using tags to determ
|
||||
await gitPackRefs();
|
||||
t.log('$ semantic-release');
|
||||
let {stdout, code} = await execa(cli, [], {env});
|
||||
t.regex(stdout, new RegExp(`Published Github release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Published GitHub release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Publishing version ${version} to npm registry`));
|
||||
t.is(code, 0);
|
||||
// Verify package.json has been updated
|
||||
@@ -339,6 +372,7 @@ test.serial('Release versions from a packed git repository, using tags to determ
|
||||
t.is(releasedVersion, version);
|
||||
t.log(`+ released ${releasedVersion}`);
|
||||
await mockServer.verify(verifyMock);
|
||||
await mockServer.verify(getRefMock);
|
||||
await mockServer.verify(createRefMock);
|
||||
await mockServer.verify(createReleaseMock);
|
||||
// Create a tag version so the tag can be used later to determine the commit associated with the version
|
||||
@@ -352,6 +386,11 @@ test.serial('Release versions from a packed git repository, using tags to determ
|
||||
{headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
{body: {permissions: {push: true}}, method: 'GET'}
|
||||
);
|
||||
getRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs/tags/v${version}`,
|
||||
{},
|
||||
{body: {}, statusCode: 404, method: 'GET'}
|
||||
);
|
||||
createRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs`,
|
||||
{body: {ref: `refs/tags/v${version}`}, headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
@@ -369,7 +408,7 @@ test.serial('Release versions from a packed git repository, using tags to determ
|
||||
await gitCommits(['fix: bar']);
|
||||
t.log('$ semantic-release');
|
||||
({stdout, code} = await execa(cli, [], {env}));
|
||||
t.regex(stdout, new RegExp(`Published Github release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Published GitHub release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Publishing version ${version} to npm registry`));
|
||||
t.is(code, 0);
|
||||
// Verify package.json has been updated
|
||||
@@ -380,6 +419,7 @@ test.serial('Release versions from a packed git repository, using tags to determ
|
||||
t.is(releasedVersion, version);
|
||||
t.log(`+ released ${releasedVersion}`);
|
||||
await mockServer.verify(verifyMock);
|
||||
await mockServer.verify(getRefMock);
|
||||
await mockServer.verify(createRefMock);
|
||||
await mockServer.verify(createReleaseMock);
|
||||
});
|
||||
@@ -453,7 +493,6 @@ test.serial('Create a tag as a recovery solution for "ENOTINHISTORY" error', asy
|
||||
name: packageName,
|
||||
version: '0.0.0-dev',
|
||||
repository: {url: `git+https://github.com/${owner}/${packageName}`},
|
||||
release: {verifyConditions: ['@semantic-release/github', '@semantic-release/npm']},
|
||||
publishConfig: {registry: npmRegistry.url},
|
||||
});
|
||||
|
||||
@@ -464,6 +503,11 @@ test.serial('Create a tag as a recovery solution for "ENOTINHISTORY" error', asy
|
||||
{headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
{body: {permissions: {push: true}}, method: 'GET'}
|
||||
);
|
||||
let getRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs/tags/v${version}`,
|
||||
{},
|
||||
{body: {}, statusCode: 404, method: 'GET'}
|
||||
);
|
||||
let createRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs`,
|
||||
{body: {ref: `refs/tags/v${version}`}, headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
@@ -481,7 +525,7 @@ test.serial('Create a tag as a recovery solution for "ENOTINHISTORY" error', asy
|
||||
await gitCommits(['feat: Initial commit']);
|
||||
t.log('$ semantic-release');
|
||||
let {stderr, stdout, code} = await execa(cli, [], {env});
|
||||
t.regex(stdout, new RegExp(`Published Github release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Published GitHub release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Publishing version ${version} to npm registry`));
|
||||
t.is(code, 0);
|
||||
// Verify package.json has been updated
|
||||
@@ -496,6 +540,7 @@ test.serial('Create a tag as a recovery solution for "ENOTINHISTORY" error', asy
|
||||
t.is(releasedVersion, version);
|
||||
t.log(`+ released ${releasedVersion}`);
|
||||
await mockServer.verify(verifyMock);
|
||||
await mockServer.verify(getRefMock);
|
||||
await mockServer.verify(createRefMock);
|
||||
await mockServer.verify(createReleaseMock);
|
||||
|
||||
@@ -520,7 +565,7 @@ test.serial('Create a tag as a recovery solution for "ENOTINHISTORY" error', asy
|
||||
({stderr, stdout, code} = await execa(cli, [], {env, reject: false}));
|
||||
|
||||
t.log('Log "ENOTINHISTORY" message');
|
||||
t.is(code, 0);
|
||||
t.is(code, 1);
|
||||
t.regex(
|
||||
stderr,
|
||||
new RegExp(
|
||||
@@ -539,6 +584,11 @@ test.serial('Create a tag as a recovery solution for "ENOTINHISTORY" error', asy
|
||||
{headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
{body: {permissions: {push: true}}, method: 'GET'}
|
||||
);
|
||||
getRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs/tags/v${version}`,
|
||||
{},
|
||||
{body: {}, statusCode: 404, method: 'GET'}
|
||||
);
|
||||
createRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs`,
|
||||
{body: {ref: `refs/tags/v${version}`}, headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
@@ -555,7 +605,7 @@ test.serial('Create a tag as a recovery solution for "ENOTINHISTORY" error', asy
|
||||
|
||||
t.log('$ semantic-release');
|
||||
({stderr, stdout, code} = await execa(cli, [], {env}));
|
||||
t.regex(stdout, new RegExp(`Published Github release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Published GitHub release: release-url/${version}`));
|
||||
t.regex(stdout, new RegExp(`Publishing version ${version} to npm registry`));
|
||||
t.is(code, 0);
|
||||
// Verify package.json has been updated
|
||||
@@ -566,6 +616,7 @@ test.serial('Create a tag as a recovery solution for "ENOTINHISTORY" error', asy
|
||||
t.is(releasedVersion, version);
|
||||
t.log(`+ released ${releasedVersion}`);
|
||||
await mockServer.verify(verifyMock);
|
||||
await mockServer.verify(getRefMock);
|
||||
await mockServer.verify(createRefMock);
|
||||
await mockServer.verify(createReleaseMock);
|
||||
});
|
||||
@@ -585,6 +636,11 @@ test.serial('Dry-run', async t => {
|
||||
});
|
||||
|
||||
/* Initial release */
|
||||
const verifyMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}`,
|
||||
{headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
{body: {permissions: {push: true}}, method: 'GET'}
|
||||
);
|
||||
const version = '1.0.0';
|
||||
t.log('Commit a feature');
|
||||
await gitCommits(['feat: Initial commit']);
|
||||
@@ -597,6 +653,7 @@ test.serial('Dry-run', async t => {
|
||||
|
||||
// Verify package.json and has not been modified
|
||||
t.is((await readJson('./package.json')).version, '0.0.0-dev');
|
||||
await mockServer.verify(verifyMock);
|
||||
});
|
||||
|
||||
test.serial('Pass options via CLI arguments', async t => {
|
||||
@@ -659,6 +716,11 @@ test.serial('Run via JS API', async t => {
|
||||
{headers: [{name: 'Authorization', values: [`token ${env.GH_TOKEN}`]}]},
|
||||
{body: {permissions: {push: true}}, method: 'GET'}
|
||||
);
|
||||
const getRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs/tags/v${version}`,
|
||||
{},
|
||||
{body: {}, statusCode: 404, method: 'GET'}
|
||||
);
|
||||
const createRefMock = await mockServer.mock(
|
||||
`/repos/${owner}/${packageName}/git/refs`,
|
||||
{
|
||||
@@ -681,11 +743,7 @@ test.serial('Run via JS API', async t => {
|
||||
t.log('Commit a feature');
|
||||
await gitCommits(['feat: Initial commit']);
|
||||
t.log('$ Call semantic-release via API');
|
||||
await semanticRelease({
|
||||
verifyConditions: [{path: '@semantic-release/github'}, '@semantic-release/npm'],
|
||||
publish: [{path: '@semantic-release/github'}, '@semantic-release/npm'],
|
||||
debug: true,
|
||||
});
|
||||
await semanticRelease();
|
||||
|
||||
// Verify package.json and has been updated
|
||||
t.is((await readJson('./package.json')).version, version);
|
||||
@@ -699,6 +757,7 @@ test.serial('Run via JS API', async t => {
|
||||
t.log(`+ released ${releasedVersion} with gitHead ${releasedGitHead}`);
|
||||
|
||||
await mockServer.verify(verifyMock);
|
||||
await mockServer.verify(getRefMock);
|
||||
await mockServer.verify(createRefMock);
|
||||
await mockServer.verify(createReleaseMock);
|
||||
});
|
||||
@@ -731,7 +790,7 @@ test.serial('Log unexpected errors from plugins and exit with 1', async t => {
|
||||
t.is(code, 1);
|
||||
});
|
||||
|
||||
test.serial('Log errors inheriting SemanticReleaseError and exit with 0', async t => {
|
||||
test.serial('Log errors inheriting SemanticReleaseError and exit with 1', async t => {
|
||||
const packageName = 'test-inherited-error';
|
||||
const owner = 'test-repo';
|
||||
// Create a git repository, set the current working directory at the root of the repo
|
||||
@@ -752,7 +811,7 @@ test.serial('Log errors inheriting SemanticReleaseError and exit with 0', async
|
||||
const {stdout, code} = await execa(cli, [], {env, reject: false});
|
||||
// Verify the type and message are logged
|
||||
t.regex(stdout, /EINHERITED Inherited error/);
|
||||
t.is(code, 0);
|
||||
t.is(code, 1);
|
||||
});
|
||||
|
||||
test.serial('CLI returns error code and prints help if called with a command', async t => {
|
||||
|
||||
@@ -67,15 +67,16 @@ test('The "publish" plugin is mandatory, and must be a single or an array of plu
|
||||
t.true(definitions.publish.config.validator([{path: 'plugin-path.js'}, 'plugin-path.js', () => {}]));
|
||||
});
|
||||
|
||||
test('The "getLastRelease" plugin output if defined, must be an object with an optionnal valid semver version in the "version" property', t => {
|
||||
test('The "getLastRelease" plugin output if defined, must be an object with a valid semver version in the "version" property and the corresponding git reference in "gitHead" property', t => {
|
||||
t.false(definitions.getLastRelease.output.validator('string'));
|
||||
t.false(definitions.getLastRelease.output.validator(1));
|
||||
t.false(definitions.getLastRelease.output.validator({version: 'v1.0.0'}));
|
||||
t.false(definitions.getLastRelease.output.validator({version: 'invalid'}));
|
||||
|
||||
t.true(definitions.getLastRelease.output.validator());
|
||||
t.true(definitions.getLastRelease.output.validator({}));
|
||||
t.true(definitions.getLastRelease.output.validator({version: 'v1.0.0'}));
|
||||
t.true(definitions.getLastRelease.output.validator({version: '1.0.0'}));
|
||||
t.true(definitions.getLastRelease.output.validator({version: 'v1.0.0', gitHead: '123'}));
|
||||
t.true(definitions.getLastRelease.output.validator({version: '1.0.0', gitHead: '123'}));
|
||||
t.true(definitions.getLastRelease.output.validator({version: null}));
|
||||
});
|
||||
|
||||
|
||||
Reference in New Issue
Block a user