- Add a new plugin type: `publish`
- Add support for multi-plugin. A plugin module can now return an object with a property for each plugin type
- Uses by default [npm](https://github.com/semantic-release/npm) and [github](https://github.com/semantic-release/github) in addition of Travis for the verify condition plugin
- Uses by default [npm](https://github.com/semantic-release/npm) and [github](https://github.com/semantic-release/github) for the publish plugin
- `gitTag` if one can be found is passed to `generateNotes` for both `lastRelease` and `nextRelease`
- `semantic-release` now verifies the plugin configuration (in the `release` property of `package.json`) and throws an error if it's invalid
- `semantic-release` now verifies each plugin output and will throw an error if a plugin returns an unexpected value.
BREAKING CHANGE: `githubToken`, `githubUrl` and `githubApiPathPrefix` have to be set at the [github](https://github.com/semantic-release/github) plugin level. They can be set via `GH_TOKEN`, `GH_URL` and `GH_PREFIX` environment variables.
BREAKING CHANGE: the `npm` parameter is not passed to any plugin anymore. Each plugin have to read `.npmrc` if they needs to (with https://github.com/kevva/npm-conf for example).
- Run with one command and do not rely on error exit codes to stop the process when a release is not necessary
- Break `index.js` in smaller modules in order to improve testability and simplify the code
- Add several missing unit and integration tests to reach 100% coverage
- Integration tests now test end to end, including publishing to Github (with http://www.mock-server.com on Docker)
- Use `tj/commander.js` to print an help message, verify and parse CLI arguments
- Semantic-release can now be called via Javascript API: `require('semantic-release')(options)`
- Remove npmlog dependency and add more log messages
- Logger is now passed to plugins
- Add debug logs with `visionmedia/debug`. `debug` is enabled for both semantic-release and plugins with `--debug`
- Use `kevva/npm-conf` in place of the deprecated `npm/npmconf`
- Pass lastRelease, nextRelease and commits to generate-notes plugin
- In dry-run mode, print the release note instead of publishing it to Github as draft, and skip the CI verifications
- The dry-run mode does not require npm and Github TOKEN to be set anymore and can be run locally
BREAKING CHANGE: Semantic-Release must now be executed with `semantic-release` instead of `semantic-release pre && npm publish && semantic-release post`.
BREAKING CHANGE: The `semantic-release` command now returns with exit code 0 on expected exception (no release has to be done, running on a PR, gitHead not found, other CI job failed etc...). It only returns with 1 when there is an unexpected error (code error in a plugin, plugin not found, git command cannot be run etc..).
BREAKING CHANGE: Calling the `semantic-release` command with unexpected argument(s) now exit with 1 and print an help message.
BREAKING CHANGE: Semantic-Release does not rely on `npmlog` anymore and the log level cannot be configured. Debug logs can be activated with CLI option `--debug` or with environment variable `DEBUG=semantic-release:*`
BREAKING CHANGE: The CLI options `--debug` doesn't enable the dry-run mode anymore but activate the debugs. The dry run mode is now set with the CLI command `--dry-run` or `-d`.
- Tag sha will now be used also if there is a gitHead in last release and it's not in the history
- Use `git merge-base` to determine if a commit is in history, allowing to use CI creating detached head repo
- Mention recovery solution by creating a version tag in `ENOTINHISTORY` and `ENOGITHEAD` error messages
- Do not mention branches containing missing commit in `ENOTINHISTORY` and `ENOGITHEAD` error messages as it's not available by default on most CI
Add several fixes and improvements in the identification of the last release gitHead:
- If there is no last release, unshallow the repo in order to retrieve all existing commits
- If git head is not present in last release, try to retrieve it from git tag with format ‘v\<version\>’ or ‘\<version\>’
- If the last release git head cannot be determined and found in commit history, unshallow the repo and try again
- Throw a ENOGITHEAD error if the gitHead for the last release cannot be found in the npm metadata nor in the git tags, preventing to make release based on the all the commits in the repo as before
- Add integration test for the scenario with a packed repo from which `npm republish` fails to read the git head
Fix#447, Fix#393, Fix#280, Fix#276
- Use async/await instead of callbacks
- Use execa to run command line
- Use AVA for tests
- Add several assertions in the unit tests
- Add documentation (comments) in the tests
- Run tests with a real git repo instead of mocking child_process and add test helpers to create repos, commits and checkout
- Simplify test directory structure
- Simplify code readability (mostly with async/await)
- Use eslint for for linting, prettier for formatting
target_commitish in GitHub Releases has two different meanings:
* Target commit that a new associated tag will be created on
* Target branch to compute how many "commits to since this release"
target_commitish is usually the default branch (aka master), because the
distance between the release and the latest branch is the primary concern.
Before this change, target_commitish was left to be a hash and the
feature of GitHub Releases that shows how much time passed since the
release is ruined, because no tracking branch is given.
By this change, target_commitish is changed to be the default branch
given in the configuration (options.branch) via edit a release API after
the release and tag are created via crate a release API.
This commit removes babel/es6 from all source and test files, because it was introducing a lot of overhead and only little gain.
This commit fixes and enables integration tests on Travis.
This commit fixes#153 and #151 along the way.
_Originally this commit should have only removed babel, but without working tests that's a bit too hairy._
_I only realized that half way into removing babel/es6, so things are all over the place now._
Closes#153, Closes#151
With this new feature you can pass an array of plugin locations/names to
both "verifyConditions" and "verifyRelease" in your `package.json`'s "release"
field. This will run multiple verification plugins in series.
This commit does a lot but it's all connected and tries to make everything more extensible and future proof.
1. CLI arguments and options from the "package.json" are no longer treated as two different things. You can now pass options either way.
BREAKING CHANGE: cli arguments are now normalized to camelCase, so e.g. `options['github-url']` is now `options.githubUrl`
2. Plugins no longer receive config they need one by one, but in one huge object. This way it's easier to pass more info in the future w/o breaking existing plugins that rely on the position of the callback in the arguments array.
BREAKING CHANGE: Plugins now need to read their passed options from one huge config object.
Old:
```js
module.exports = function (pluginConfig, foo, bar, cb) {…}
```
New:
```js
// ES5
module.exports = function(pluginConfig, config, cb) {
var foo = config.foo
var bar = config.bar
…
}
// ES6
module.exports = function (pluginConfig, {foo, bar}, cb) {…}
```
