fix: match tag to tagFormat from the begining of the string

docs/support/FAQ.md

@@ -57,7 +57,36 @@ To publish a non-Node package (without a `package.json`) you would need to:
 - 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.
+See the [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on specific CI environments.
+
+In addition you will need to configure the **semantic-release** [plugins](../usage/plugins.md#plugins) to:
+- Disable the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin
+- Define plugins for the [verifyConditions](../usage/plugins.md#verifyconditions-plugin), [prepare](../usage/plugins.md#prepare-plugin) and [publish](../usage/plugins.md#publish-plugin) steps to release on your package registry. The [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin is recommended for situation where a release can be done with a shell command.
+
+Here is a basic example to create [GitHub releases](https://help.github.com/articles/about-releases) and use shell command to publish:
+
+```json
+{
+  "verifyConditions": ["@semantic-release/github"],
+  "prepare": [
+    {
+      "path": "@semantic-release/exec",
+      "cmd": "set-version ${nextRelease.version}"
+    }
+  ],
+  "publish": [
+    "@semantic-release/github",
+    {
+      "path": "@semantic-release/exec",
+      "cmd": "publish-package"
+    }
+  ],
+}
+```
+
+**Note**: This is a theoretical example where the command `set-version` update the project version with the value passed as its first argument and `publish-package` publishes the package to a registry.
+
+See the [package managers and languages recipes](../recipes/README.md#package-managers-and-languages) for more details on specific project types.
 
 ## Can I use semantic-release with any CI service?
 
@@ -65,7 +94,7 @@ Yes, **semantic-release** can be used with any CI service, as long as it provide
 - 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.
+See the [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on specific CI environments.
 
 ## Can I run semantic-release on my local machine rather than on a CI server?
 

docs/usage/ci-configuration.md

@@ -20,7 +20,7 @@ See [CI configuration recipes](../recipes/README.md#ci-configurations) for more
 
 Alternatively the Git authentication can be set up via [SSH keys](../recipes/git-auth-ssh-keys.md).
 
-Most **semantic-release** [plugins](plugins.md) require to set up authentication in order to publish to a package manager registry. 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:
+Most **semantic-release** [plugins](plugins.md) require setting up authentication in order to publish to a package manager registry. 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                                                                                                                                                                                                                                                                                                               |
 |-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
@@ -35,7 +35,7 @@ See [CI configuration recipes](../recipes/README.md#ci-configurations) for more
 
 ## 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:
+[`semantic-release-cli`](https://github.com/semantic-release/cli) allows for easy [installation](installation.md) of **semantic-release** in your Node project as well as setting up the CI configuration:
 
 ```bash
 npm install -g semantic-release-cli

docs/usage/configuration.md

@@ -27,7 +27,7 @@ $ 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.
+**Note**: Plugin options cannot be defined via CLI arguments and must be defined in the configuration file.
 
 ## Options
 
@@ -37,7 +37,7 @@ 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.
+List of modules or file paths containing a [shareable configuration](shareable-configurations.md). If multiple shareable configurations 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.
 
@@ -79,7 +79,7 @@ The [Git tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) format used by
 
 Type: `Boolean`
 
-Default: `false` if running in a CI environment, `false` otherwise
+Default: `false` if running in a CI environment, `true` otherwise
 
 CLI arguments: `-d`, `--dry-run`
 
@@ -93,7 +93,7 @@ Default: `false`
 
 CLI arguments: `--no-ci`
 
-Skip Continuous Integration environment verifications, allowing to make releases from a local machine.
+Skip Continuous Integration environment verifications. This allows for making releases from a local machine.
 
 ### debug
 
@@ -103,7 +103,7 @@ Default: `false`
 
 CLI argument: `--debug`
 
-Output debugging information. It can also be enabled by set the `DEBUG` environment variable to `semantic-release:*`.
+Output debugging information. It can also be enabled by setting the `DEBUG` environment variable to `semantic-release:*`.
 
 ### verifyConditions
 

docs/usage/shareable-configurations.md

@@ -1,5 +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.
+A sharable configuration is an [npm](https://www.npmjs.com/) package that exports a **semantic-release** configuration object. It allows for use of the same configuration across several projects.
 
 The shareable configurations to use can be set with the [extends](configuration.md#extends) option.

lib/get-last-release.js

@@ -28,11 +28,10 @@ module.exports = async (tagFormat, logger) => {
   // by replacing the `version` variable in the template by `(.+)`.
   // The `tagFormat` is compiled with space as the `version` as it's an invalid tag character,
   // so it's guaranteed to no be present in the `tagFormat`.
-  const tagRegexp = escapeRegExp(template(tagFormat)({version: ' '})).replace(' ', '(.+)');
+  const tagRegexp = `^${escapeRegExp(template(tagFormat)({version: ' '})).replace(' ', '(.+)')}`;
+
   const tags = (await gitTags())
-    .map(tag => {
-      return {gitTag: tag, version: (tag.match(tagRegexp) || new Array(2))[1]};
-    })
+    .map(tag => ({gitTag: tag, version: (tag.match(tagRegexp) || new Array(2))[1]}))
     .filter(
       tag => tag.version && semver.valid(semver.clean(tag.version)) && !semver.prerelease(semver.clean(tag.version))
     )
@@ -40,14 +39,11 @@ module.exports = async (tagFormat, logger) => {
 
   debug('found tags: %o', tags);
 
-  if (tags.length > 0) {
-    const {gitTag, version} = await pLocate(tags, tag => isRefInHistory(tag.gitTag), {
-      concurrency: 1,
-      preserveOrder: true,
-    });
-    logger.log('Found git tag %s associated with version %s', gitTag, version);
+  const tag = await pLocate(tags, tag => isRefInHistory(tag.gitTag), {concurrency: 1, preserveOrder: true});
 
-    return {gitHead: await gitTagHead(gitTag), gitTag, version};
+  if (tag) {
+    logger.log('Found git tag %s associated with version %s', tag.gitTag, tag.version);
+    return {gitHead: await gitTagHead(tag.gitTag), ...tag};
   }
 
   logger.log('No git tag version found');

package.json

@@ -32,7 +32,7 @@
     "execa": "^0.10.0",
     "get-stream": "^3.0.0",
     "git-log-parser": "^1.2.0",
-    "git-url-parse": "^8.1.0",
+    "git-url-parse": "^8.3.1",
     "hook-std": "^0.4.0",
     "hosted-git-info": "^2.6.0",
     "lodash": "^4.17.4",

test/get-last-release.test.js

@@ -62,6 +62,19 @@ test.serial('Get the highest tag in the history of the current branch', async t
   t.deepEqual(result, {gitHead: commits[0].hash, gitTag: 'v2.0.0', version: '2.0.0'});
 });
 
+test.serial('Match the tag name from the begining of the string', async t => {
+  // Create a git repository, set the current working directory at the root of the repo
+  await gitRepo();
+  const commits = await gitCommits(['First']);
+  await gitTagVersion('prefix/v1.0.0');
+  await gitTagVersion('prefix/v2.0.0');
+  await gitTagVersion('other-prefix/v3.0.0');
+
+  const result = await getLastRelease(`prefix/v\${version}`, t.context.logger);
+
+  t.deepEqual(result, {gitHead: commits[0].hash, gitTag: 'prefix/v2.0.0', version: '2.0.0'});
+});
+
 test.serial('Return empty object if no valid tag is found', async t => {
   // Create a git repository, set the current working directory at the root of the repo
   await gitRepo();
@@ -79,6 +92,23 @@ test.serial('Return empty object if no valid tag is found', async t => {
   t.is(t.context.log.args[0][0], 'No git tag version found');
 });
 
+test.serial('Return empty object if no valid tag is found in history', async t => {
+  // Create a git repository, set the current working directory at the root of the repo
+  await gitRepo();
+  await gitCommits(['First']);
+  await gitCheckout('other-branch');
+  await gitCommits(['Second']);
+  await gitTagVersion('v1.0.0');
+  await gitTagVersion('v2.0.0');
+  await gitTagVersion('v3.0.0');
+  await gitCheckout('master', false);
+
+  const result = await getLastRelease(`v\${version}`, t.context.logger);
+
+  t.deepEqual(result, {});
+  t.is(t.context.log.args[0][0], 'No git tag version found');
+});
+
 test.serial('Get the highest valid tag corresponding to the "tagFormat"', async t => {
   // Create a git repository, set the current working directory at the root of the repo
   await gitRepo();