simon/semantic-release
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: fix typos (#2476)

Browse Source
This commit is contained in:
HonkingGoose 2022-06-16 21:57:37 +02:00 committed by GitHub
parent ec89babb95
commit 9589a96239
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 11 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/developer-guide/plugin.md
View File

@ -12,9 +12,9 @@ To create a plugin for `semantic-release`, you need to decide which parts of the
- `success` - `success`
- `fail` - `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 `verifyConditions` and `success` step, the `main` file for your object would need to `export` an object with `verifyConditions` and `success` functions. `semantic-release` will require the plugin via `node` and look through the required object for methods named like the lifecycles 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: In addition to the lifecycle methods, each lifecycle is passed two objects:
1. `pluginConfig` - an object containing the options that a user may pass in via their `release.config.js` file (or similar) 1. `pluginConfig` - an object containing the options that a user may pass in via their `release.config.js` file (or similar)
2. `context` - provided by `semantic-release` for access to things like `env` variables set on the running process. 2. `context` - provided by `semantic-release` for access to things like `env` variables set on the running process.

6
docs/extending/plugins-list.md
View File

@ -55,12 +55,12 @@
- [@semantic-release-plus/docker](https://github.com/semantic-release-plus/semantic-release-plus/tree/master/packages/plugins/docker) - [@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. - `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 and channel and push it to the configured docker registry. - `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. - `addChannel`: Updates a release published on one channel with the destinations channel tag and pushes to the registry i.e.: next to latest.
- [semantic-release-gcr](https://github.com/carlos-cubas/semantic-release-gcr) - [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 - `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 - `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag
- [semantic-release-vsce](https://github.com/raix/semantic-release-vsce) - [semantic-release-vsce](https://github.com/raix/semantic-release-vsce)
- `verifyConditions`: Verify the presence and the validity of the vsce authentication and release configuration - `verifyConditions`: Verify the presence and the validity of the "VS Code extension" authentication and release configuration
- `prepare`: Create a `.vsix` for distribution - `prepare`: Create a `.vsix` for distribution
- `publish`: Publish the package to the Visual Studio Code marketplace - `publish`: Publish the package to the Visual Studio Code marketplace
- [semantic-release-verify-deps](https://github.com/piercus/semantic-release-verify-deps) - [semantic-release-verify-deps](https://github.com/piercus/semantic-release-verify-deps)
@ -84,7 +84,7 @@
- `prepare`: Changes the version number in the `pom.xml` (or all `pom.xml` files in maven projects with multiple `pom.xml` files) and optionally creates a commit with this version number and pushes it to `master` - `prepare`: Changes the version number in the `pom.xml` (or all `pom.xml` files in maven projects with multiple `pom.xml` files) and optionally creates a commit with this version number and pushes it to `master`
- `publish`: Runs `mvn deploy` to deploy to maven central and optionally will update to next snapshot version and merge changes to development branch - `publish`: Runs `mvn deploy` to deploy to maven central and optionally will update to next snapshot version and merge changes to development branch
- [semantic-release-ado](https://github.com/lluchmk/semantic-release-ado) - [semantic-release-ado](https://github.com/lluchmk/semantic-release-ado)
- `prepare`: Stores the version number as an Azure DevOps pipeline variable availabe to downstream steps on the job - `prepare`: Stores the version number as an Azure DevOps pipeline variable available to downstream steps on the job
- [gradle-semantic-release](https://github.com/KengoTODA/gradle-semantic-release-plugin) - [gradle-semantic-release](https://github.com/KengoTODA/gradle-semantic-release-plugin)
- `verifyConditions`: Verify that project has a Gradle wrapper script, and `build.gradle` contains a task to publish artifacts. - `verifyConditions`: Verify that project has a Gradle wrapper script, and `build.gradle` contains a task to publish artifacts.
- `prepare`: Changes the version number in the `gradle.properties` - `prepare`: Changes the version number in the `gradle.properties`

3
docs/extending/shareable-configurations-list.md
View File

@ -6,7 +6,7 @@
## Community configurations ## Community configurations
- [@jedmao/semantic-release-npm-github-config](https://github.com/jedmao/semantic-release-npm-github-config) - [@jedmao/semantic-release-npm-github-config](https://github.com/jedmao/semantic-release-npm-github-config)
- Provides an informative [git](https://github.com/semantic-release/git) commit message for the release commit that does not trigger continuous integration and conforms to the [conventional commits specification](https://www.conventionalcommits.org/) (e.g., "chore(release): 1.2.3 [skip ci]\n\nnotes"). - Provides an informative [Git](https://github.com/semantic-release/git) commit message for the release commit that does not trigger continuous integration and conforms to the [conventional commits specification](https://www.conventionalcommits.org/) (e.g., `chore(release): 1.2.3 [skip ci]\n\nnotes`).
- Creates a tarball that gets uploaded with each [GitHub release](https://github.com/semantic-release/github). - Creates a tarball that gets uploaded with each [GitHub release](https://github.com/semantic-release/github).
- Publishes the same tarball to [npm](https://github.com/semantic-release/npm). - Publishes the same tarball to [npm](https://github.com/semantic-release/npm).
- Commits the version change in `package.json`. - Commits the version change in `package.json`.
@ -18,4 +18,3 @@
- Updates GitHub release with release-notes. - Updates GitHub release with release-notes.
- Bumps a version in package.json. - Bumps a version in package.json.
- Publishes the new version to [NPM](https://npmjs.org). - Publishes the new version to [NPM](https://npmjs.org).

4
docs/recipes/ci-configurations/gitlab-ci.md
View File

@ -14,7 +14,7 @@ GitLab CI supports [Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html) all
### `.gitlab-ci.yml` configuration for Node projects ### `.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. 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.
@ -48,7 +48,7 @@ publish:
### `.gitlab-ci.yml` configuration for all projects ### `.gitlab-ci.yml` configuration for all 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. 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.

2
docs/support/FAQ.md
View File

@ -44,7 +44,7 @@ Yes, **semantic-release** is a Node CLI application, but it can be used to publi
To publish a non-Node package (without a `package.json`) you would need to: To publish a non-Node package (without a `package.json`) you would need to:
- Use a [global](../usage/installation.md#global-installation) **semantic-release** installation - Use a [global](../usage/installation.md#global-installation) **semantic-release** installation
- Set **semantic-release** [options](../usage/configuration.md#options) via [CLI arguments or rc file](../usage/configuration.md#configuration) - 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 - 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/release-workflow/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.

4
docs/usage/configuration.md
View File

@ -69,8 +69,8 @@ The branches on which releases should happen. By default **semantic-release** wi
- regular releases to a distribution channel matching the branch name from any existing branch with a name matching a maintenance release range (`N.N.x` or `N.x.x` or `N.x` with `N` being a number) - regular releases to a distribution channel matching the branch name from any existing branch with a name matching a maintenance release range (`N.N.x` or `N.x.x` or `N.x` with `N` being a number)
- regular releases to the `next` distribution channel from the branch `next` if it exists - regular releases to the `next` distribution channel from the branch `next` if it exists
- regular releases to the `next-major` distribution channel from the branch `next-major` if it exists - regular releases to the `next-major` distribution channel from the branch `next-major` if it exists
- prereleases to the `beta` distribution channel from the branch `beta` if it exists - pre-releases to the `beta` distribution channel from the branch `beta` if it exists
- prereleases to the `alpha` distribution channel from the branch `alpha` if it exists - pre-releases to the `alpha` distribution channel from the branch `alpha` if it exists
**Note**: If your repository does not have a release branch, then **semantic-release** will fail with an `ERELEASEBRANCHES` error message. If you are using the default configuration, you can fix this error by pushing a `master` branch. **Note**: If your repository does not have a release branch, then **semantic-release** will fail with an `ERELEASEBRANCHES` error message. If you are using the default configuration, you can fix this error by pushing a `master` branch.