diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 37a06085b4..b5282a3150 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -63,7 +63,8 @@ jobs: cache: npm # run npm link to install current directory globally this is similar to `sudo npm install -g semantic-release` # we need to eat our own dog food not our previously published version - - run: sudo npm link + - run: npm ci --ignore-scripts + - run: sudo npm link --ignore-scripts - run: npx semantic-release-plus env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d6b24e4f94..018b51eaba 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -21,45 +21,55 @@ Help us keep **semantic-release** open and inclusive. Please read and follow our ### 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+). +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), 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 guidelines](#documentation). ### Give feedback on issues -Some issues are created without information requested in the [Bug report guideline](#bug-report). Help make them easier to resolve by adding any relevant information. +Some issues are created without information requested in the [Bug report guideline](#bug-report). +Help make them easier to resolve by adding any relevant information. -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**. +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 bugs 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. +Confirmed bugs 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. +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 sure 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 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). +A good bug report shouldn't leave others needing to chase you 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=01_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). +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=02_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). +[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 [plugin suggestion template](https://github.com/semantic-release/semantic-release/issues/new?template=03_plugin_suggestion.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. +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 requests (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. +**Please ask first** before embarking on any significant pull requests (e.g. implementing features, refactoring code), otherwise you risk spending a lot of time working on something that the project's maintainers might not want to merge into the project. -If you have 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 :) +If you have 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: @@ -91,7 +101,9 @@ $ git push origin **Tips**: - For ambitious tasks, open a Pull Request as soon as possible with the `[WIP]` prefix in the title, in order to get feedback and help from the community. -- [Allow semantic-release maintainers to make changes to your 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. +- [Allow semantic-release maintainers to make changes to your 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 @@ -140,7 +152,8 @@ A complex feature can be broken down into multiple commits as long as each one m #### 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**: +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 (): @@ -156,7 +169,8 @@ The **footer** can contain a [closing reference to an issue](https://help.github #### 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 .`, where the hash is the SHA of the commit being reverted. +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 .`, where the hash is the SHA of the commit being reverted. #### Type @@ -191,7 +205,8 @@ The body should include the motivation for the change and contrast this with pre 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. +**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 @@ -232,7 +247,8 @@ $ npm install ### Lint -All the [semantic-release](https://github.com/semantic-release) repositories 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. +All the [semantic-release](https://github.com/semantic-release) repositories 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 are no linting errors with `npm run lint`. diff --git a/README.md b/README.md index ec728086d8..46e99bf732 100644 --- a/README.md +++ b/README.md @@ -50,9 +50,9 @@ This removes the immediate connection between human emotions and version numbers - Notify maintainers and users of new releases - Use formalized commit message convention to document changes in the codebase - Publish on different distribution channels (such as [npm dist-tags](https://docs.npmjs.com/cli/dist-tag)) based on git merges -- Integrate with your [continuous integration workflow](docs/recipes/README.md#ci-configurations) +- Integrate with your [continuous integration workflow](docs/recipes/release-workflow/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) +- Support any [package managers and languages](docs/recipes/release-workflow/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? @@ -69,11 +69,11 @@ Tools such as [commitizen](https://github.com/commitizen/cz-cli) or [commitlint] The table below shows which commit message gets you which release type when `semantic-release` runs (using the default configuration): -| Commit message | Release type | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------- | -| `fix(pencil): stop graphite breaking when too much pressure applied` | ~~Patch~~ Fix Release | -| `feat(pencil): add 'graphiteWidth' option` | ~~Minor~~ Feature 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.` | ~~Major~~ Breaking Release | +| Commit message | Release type | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------- | +| `fix(pencil): stop graphite breaking when too much pressure applied` | ~~Patch~~ Fix Release | +| `feat(pencil): add 'graphiteWidth' option` | ~~Minor~~ Feature 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.` | ~~Major~~ Breaking Release
(Note that the `BREAKING CHANGE: ` token must be in the footer of the commit) | ### Automation with CI @@ -87,9 +87,9 @@ For each new commit added to one of the release branches (for example: `master`, **semantic-release** offers various ways to control the timing, the content and the audience of published releases. See example workflows in the following recipes: -- [Using distribution channels](docs/recipes/distribution-channels.md#publishing-on-distribution-channels) -- [Maintenance releases](docs/recipes/maintenance-releases.md#publishing-maintenance-releases) -- [Pre-releases](docs/recipes/pre-releases.md#publishing-pre-releases) +- [Using distribution channels](docs/recipes/release-workflow/distribution-channels.md#publishing-on-distribution-channels) +- [Maintenance releases](docs/recipes/release-workflow/maintenance-releases.md#publishing-maintenance-releases) +- [Pre-releases](docs/recipes/release-workflow/pre-releases.md#publishing-pre-releases) ### Release steps @@ -130,10 +130,9 @@ In order to use **semantic-release** you need: - [Plugins](docs/extending/plugins-list.md) - [Shareable configuration](docs/extending/shareable-configurations-list.md) - Recipes - - [CI configurations](docs/recipes/README.md) - - [Git hosted services](docs/recipes/README.md) - - [Release workflow](docs/recipes/README.md) - - [Package managers and languages](docs/recipes/README.md) + - [CI configurations](docs/recipes/ci-configurations/README.md) + - [Git hosted services](docs/recipes/git-hosted-services/README.md) + - [Release workflow](docs/recipes/release-workflow/README.md) - Developer guide - [JavaScript API](docs/developer-guide/js-api.md) - [Plugins development](docs/developer-guide/plugin.md) @@ -153,12 +152,12 @@ In order to use **semantic-release** you need: ## Badge -Let people know that your package is published using **semantic-release** by including this badge in your readme. +Let people know that your package is published using **semantic-release** and which [commit-convention](#commit-message-format) is followed by including this badge in your readme. -[![semantic-release](https://img.shields.io/badge/semantic-release-e10079.svg?logo=semantic-release)](https://github.com/semantic-release/semantic-release) +[![semantic-release: angular](https://img.shields.io/badge/semantic--release-angular-e10079?logo=semantic-release)](https://github.com/semantic-release/semantic-release) ```md -[![semantic-release](https://img.shields.io/badge/semantic-release-e10079.svg?logo=semantic-release)](https://github.com/semantic-release/semantic-release) +[![semantic-release: angular](https://img.shields.io/badge/semantic--release-angular-e10079?logo=semantic-release)](https://github.com/semantic-release/semantic-release) ``` ## Contributors ✨ diff --git a/SUMMARY.md b/SUMMARY.md index 15e94851e7..27fe666fe7 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -19,22 +19,21 @@ ## Recipes -- [CI configurations](docs/recipes/README.md#ci-configurations) - - [CircleCI 2.0](docs/recipes/circleci-workflows.md) - - [Travis CI](docs/recipes/travis.md) - - [GitLab CI](docs/recipes/gitlab-ci.md) - - [GitHub Actions](docs/recipes/github-actions.md) - - [Jenkins CI](docs/recipes/jenkins-ci.md) -- [Git hosted services](docs/recipes/README.md#git-hosted-services) - - [Git authentication with SSH keys](docs/recipes/git-auth-ssh-keys.md) -- [Release Workflow](docs/recipes/README.md#release-workflow) - - [Publishing on distribution channels](docs/recipes/distribution-channels.md) - - [Publishing maintenance releases](docs/recipes/maintenance-releases.md) - - [Publishing pre-releases](docs/recipes/pre-releases.md) -- [Package managers and languages](recipes/package-managers-and-languages.md) -- [Monorepos](docs/recipes/README.md#Monorepos) +- [CI configurations](docs/recipes/ci-configurations/README.md) + - [CircleCI 2.0](docs/recipes/ci-configurations/circleci-workflows.md) + - [Travis CI](docs/recipes/ci-configurations/travis.md) + - [GitLab CI](docs/recipes/ci-configurations/gitlab-ci.md) + - [GitHub Actions](docs/recipes/ci-configurations/github-actions.md) + - [Jenkins CI](docs/recipes/ci-configurations/jenkins-ci.md) +- [Git hosted services](docs/recipes/git-hosted-services/README.md) + - [Git authentication with SSH keys](docs/recipes/git-hosted-services/git-auth-ssh-keys.md) +- [Release Workflow](docs/recipes/release-workflow/README.md) + - [Publishing on distribution channels](docs/recipes/release-workflow/distribution-channels.md) + - [Publishing maintenance releases](docs/recipes/release-workflow/maintenance-releases.md) + - [Publishing pre-releases](docs/recipes/release-workflow/pre-releases.md) +- [Monorepos](docs/recipes/nx-monorepo.md) - [nx monorepo](docs/recipes/nx-monorepo.md) -- [Utility](docs/recipes/README.md#Utility) +- [Utility](docs/recipes/expected-next-version.md) - [Get expected next version](docs/recipes/expected-next-version.md) ## Developer guide diff --git a/docs/README.md b/docs/README.md index ce1e098c5e..748d07025d 100644 --- a/docs/README.md +++ b/docs/README.md @@ -2,6 +2,6 @@ - [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 +- [Recipes](recipes/release-workflow/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 diff --git a/docs/extending/plugins-list.md b/docs/extending/plugins-list.md index bc56f45bbb..35dd7f4018 100644 --- a/docs/extending/plugins-list.md +++ b/docs/extending/plugins-list.md @@ -55,7 +55,8 @@ - `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag - [@semantic-release-plus/docker](https://github.com/semantic-release-plus/semantic-release-plus/tree/master/packages/plugins/docker) - `verifyConditions`: Verify that all needed configuration is present and login to the configured docker registry. - - `publish`: Tag the image specified by `name` with the new version, push it to the configured docker registry and update the `latest`, `major`, `minor` tags based on the configuration settings. + - `publish`: Tag the image specified by `name` with the new version and channel and push it to the configured docker registry. + - `addChannel`: Updates a release published on one channel with the destinations channel tag and pushes to the registry ie: next to latest. - [semantic-release-gcr](https://github.com/carlos-cubas/semantic-release-gcr) - `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry - `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag diff --git a/docs/recipes/README.md b/docs/recipes/README.md deleted file mode 100644 index 242d4f61cf..0000000000 --- a/docs/recipes/README.md +++ /dev/null @@ -1,29 +0,0 @@ -# Recipes - -## CI configurations - -- [CircleCI 2.0 workflows](circleci-workflows.md) -- [Travis CI](travis.md) -- [GitLab CI](gitlab-ci.md) -- [GitHub Actions](github-actions.md) -- [Jenkins CI](jenkins-ci.md) - -## Git hosted services - -- [Git authentication with SSH keys](git-auth-ssh-keys.md) - -## Release workflow - -- [Publishing on distribution channels](distribution-channels.md) -- [Publishing maintenance releases](maintenance-releases.md) -- [Publishing pre-releases](pre-releases.md) - -## Monorepos - -- [nx mono repo](nx-mono-repo.md) - -## Utility - -- [Get expected next version](expected-next-version.md) - -## Package managers and languages diff --git a/docs/recipes/ci-configurations/README.md b/docs/recipes/ci-configurations/README.md new file mode 100644 index 0000000000..ea0f639bf5 --- /dev/null +++ b/docs/recipes/ci-configurations/README.md @@ -0,0 +1,7 @@ +# CI configurations + +- [CircleCI 2.0 workflows](circleci-workflows.md) +- [Travis CI](travis.md) +- [GitLab CI](gitlab-ci.md) +- [GitHub Actions](github-actions.md) +- [Jenkins CI](jenkins-ci.md) diff --git a/docs/recipes/circleci-workflows.md b/docs/recipes/ci-configurations/circleci-workflows.md similarity index 86% rename from docs/recipes/circleci-workflows.md rename to docs/recipes/ci-configurations/circleci-workflows.md index 548aaf1f5f..468e23b555 100644 --- a/docs/recipes/circleci-workflows.md +++ b/docs/recipes/ci-configurations/circleci-workflows.md @@ -2,9 +2,9 @@ ## Environment variables -The [Authentication](../usage/ci-configuration.md#authentication) environment variables can be configured in [CircleCi Project Settings](https://circleci.com/docs/2.0/env-vars/#adding-environment-variables-in-the-app).. +The [Authentication](../../usage/ci-configuration.md#authentication) environment variables can be configured in [CircleCi Project Settings](https://circleci.com/docs/2.0/env-vars/#adding-environment-variables-in-the-app).. -Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../usage/getting-started.md#getting-started). +Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../../usage/getting-started.md#getting-started). ## Multiple Node jobs configuration diff --git a/docs/recipes/github-actions.md b/docs/recipes/ci-configurations/github-actions.md similarity index 94% rename from docs/recipes/github-actions.md rename to docs/recipes/ci-configurations/github-actions.md index 370982dfbf..e3cd6e9bba 100644 --- a/docs/recipes/github-actions.md +++ b/docs/recipes/ci-configurations/github-actions.md @@ -2,7 +2,7 @@ ## Environment variables -The [Authentication](../usage/ci-configuration.md#authentication) environment variables can be configured with [Secret Variables](https://docs.github.com/en/actions/reference/encrypted-secrets). +The [Authentication](../../usage/ci-configuration.md#authentication) environment variables can be configured with [Secret Variables](https://docs.github.com/en/actions/reference/encrypted-secrets). In this example a publish type [`NPM_TOKEN`](https://docs.npmjs.com/creating-and-viewing-authentication-tokens) is required to publish a package to the npm registry. GitHub Actions [automatically populate](https://help.github.com/en/articles/virtual-environments-for-github-actions#github_token-secret) a [`GITHUB_TOKEN`](https://help.github.com/en/articles/creating-a-personal-access-token-for-the-command-line) environment variable which can be used in Workflows. @@ -10,7 +10,7 @@ In this example a publish type [`NPM_TOKEN`](https://docs.npmjs.com/creating-and [GitHub Actions](https://github.com/features/actions) support [Workflows](https://help.github.com/en/articles/configuring-workflows), allowing to run tests on multiple Node versions and publish a release only when all test pass. -**Note**: The publish pipeline must run on a [Node version that meets our version requirement](../support/node-version.md). +**Note**: The publish pipeline must run on a [Node version that meets our version requirement](../../support/node-version.md). ### `.github/workflows/release.yml` configuration for Node projects diff --git a/docs/recipes/gitlab-ci.md b/docs/recipes/ci-configurations/gitlab-ci.md similarity index 76% rename from docs/recipes/gitlab-ci.md rename to docs/recipes/ci-configurations/gitlab-ci.md index f1cfe634ce..f272bbb54c 100644 --- a/docs/recipes/gitlab-ci.md +++ b/docs/recipes/ci-configurations/gitlab-ci.md @@ -2,7 +2,7 @@ ## Environment variables -The [Authentication](../usage/ci-configuration.md#authentication) environment variables can be configured with [Protected variables](https://docs.gitlab.com/ce/ci/variables/README.html#protected-environment-variables). +The [Authentication](../../usage/ci-configuration.md#authentication) environment variables can be configured with [Protected variables](https://docs.gitlab.com/ce/ci/variables/README.html#protected-environment-variables). **Note**: Make sure to configure your release branch as [protected](https://docs.gitlab.com/ce/user/project/protected_branches.html) in order for the CI/CD build to access the protected variables. @@ -10,13 +10,13 @@ The [Authentication](../usage/ci-configuration.md#authentication) environment va 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 version that meets our version requirement](../support/node-version.md). +**Note**: The publish pipeline must run a [Node version that meets our version requirement](../../support/node-version.md). ### `.gitlab-ci.yml` configuration for Node projects This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. 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 on whether you are using a [local](../usage/installation.md#local-installation) or [global](../usage/installation.md#global-installation) **semantic-release** installation. +**Note**: The`semantic-release` execution command varies depending on whether 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 @@ -50,7 +50,7 @@ publish: This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. 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. +**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 on the master branch a commit is triggered @@ -82,7 +82,7 @@ release: ### `package.json` configuration -A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation. +A `package.json` is required only for [local](../../usage/installation.md#local-installation) **semantic-release** installation. ```json { diff --git a/docs/recipes/jenkins-ci.md b/docs/recipes/ci-configurations/jenkins-ci.md similarity index 77% rename from docs/recipes/jenkins-ci.md rename to docs/recipes/ci-configurations/jenkins-ci.md index d5a36dacf1..69b6d880a7 100644 --- a/docs/recipes/jenkins-ci.md +++ b/docs/recipes/ci-configurations/jenkins-ci.md @@ -2,15 +2,15 @@ ## Environment variables -The [Authentication](../usage/ci-configuration.md#authentication) environment variables can be configured in [Jenkins Project Settings](https://www.jenkins.io/doc/pipeline/tour/environment/).. +The [Authentication](../../usage/ci-configuration.md#authentication) environment variables can be configured in [Jenkins Project Settings](https://www.jenkins.io/doc/pipeline/tour/environment/).. -Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../usage/getting-started.md#getting-started). +Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../../usage/getting-started.md#getting-started). ## Node.js project configuration ### `Jenkinsfile (Declarative Pipeline)` configuration for a Node.js job -**Note**: The publish pipeline must run a Node version that [meets our requirement](../support/node-version.md). +**Note**: The publish pipeline must run a Node version that [meets our requirement](../../support/node-version.md). This example is a minimal configuration for **semantic-release** with a build running a version of Node labelled as "node LTS". Since versions of Node are manually downloaded and labelled, we recommend keeping the version used for the release steps up-to-date with the latest LTS version. @@ -50,7 +50,7 @@ pipeline { ### `package.json` configuration for a Node job -A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation. +A `package.json` is required only for [local](../../usage/installation.md#local-installation) **semantic-release** installation. ```json { diff --git a/docs/recipes/travis.md b/docs/recipes/ci-configurations/travis.md similarity index 81% rename from docs/recipes/travis.md rename to docs/recipes/ci-configurations/travis.md index d789a0d143..1a9a05204f 100644 --- a/docs/recipes/travis.md +++ b/docs/recipes/ci-configurations/travis.md @@ -2,9 +2,9 @@ ## 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). +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/getting-started.md#getting-started). +Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../../usage/getting-started.md#getting-started). ## Node.js projects configuration @@ -12,7 +12,7 @@ Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with This example is a minimal configuration for **semantic-release** with a build running Node 14 and 16. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options. -This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded). +This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](../../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded). It's recommended to run the `semantic-release` command in the [Travis `deploy` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error occurs the build will fail and Travis will send a notification. @@ -43,7 +43,7 @@ jobs: ### `package.json` configuration for multiple Node jobs -A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation. +A `package.json` is required only for [local](../../usage/installation.md#local-installation) **semantic-release** installation. ```json { @@ -57,13 +57,13 @@ A `package.json` is required only for [local](../usage/installation.md#local-ins 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. +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). See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options. -This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded). +This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](../../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded). It's recommended to run the `semantic-release` command in the [Travis `deploy` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error occurs the build will fail and Travis will send a notification. diff --git a/docs/recipes/git-hosted-services/README.md b/docs/recipes/git-hosted-services/README.md new file mode 100644 index 0000000000..8c8639341b --- /dev/null +++ b/docs/recipes/git-hosted-services/README.md @@ -0,0 +1,3 @@ +# Git hosted services + +- [Git authentication with SSH keys](git-auth-ssh-keys.md) diff --git a/docs/recipes/git-auth-ssh-keys.md b/docs/recipes/git-hosted-services/git-auth-ssh-keys.md similarity index 93% rename from docs/recipes/git-auth-ssh-keys.md rename to docs/recipes/git-hosted-services/git-auth-ssh-keys.md index a099a45590..0fe2504cf1 100644 --- a/docs/recipes/git-auth-ssh-keys.md +++ b/docs/recipes/git-hosted-services/git-auth-ssh-keys.md @@ -1,6 +1,6 @@ # Git authentication with SSH keys -When using [environment variables](../usage/ci-configuration.md#authentication) to set up the Git authentication, the remote Git repository will automatically be accessed via [https](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_http_protocols), independently of the [`repositoryUrl`](../usage/configuration.md#repositoryurl) format configured in the **semantic-release** [Configuration](../usage/configuration.md#configuration) (the format will be automatically converted as needed). +When using [environment variables](../../usage/ci-configuration.md#authentication) to set up the Git authentication, the remote Git repository will automatically be accessed via [https](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_http_protocols), independently of the [`repositoryUrl`](../../usage/configuration.md#repositoryurl) format configured in the **semantic-release** [Configuration](../../usage/configuration.md#configuration) (the format will be automatically converted as needed). Alternatively the Git repository can be accessed via [SSH](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_ssh_protocol) by creating SSH keys, adding the public one to your Git hosted account and making the private one available on the CI environment. diff --git a/docs/recipes/release-workflow/README.md b/docs/recipes/release-workflow/README.md new file mode 100644 index 0000000000..4597f603cf --- /dev/null +++ b/docs/recipes/release-workflow/README.md @@ -0,0 +1,5 @@ +# Release workflow + +- [Publishing on distribution channels](distribution-channels.md) +- [Publishing maintenance releases](maintenance-releases.md) +- [Publishing pre-releases](pre-releases.md) diff --git a/docs/recipes/distribution-channels.md b/docs/recipes/release-workflow/distribution-channels.md similarity index 93% rename from docs/recipes/distribution-channels.md rename to docs/recipes/release-workflow/distribution-channels.md index 122c3e142e..67da47e21e 100644 --- a/docs/recipes/distribution-channels.md +++ b/docs/recipes/release-workflow/distribution-channels.md @@ -4,8 +4,8 @@ This recipe will walk you through a simple example that uses distribution channe This example uses the **semantic-release** default configuration: -- [branches](../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]` -- [plugins](../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']` +- [branches](../../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]` +- [plugins](../../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']` ## Initial release diff --git a/docs/recipes/maintenance-releases.md b/docs/recipes/release-workflow/maintenance-releases.md similarity index 95% rename from docs/recipes/maintenance-releases.md rename to docs/recipes/release-workflow/maintenance-releases.md index ebc260747e..a745dde381 100644 --- a/docs/recipes/maintenance-releases.md +++ b/docs/recipes/release-workflow/maintenance-releases.md @@ -4,8 +4,8 @@ This recipe will walk you through a simple example that uses Git branches and di This example uses the **semantic-release** default configuration: -- [branches](../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]` -- [plugins](../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']` +- [branches](../../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]` +- [plugins](../../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']` ## Initial release diff --git a/docs/recipes/pre-releases.md b/docs/recipes/release-workflow/pre-releases.md similarity index 93% rename from docs/recipes/pre-releases.md rename to docs/recipes/release-workflow/pre-releases.md index 928c661809..728c50a352 100644 --- a/docs/recipes/pre-releases.md +++ b/docs/recipes/release-workflow/pre-releases.md @@ -3,9 +3,13 @@ This recipe will walk you through a simple example that uses pre-releases to publish beta versions while working on a future major release and then make only one release on the default distribution. This example uses the **semantic-release** default configuration: +<<<<<<< HEAD:docs/recipes/pre-releases.md - [branches](../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]` -- [plugins](../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']` +- # [plugins](../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']` +- [branches](../../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]` +- [plugins](../../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']` + > > > > > > > dd7d664aa121e6d81057d33ff120d95f1da57067:docs/recipes/release-workflow/pre-releases.md ## Initial release diff --git a/docs/support/FAQ.md b/docs/support/FAQ.md index 5c7e26b36a..aff1686f8c 100644 --- a/docs/support/FAQ.md +++ b/docs/support/FAQ.md @@ -53,7 +53,7 @@ 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 a version of Node that [meets our version requirement](./node-version.md) to execute the `semantic-release` command -See the [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on specific CI environments. +See the [CI configuration recipes](../recipes/release-workflow/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 which is used by default and use a plugin for your project type. @@ -80,7 +80,7 @@ Here is a basic example to create [GitHub releases](https://help.github.com/arti **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. +See the [package managers and languages recipes](../recipes/release-workflow/README.md#package-managers-and-languages) for more details on specific project types. ## Can I use semantic-release with any CI service? @@ -89,7 +89,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](../recipes/README.md#ci-configurations) for more details on specific CI environments. +See the [CI configuration recipes](../recipes/release-workflow/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? @@ -105,7 +105,7 @@ However this is not the recommended approach, as running unit and integration te 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. +See the [GitLab CI recipes](../recipes/ci-configurations/gitlab-ci.md#using-semantic-release-with-gitlab-ci) for the CI configuration. ## Can I use semantic-release with any Git hosted environment? @@ -205,7 +205,7 @@ If you need more control over the timing of releases, see [Triggering a release] 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. -If your project is under heavy development, with frequent breaking changes, and is not production ready yet we recommend [publishing pre-releases](../recipes/pre-releases.md#publishing-pre-releases). +If your project is under heavy development, with frequent breaking changes, and is not production ready yet we recommend [publishing pre-releases](../recipes/release-workflow/pre-releases.md#publishing-pre-releases). 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`. diff --git a/docs/support/node-version.md b/docs/support/node-version.md index 43bb6df042..88b4117ba2 100644 --- a/docs/support/node-version.md +++ b/docs/support/node-version.md @@ -14,7 +14,7 @@ See our [Node Support Policy](node-support-policy.md) for our long-term promise The recommended approach is to run the `semantic-release` command from a CI job running on the latest available LTS version of node. This can either be a job used by your project to test on the latest Node LTS version 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. +See [CI configuration](../usage/ci-configuration.md) and [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details. ## Alternative solutions diff --git a/docs/support/troubleshooting.md b/docs/support/troubleshooting.md index 892338f9cc..d0a5f7c0e7 100644 --- a/docs/support/troubleshooting.md +++ b/docs/support/troubleshooting.md @@ -66,5 +66,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"]}' 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"]}' +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. diff --git a/docs/usage/ci-configuration.md b/docs/usage/ci-configuration.md index 07bf009549..f6355a84d8 100644 --- a/docs/usage/ci-configuration.md +++ b/docs/usage/ci-configuration.md @@ -14,7 +14,7 @@ Here is a few example of the CI services that can be used to achieve this: - [Wercker Workflows](http://devcenter.wercker.com/docs/workflows) - [GoCD Pipelines](https://docs.gocd.org/current/introduction/concepts_in_go.html#pipeline). -See [CI configuration recipes](../recipes/README.md#ci-configurations) for more details. +See [CI configuration recipes](../recipes/ci-configurations/README.md) for more details. ## Authentication @@ -30,7 +30,7 @@ See [CI configuration recipes](../recipes/README.md#ci-configurations) for more | `BB_TOKEN_BASIC_AUTH` or `BITBUCKET_TOKEN_BASIC_AUTH` | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html) with basic auth support. For clearification `user:token` has to be the value of this env. | | `GIT_CREDENTIALS` | [URL encoded](https://en.wikipedia.org/wiki/Percent-encoding) Git username and password in the format `:`. The username and password must each be individually URL encoded, not the `:` separating them. | -Alternatively the Git authentication can be set up via [SSH keys](../recipes/git-auth-ssh-keys.md). +Alternatively the Git authentication can be set up via [SSH keys](../recipes/git-hosted-services/git-auth-ssh-keys.md). ### Authentication for plugins @@ -45,6 +45,6 @@ See each plugin's documentation for the environment variables required. The authentication token/credentials have to be made available in the CI service via environment variables. -See [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on how to configure environment variables in your CI service. +See [CI configuration recipes](../recipes/ci-configurations/README.md) for more details on how to configure environment variables in your CI service. **Note**: The environment variables `GH_TOKEN`, `GITHUB_TOKEN`, `GL_TOKEN` and `GITLAB_TOKEN` can be used for both the Git authentication and the API authentication required by [@semantic-release/github](https://github.com/semantic-release/github) and [@semantic-release/gitlab](https://github.com/semantic-release/gitlab). diff --git a/docs/usage/installation.md b/docs/usage/installation.md index 5ff17d7616..8bcb459707 100644 --- a/docs/usage/installation.md +++ b/docs/usage/installation.md @@ -24,7 +24,7 @@ For other type of projects we recommend installing **semantic-release** directly $ npx semantic-release ``` -**Note**: For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with with `npx semantic-release@18`). +**Note**: For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with `npx semantic-release@18`). 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. diff --git a/docs/usage/workflow-configuration.md b/docs/usage/workflow-configuration.md index c3abaf63e4..735c9d1c89 100644 --- a/docs/usage/workflow-configuration.md +++ b/docs/usage/workflow-configuration.md @@ -2,12 +2,12 @@ **semantic-release** allow to manage and automate complex release workflow, based on multiple Git branches and distribution channels. This allow to: -- Distributes certain releases to a particular group of users via distribution channels +- Distribute certain releases to a particular group of users via distribution channels - Manage the availability of releases on distribution channels via branches merge - Maintain multiple lines of releases in parallel - Work on large future releases outside the normal flow of one version increment per Git push -See [Release workflow recipes](../recipes/README.md#release-workflow) for detailed examples. +See [Release workflow recipes](../recipes/release-workflow/README.md#release-workflow) for detailed examples. The release workflow is configured via the [branches option](./configuration.md#branches) which accepts a single or an array of branch definitions. Each branch can be defined either as a string, a [glob](https://github.com/micromatch/micromatch#matching-features) or an object. For string and glob definitions each [property](#branches-properties) will be defaulted. @@ -97,7 +97,7 @@ For example the configuration `['master', {name: 'pre/rc', prerelease: '${name.r branches: [ { name: 'master' }, { name: 'pre/rc', channel: 'pre/rc', prerelease: 'rc' }, // `prerelease` is built with the template `${name.replace(/^pre\\//g, "")}` - { name: 'beta', channel: 'beta', prerelease: 'beta' }, // `prerelease` is set to `beta` as it is the value of `name` + { name: 'beta', channel: 'beta', prerelease: true }, // `prerelease` is set to `beta` as it is the value of `name` ]; } ``` @@ -114,7 +114,7 @@ A project must define a minimum of 1 release branch and can have a maximum of 3. **Note:** With **semantic-release** as with most package managers, a release version must be unique, independently of the distribution channel on which it is available. -See [publishing on distribution channels recipe](../recipes/distribution-channels.md) for a detailed example. +See [publishing on distribution channels recipe](../recipes/release-workflow/distribution-channels.md) for a detailed example. #### Pushing to a release branch @@ -150,7 +150,7 @@ Maintenance branches are always considered lower than [release branches](#releas **semantic-release** will automatically add releases to the corresponding distribution channel when code is [merged from a release or maintenance branch to another maintenance branch](#merging-into-a-maintenance-branch), however only versions within the branch `range` can be merged. If a merged version is outside the maintenance branch `range`, **semantic-release** will not add to the corresponding channel and will throw an `EINVALIDMAINTENANCEMERGE` error. -See [publishing maintenance releases recipe](../recipes/maintenance-releases.md) for a detailed example. +See [publishing maintenance releases recipe](../recipes/release-workflow/maintenance-releases.md) for a detailed example. #### Pushing to a maintenance branch @@ -181,7 +181,7 @@ A pre-release branch is characterized by the `prerelease` property that defines When merging commits associated with an existing release, **semantic-release** will treat them as [pushed commits](#pushing-to-a-pre-release-branch) and publish a new release if necessary, but it will never add those releases to the distribution channel corresponding to the pre-release branch. -See [publishing pre-releases recipe](../recipes/pre-releases.md) for a detailed example. +See [publishing pre-releases recipe](../recipes/release-workflow/pre-releases.md) for a detailed example. #### Pushing to a pre-release branch diff --git a/package-lock.json b/package-lock.json index 1ce0ed7cb6..ec28dcf731 100644 --- a/package-lock.json +++ b/package-lock.json @@ -510,17 +510,37 @@ } }, "@semantic-release/commit-analyzer": { - "version": "9.0.0", - "resolved": "https://registry.npmjs.org/@semantic-release/commit-analyzer/-/commit-analyzer-9.0.0.tgz", - "integrity": "sha512-wFeX+KbOazDHwAHW5y9wgAvOX/+8DPRyHTxkI/6q3DGU/ep4zy7hTNhE0Yf6msCDCQ3wras/veBYSei6EFOvSg==", + "version": "9.0.2", + "resolved": "https://registry.npmjs.org/@semantic-release/commit-analyzer/-/commit-analyzer-9.0.2.tgz", + "integrity": "sha512-E+dr6L+xIHZkX4zNMe6Rnwg4YQrWNXK+rNsvwOPpdFppvZO1olE2fIgWhv89TkQErygevbjsZFSIxp+u6w2e5g==", "requires": { "conventional-changelog-angular": "^5.0.0", "conventional-commits-filter": "^2.0.0", - "conventional-commits-parser": "^3.0.7", + "conventional-commits-parser": "^3.2.3", "debug": "^4.0.0", - "import-from": "^3.0.0", + "import-from": "^4.0.0", "lodash": "^4.17.4", "micromatch": "^4.0.2" + }, + "dependencies": { + "conventional-commits-parser": { + "version": "3.2.4", + "resolved": "https://registry.npmjs.org/conventional-commits-parser/-/conventional-commits-parser-3.2.4.tgz", + "integrity": "sha512-nK7sAtfi+QXbxHCYfhpZsfRtaitZLIA6889kFIouLvz6repszQDgxBu7wf2WbU+Dco7sAnNCJYERCwt54WPC2Q==", + "requires": { + "JSONStream": "^1.0.4", + "is-text-path": "^1.0.1", + "lodash": "^4.17.15", + "meow": "^8.0.0", + "split2": "^3.0.0", + "through2": "^4.0.0" + } + }, + "import-from": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/import-from/-/import-from-4.0.0.tgz", + "integrity": "sha512-P9J71vT5nLlDeV8FHs5nNxaLbrpfAV5cF5srvbZfpwpcJoM/xZR3hiv+q+SAnuSmuGbXMWud063iIMx/V/EWZQ==" + } } }, "@semantic-release/error": { @@ -5951,7 +5971,7 @@ }, "dependencies": { "ansi-regex": { - "version": "5.0.1", + "version": "5.0.0", "bundled": true }, "is-fullwidth-code-point": { diff --git a/package.json b/package.json index 9a370c1ec2..6a23545368 100644 --- a/package.json +++ b/package.json @@ -22,7 +22,7 @@ "Justin Dietz (https://twitter.com/@skigeek)" ], "dependencies": { - "@semantic-release/commit-analyzer": "^9.0.0", + "@semantic-release/commit-analyzer": "^9.0.2", "@semantic-release/error": "^3.0.0", "@semantic-release/github": "^8.0.0", "@semantic-release/npm": "^8.0.0",