fix: bump minimal version of lodash to address CVE-2021-23337 (#1931)

* docs(Plugin Developer Guide): More detailed lifecycle list and context descriptions

This commit will improve the following in the Plugin developer guide:
  * Lifecyle list more complete (previous was missing some lifecycles)
  * Context object has been now described in more detail per lifecycle
  * Some readability/maintainability fixes to the markdown file itself
    to make it easier to edit and read in an editor.

* docs(Plugin Developer Guide): Added missing context field to analyzeCommits lifecycle documentation

analyzeCommits lifecycle context was missing documentation for "commits" list.

* docs(developer-guide): remove line breaks added in an earlier commit

As per requested in the code review, the line breaks that were added in an earlier commit are now
removed. While this does make reading the text just slightly more difficult (to see the whole
picture), the benefit of making code reviews easier does outweight the admittedly small benefit.

README.md

@@ -1,8 +1,8 @@
 <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://spectrum.chat/semantic-release">
-    <img alt="Join the community on Spectrum" src="https://withspectrum.github.io/badge/badge.svg">
+  <a href="https://github.com/semantic-release/semantic-release/discussions">
+    <img alt="Join the community on GitHub Discussions" src="https://img.shields.io/badge/Join%20the%20community-on%20GitHub%20Discussions-blue">
   </a>
   <a href="https://github.com/semantic-release/semantic-release/actions?query=workflow%3ATest+branch%3Amaster">
     <img alt="Build states" src="https://github.com/semantic-release/semantic-release/workflows/Test/badge.svg">
@@ -48,7 +48,7 @@ This removes the immediate connection between human emotions and version numbers
 
 **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 publishes 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.
+By default **semantic-release** uses [Angular Commit Message Conventions](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format). 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) or [commitlint](https://github.com/conventional-changelog/commitlint) can be used to help contributors and enforce valid commit messages.
 
@@ -131,7 +131,7 @@ In order to use **semantic-release** you need:
 ## Get help
 
 - [Stack Overflow](https://stackoverflow.com/questions/tagged/semantic-release)
-- [Spectrum community](https://spectrum.chat/semantic-release)
+- [GitHub Discussions](https://github.com/semantic-release/semantic-release/discussions)
 - [Twitter](https://twitter.com/SemanticRelease)
 
 ## Badge

docs/README.md

@@ -1,7 +1,7 @@
 # semantic-release documentation
 
 - [Usage](usage/README.md) - **semantic-release** installation and configuration
-- [Extending](extending/README.md)- Extending **semantic-release** with plugins and shareable configurations
+- [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
 - [Support](support/README.md) - FAQ and troubleshooting

docs/developer-guide/plugin.md

@@ -1,14 +1,18 @@
 # Plugin Developer Guide
 
-To create a plugin for `semantic-release`, you need to decide which parts of the release lifecycle are important to that plugin. For example, it is best to always have a `verify` step because you may be receiving inputs from a user and want to make sure they exist. A plugin can abide by any of the following lifecycles:
+To create a plugin for `semantic-release`, you need to decide which parts of the release lifecycle are important to that plugin. For example, it is best to always have a `verifyConditions` step because you may be receiving inputs from a user and want to make sure they exist. A plugin can abide by any of the following lifecycles:
 
-- `verify`
+- `verifyConditions`
+- `analyzeCommits`
+- `verifyRelease`
+- `generateNotes`
+- `addChannel`
 - `prepare`
 - `publish`
 - `success`
 - `fail`
 
-`semantic-release` will require the plugin via `node` and look through the required object for methods named like the lifecyles stated above. For example, if your plugin only had a `verify` and `success` step, the `main` file for your object would need to `export` an object with `verify` and `success` functions.
+`semantic-release` will require the plugin via `node` and look through the required object for methods named like the lifecyles stated above. For example, if your plugin only had a `verifyConditions` and `success` step, the `main` file for your object would need to `export` an object with `verifyConditions` and `success` functions.
 
 In addition to the lifecycle methods, each lifecyle is passed two objects:
 
@@ -93,7 +97,131 @@ if (message.length) {
 }
 ```
 
-## Supporting Environment Variables
+## Context
+
+### Common context keys
+
+* `stdout`
+* `stderr`
+* `logger`
+
+### Context object keys by lifecycle
+
+#### verifyConditions
+
+Initially the context object contains the following keys (`verifyConditions` lifecycle):
+* `cwd`
+  * Current working directory
+* `env`
+  * Environment variables
+* `envCi`
+  * Information about CI environment
+  * Contains (at least) the following keys:
+    * `isCi`
+      * Boolean, true if the environment is a CI environment
+    * `commit`
+      * Commit hash
+    * `branch`
+      * Current branch
+* `options`
+  * Options passed to `semantic-release` via CLI, configuration files etc.
+* `branch`
+  * Information on the current branch
+  * Object keys:
+    * `channel`
+    * `tags`
+    * `type`
+    * `name`
+    * `range`
+    * `accept`
+    * `main`
+* `branches`
+  * Information on branches
+  * List of branch objects (see above)
+
+#### analyzeCommits
+
+Compared to the verifyConditions, `analyzeCommits` lifecycle context has keys
+
+* `commits` (List)
+  * List of commits taken into account when determining the new version.
+  * Keys:
+    * `commit` (Object)
+      * Keys:
+        * `long` (String, Commit hash)
+        * `short` (String, Commit hash)
+    * `tree` (Object)
+      * Keys:
+        * `long` (String, Commit hash)
+        * `short` (String, Commit hash)
+    * `author` (Object)
+      * Keys:
+        * `name` (String)
+        * `email` (String)
+        * `date` (String, ISO 8601 timestamp)
+    * `committer` (Object)
+      * Keys:
+        * `name` (String)
+        * `email` (String)
+        * `date` (String, ISO 8601 timestamp)
+    * `subject` (String, Commit message subject)
+    * `body` (String, Commit message body)
+    * `hash` (String, Commit hash)
+    * `committerDate` (String, ISO 8601 timestamp)
+    * `message` (String)
+    * `gitTags` (String, List of git tags)
+* `releases` (List)
+* `lastRelease` (Object)
+  * Keys
+    * `version` (String)
+    * `gitTag` (String)
+    * `channels` (List)
+    * `gitHead` (String, Commit hash)
+    * `name` (String)
+
+#### verifyRelease
+
+Additional keys:
+
+* `nextRelease`
+  * Similar object as `lastRelease` (see above)
+
+#### generateNotes
+
+No new content in the context.
+
+#### addChannel
+
+*This is run only if there are releases that have been merged from a higher branch but not added on the channel of the current branch.*
+
+Context content is similar to lifecycle `verifyRelease`.
+
+#### prepare
+
+Only change is that `generateNotes` has populated `nextRelease.notes`.
+
+#### publish
+
+No new content in the context.
+
+#### success
+
+Lifecycles `success` and `fail` are mutually exclusive, only one of them will be run.
+
+Additional keys:
+
+* `releases`
+  * Populated by `publish` lifecycle
+
+#### fail
+
+Lifecycles `success` and `fail` are mutually exclusive, only one of them will be run.
+
+Additional keys:
+
+* `errors`
+
+### Supporting Environment Variables
 
 Similar to `options`, environment variables exist to allow users to pass tokens and set special URLs. These are set on the `context` object instead of the `pluginConfig` object. Let's say we wanted to check for `GITHUB_TOKEN` in the environment because we want to post to GitHub on the user's behalf. To do this, we can add the following to our `verify` command:
 
@@ -101,6 +229,6 @@ Similar to `options`, environment variables exist to allow users to pass tokens
 const { env } = context;
 
 if (env.GITHUB_TOKEN) {
-    //...
+  //...
 }
-```
+```

docs/extending/plugins-list.md

@@ -20,7 +20,7 @@
   - `publish`: Publish the package on the npm registry
 - [@semantic-release/gitlab](https://github.com/semantic-release/gitlab)
   - `verifyConditions`: Verify the presence and the validity of the GitLab authentication and release configuration
-  - `publish`: Publish a [GitLab release](https://docs.gitlab.com/ce/workflow/releases.html)
+  - `publish`: Publish a [GitLab release](https://docs.gitlab.com/ee/user/project/releases/)
 - [@semantic-release/git](https://github.com/semantic-release/git)
   - `verifyConditions`: Verify the presence and the validity of the Git authentication and release configuration
   - `prepare`: Push a release commit and tag, including configurable files
@@ -91,6 +91,9 @@
 - [semantic-release-github-pages](https://github.com/qiwi/semantic-release-gh-pages-plugin)
   - `verifyConditions`: Verify the presence of the auth token set via environment variables.
   - `publish`: Pushes commit to the documentation branch.
+- [semantic-release-github-pullrequest](https://github.com/asbiin/semantic-release-github-pullrequest)
+  - `verifyConditions`: Verify the presence and the validity of the GitHub authentication and other configuration.
+  - `publish`: Create a branch to upload all assets and create the pull request on the base branch on GitHub.
 - [leiningen-semantic-release](https://github.com/NoxHarmonium/leiningen-semantic-release)
   - `verifyConditions`: Checks the project.clj is syntactically valid.
   - `prepare`: Update the project.clj version and package the output jar file.

docs/recipes/distribution-channels.md

@@ -97,7 +97,7 @@ The Git history of the repository is now:
 
 After a period of feedback from our users using the `@next` dist-tag we feel confident to make our big feature available to all users. To do so we merge the `next` branch into `master`. There should be no conflict as `next` is strictly ahead of `master`.
 
-Once the merge commit is pushed to `next`, **semantic-release** will add the version `2.1.0` to the dist-tag `@latest` so all users will receive it when installing out module with `npm install example-module`.
+Once the merge commit is pushed to `master`, **semantic-release** will add the version `2.1.0` to the dist-tag `@latest` so all users will receive it when installing out module with `npm install example-module`.
 
 The Git history of the repository is now:
 

docs/recipes/github-actions.md

@@ -25,7 +25,7 @@ on:
 jobs:
   release:
     name: Release
-    runs-on: ubuntu-18.04
+    runs-on: ubuntu-latest
     steps:
       - name: Checkout
         uses: actions/checkout@v2

docs/support/resources.md

@@ -15,6 +15,7 @@
 - ["Introduction to SemVer" - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2)
 - ["Introduction to Semantic Release" - liv](https://blog.greenkeeper.io/introduction-to-semantic-release-33f73b117c8)
 - ["Series - Semantic Release Automation" - Abdelrahman Wahdan](https://dev.to/abdelrahmanahmed/semantic-release-and-how-to-automate-it-part-1-4pa2)
+- ["Explain semantic release and how to use it on GitLab pipeline"](https://regoo707.medium.com/auto-bump-apps-versions-and-releases-using-gitlab-pipeline-e32f1d7fa3ee)
 
 ## Tutorials
 

docs/support/troubleshooting.md

@@ -65,5 +65,5 @@ To recover from that situation, do the following:
 
 1. Delete the tag(s) for the release(s) that have been lost from the git history. You can delete each tag from remote using `git push origin :[TAG NAME]`, e.g. `git push origin :v2.0.0-beta.1`. You can delete tags locally using `git tag -d [TAG NAME]`, e.g. `git tag -d v2.0.0-beta.1`.
 2. Re-create the tags locally: `git tag [TAG NAME] [COMMIT HASH]`, where `[COMMIT HASH]` is the new commit that created the release for the lost tag. E.g. `git tag v2.0.0-beta.1 abcdef0`
-3. Re-create the git notes for each release tag, e.g. `git notes --ref semantic-release add -f -m '{"channels":["beta"]}' v3.0.0-beta.1`. If the release was also published in the default channel (usually `master`), then set the first channel to `null`, e.g. `git notes --ref semantic-release add -f -m '{"channels":[null, "beta"]}'
+3. Re-create the git notes for each release tag, e.g. `git notes --ref semantic-release add -f -m '{"channels":["beta"]}' v2.0.0-beta.1`. If the release was also published in the default channel (usually `master`), then set the first channel to `null`, e.g. `git notes --ref semantic-release add -f -m '{"channels":[null, "beta"]}'
 4. Push the local notes: `git push --force origin refs/notes/semantic-release`. The `--force` is needed after the rebase. Be careful.

docs/usage/ci-configuration.md

@@ -8,7 +8,7 @@ Here is a few example of the CI services that can be used to achieve this:
 - [CircleCI Workflows](https://circleci.com/docs/2.0/workflows)
 - [GitHub Actions](https://github.com/features/actions)
 - [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)
+- [GitLab Pipelines](https://docs.gitlab.com/ce/ci/introduction/)
 - [Codefresh Pipelines](https://codefresh.io/docs/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines)
 - [Wercker Workflows](http://devcenter.wercker.com/docs/workflows)
 - [GoCD Pipelines](https://docs.gocd.org/current/introduction/concepts_in_go.html#pipeline).

lib/get-config.js

@@ -9,19 +9,10 @@ const plugins = require('./plugins');
 const {validatePlugin, parseConfig} = require('./plugins/utils');
 
 const CONFIG_NAME = 'release';
-const CONFIG_FILES = [
-  'package.json',
-  `.${CONFIG_NAME}rc`,
-  `.${CONFIG_NAME}rc.json`,
-  `.${CONFIG_NAME}rc.yaml`,
-  `.${CONFIG_NAME}rc.yml`,
-  `.${CONFIG_NAME}rc.js`,
-  `${CONFIG_NAME}.config.js`,
-];
 
 module.exports = async (context, cliOptions) => {
   const {cwd, env} = context;
-  const {config, filepath} = (await cosmiconfig(CONFIG_NAME, {searchPlaces: CONFIG_FILES}).search(cwd)) || {};
+  const {config, filepath} = (await cosmiconfig(CONFIG_NAME).search(cwd)) || {};
 
   debug('load config from: %s', filepath);
 

lib/git.js

@@ -318,7 +318,7 @@ async function getNote(ref, execaOptions) {
 }
 
 /**
- * Get and parse the JSON note of a given reference.
+ * Add JSON note to a given reference.
  *
  * @param {Object} note The object to save in the reference note.
  * @param {String} ref The Git reference to add the note to.

package.json

@@ -35,10 +35,10 @@
     "get-stream": "^6.0.0",
     "git-log-parser": "^1.2.0",
     "hook-std": "^2.0.0",
-    "hosted-git-info": "^3.0.0",
-    "lodash": "^4.17.15",
+    "hosted-git-info": "^4.0.0",
+    "lodash": "^4.17.21",
     "marked": "^2.0.0",
-    "marked-terminal": "^4.0.0",
+    "marked-terminal": "^4.1.1",
     "micromatch": "^4.0.2",
     "p-each-series": "^2.1.0",
     "p-reduce": "^2.0.0",
@@ -57,12 +57,12 @@
     "dockerode": "3.2.1",
     "file-url": "3.0.0",
     "fs-extra": "9.1.0",
-    "got": "11.8.1",
-    "js-yaml": "3.14.0",
+    "got": "11.8.2",
+    "js-yaml": "3.14.1",
     "mockserver-client": "5.11.2",
-    "nock": "13.0.7",
+    "nock": "13.0.11",
     "nyc": "15.1.0",
-    "p-retry": "4.3.0",
+    "p-retry": "4.5.0",
     "proxyquire": "2.1.3",
     "sinon": "9.2.4",
     "stream-buffers": "3.0.2",

test/get-config.test.js

@@ -191,6 +191,28 @@ test('Read options from .releaserc.js', async (t) => {
   t.deepEqual(t.context.plugins.args[0][0], {options: expected, cwd});
 });
 
+test('Read options from .releaserc.cjs', async (t) => {
+  // Create a git repository, set the current working directory at the root of the repo
+  const {cwd} = await gitRepo();
+  const options = {
+    analyzeCommits: {path: 'analyzeCommits', param: 'analyzeCommits_param'},
+    branches: ['test_branch'],
+    repositoryUrl: 'https://host.null/owner/module.git',
+    tagFormat: `v\${version}`,
+    plugins: false,
+  };
+  // Create .releaserc.cjs in repository root
+  await writeFile(path.resolve(cwd, '.releaserc.cjs'), `module.exports = ${JSON.stringify(options)}`);
+
+  const {options: result} = await t.context.getConfig({cwd});
+
+  const expected = {...options, branches: ['test_branch']};
+  // Verify the options contains the plugin config from .releaserc.cjs
+  t.deepEqual(result, expected);
+  // Verify the plugins module is called with the plugin options from .releaserc.cjs
+  t.deepEqual(t.context.plugins.args[0][0], {options: expected, cwd});
+});
+
 test('Read options from release.config.js', async (t) => {
   // Create a git repository, set the current working directory at the root of the repo
   const {cwd} = await gitRepo();
@@ -213,6 +235,28 @@ test('Read options from release.config.js', async (t) => {
   t.deepEqual(t.context.plugins.args[0][0], {options: expected, cwd});
 });
 
+test('Read options from release.config.cjs', async (t) => {
+  // Create a git repository, set the current working directory at the root of the repo
+  const {cwd} = await gitRepo();
+  const options = {
+    analyzeCommits: {path: 'analyzeCommits', param: 'analyzeCommits_param'},
+    branches: ['test_branch'],
+    repositoryUrl: 'https://host.null/owner/module.git',
+    tagFormat: `v\${version}`,
+    plugins: false,
+  };
+  // Create release.config.cjs in repository root
+  await writeFile(path.resolve(cwd, 'release.config.cjs'), `module.exports = ${JSON.stringify(options)}`);
+
+  const {options: result} = await t.context.getConfig({cwd});
+
+  const expected = {...options, branches: ['test_branch']};
+  // Verify the options contains the plugin config from release.config.cjs
+  t.deepEqual(result, expected);
+  // Verify the plugins module is called with the plugin options from release.config.cjs
+  t.deepEqual(t.context.plugins.args[0][0], {options: expected, cwd});
+});
+
 test('Prioritise CLI/API parameters over file configuration and git repo', async (t) => {
   // Create a git repository, set the current working directory at the root of the repo
   let {cwd, repositoryUrl} = await gitRepo();