Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
  Matt TraviandGitHub
|
8f075227eb | ||
 Alexander MendesandGitHub
|
2f4bcef33a | ||
 
|
f419080fbf | ||
 Matt TraviandGitHub
|
3bbf08c9d0 | ||
|
846f4c23b9 | ||
 Florian KostenzerandGitHub
|
bd294eb63e | ||
 iczellionandGitHub
|
c69445ebea | ||
|
|
d80e2eab27 | ||
 HonkingGooseandGitHub
|
9589a96239 | ||
|
HonkingGooseandGitHub
|
ec89babb95 | ||
|
HonkingGooseandGitHub
|
db620aa799 | ||
|
HonkingGooseandGitHub
|
dd77f1f603 | ||
|
HonkingGooseandGitHub
|
e66b4b59c0 | ||
|
HonkingGooseandGitHub
|
3387fb756d | ||
 Cesar SandGitHub
|
587bb91c9a | ||
|
|
05c9360475 | ||
|
|
f1d7ad4e35 | ||
 Matt TraviandGitHub
|
58a226f29c | ||
|
|
17d60d310e | ||
|
Matt TraviandGitHub
|
ab45ab1f8d | ||
|
ea389c3c88 | ||
|
|
fa994db054 | ||
|
|
b79116bf6d | ||
|
|
6fd7e56eb8 | ||
 Bolaji AyodejiandGitHub
|
2b94bb4e09 | ||
 hong-jen kaoandGitHub
|
b4bc1918cb | ||
|
Matt TraviandGitHub
|
2c30e268f9 | ||
|
Matt Travi
|
0eca144bad |
@@ -1,21 +0,0 @@
|
||||
---
|
||||
name: Bug report
|
||||
about: Something not working as expected
|
||||
|
||||
---
|
||||
|
||||
## Current behavior
|
||||
|
||||
<!-- Describe how the issue manifests. -->
|
||||
|
||||
## Expected behavior
|
||||
|
||||
<!-- Describe what the desired behavior would be. -->
|
||||
|
||||
## Environment
|
||||
|
||||
- **semantic-release** version: <!-- Version set in package.json devDpendencies -->
|
||||
- CI environment: <!-- CI service name -->
|
||||
- Plugins used: <!-- List semantic-release plugin used if any -->
|
||||
- **semantic-release** configuration: <!-- link to your repository or relevant part of the semantic-release config -->
|
||||
- CI logs: <!-- link to your CI logs or semantic-release logs -->
|
||||
@@ -0,0 +1,51 @@
|
||||
name: Bug Report
|
||||
description: Something not working as expected
|
||||
body:
|
||||
- type: textarea
|
||||
attributes:
|
||||
label: Current behavior
|
||||
description: Describe how the issue manifests.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
attributes:
|
||||
label: Expected behavior
|
||||
description: Describe what the desired behavior would be.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: input
|
||||
attributes:
|
||||
label: "`semantic-release` version"
|
||||
description: Version set in `package.json` `devDpendencies`.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: input
|
||||
attributes:
|
||||
label: CI environment
|
||||
description: CI service name.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
attributes:
|
||||
label: Plugins used
|
||||
description: List `semantic-release` plugin used, if any.
|
||||
validations:
|
||||
required: false
|
||||
|
||||
- type: textarea
|
||||
attributes:
|
||||
label: "`semantic-release` configuration"
|
||||
description: Link to your repository or relevant part of the `semantic-release` config.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
attributes:
|
||||
label: CI logs
|
||||
description: Link to your CI logs or `semantic-release` logs.
|
||||
validations:
|
||||
required: true
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
name: Feature request
|
||||
about: Wouldn’t it be nice if semantic-release could ...
|
||||
|
||||
---
|
||||
|
||||
## New feature motivation
|
||||
|
||||
<!-- Describe the context, the use-case and the advantages of the feature request. -->
|
||||
|
||||
## New feature description
|
||||
|
||||
<!-- Describe the functional changes that would have to be made in semantic-release or its plugins. -->
|
||||
|
||||
## New feature implementation
|
||||
|
||||
<!-- Optionally describe the technical changes to be made in semantic-release or its plugins. -->
|
||||
@@ -0,0 +1,23 @@
|
||||
name: Feature request
|
||||
description: Wouldn't it be nice if `semantic-release` could ...
|
||||
body:
|
||||
- type: textarea
|
||||
attributes:
|
||||
label: New feature motivation
|
||||
description: Describe the context, the use-case and the advantages of the feature request.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
attributes:
|
||||
label: New feature description
|
||||
description: Describe the functional changes that would have to be made in `semantic-release` or its plugins.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
attributes:
|
||||
label: New feature implementation
|
||||
description: Optionally describe the technical changes to be made in `semantic-release` or its plugins.
|
||||
validations:
|
||||
required: false
|
||||
@@ -1,13 +0,0 @@
|
||||
---
|
||||
name: New plugin suggestion
|
||||
about: Integrate with a new platform, etc
|
||||
|
||||
---
|
||||
|
||||
## New plugin motivation
|
||||
|
||||
<!-- Describe the reasons to create a new plugin and why it's not covered by the existing ones. -->
|
||||
|
||||
## Third-party documentation
|
||||
|
||||
<!-- Provide explanation and documentation links for the platform to integrate with. -->
|
||||
@@ -0,0 +1,16 @@
|
||||
name: New plugin suggestion
|
||||
description: Integrate with a new platform, etc
|
||||
body:
|
||||
- type: textarea
|
||||
attributes:
|
||||
label: New plugin motivation
|
||||
description: Describe the reasons to create a new plugin and why it's not covered by the existing ones.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
attributes:
|
||||
label: Third-party documentation
|
||||
description: Provide explanation and documentation links for the platform to integrate with.
|
||||
validations:
|
||||
required: true
|
||||
@@ -12,9 +12,9 @@ To create a plugin for `semantic-release`, you need to decide which parts of the
|
||||
- `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 `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)
|
||||
2. `context` - provided by `semantic-release` for access to things like `env` variables set on the running process.
|
||||
|
||||
@@ -55,12 +55,12 @@
|
||||
- [@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 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)
|
||||
- `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
|
||||
- [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
|
||||
- `publish`: Publish the package to the Visual Studio Code marketplace
|
||||
- [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`
|
||||
- `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)
|
||||
- `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)
|
||||
- `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`
|
||||
@@ -157,3 +157,12 @@
|
||||
- `verifyConditions`: Verify plugin configuration and login to Helm registry
|
||||
- `prepare`: Package Helm chart to local folder
|
||||
- `publish`: Publish Helm chart to OCI registry
|
||||
- [semantic-release-space](https://github.com/123FLO321/semantic-release-space)
|
||||
- `verifyConditions` Verifies that all required options are set.
|
||||
- `prepare` Creates a JetBrains Space Deployment Target if it does not yet exist.
|
||||
- `publish` Starts a JetBrains Space Deployment.
|
||||
- `success` Marks the JetBrains Space Deployment as completed.
|
||||
- `fail` Marks the JetBrains Space Deployment as failed.
|
||||
- [semantic-release-react-native](https://github.com/alexandermendes/semantic-release-react-native)
|
||||
- `verifyConditions` Validate configuration.
|
||||
- `prepare` Version native iOS and Android files.
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## Community configurations
|
||||
- [@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).
|
||||
- Publishes the same tarball to [npm](https://github.com/semantic-release/npm).
|
||||
- Commits the version change in `package.json`.
|
||||
@@ -18,4 +18,3 @@
|
||||
- Updates GitHub release with release-notes.
|
||||
- Bumps a version in package.json.
|
||||
- Publishes the new version to [NPM](https://npmjs.org).
|
||||
|
||||
|
||||
@@ -22,14 +22,12 @@ Finally, we call our release job with a `requires` parameter so that `release` w
|
||||
```yaml
|
||||
version: 2.1
|
||||
orbs:
|
||||
node: circleci/node@4.5
|
||||
node: circleci/node@5.0.0
|
||||
jobs:
|
||||
release:
|
||||
executor: node/default
|
||||
steps:
|
||||
- checkout
|
||||
- node/install
|
||||
lts: true
|
||||
- node/install-packages # Install and automatically cache packages
|
||||
# Run optional required steps before releasing
|
||||
# - run: npm run build-script
|
||||
|
||||
@@ -14,7 +14,7 @@ GitLab CI supports [Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html) all
|
||||
|
||||
### `.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.
|
||||
|
||||
@@ -48,7 +48,7 @@ publish:
|
||||
|
||||
### `.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.
|
||||
|
||||
@@ -66,8 +66,8 @@ release:
|
||||
- npm install -g semantic-release @semantic-release/gitlab
|
||||
script:
|
||||
- semantic-release
|
||||
only:
|
||||
- master
|
||||
rules:
|
||||
- if: $CI_COMMIT_BRANCH == "master"
|
||||
|
||||
release:
|
||||
image: node:12-buster-slim
|
||||
@@ -77,8 +77,8 @@ release:
|
||||
- npm install -g semantic-release @semantic-release/gitlab
|
||||
script:
|
||||
- semantic-release
|
||||
only:
|
||||
- master
|
||||
rules:
|
||||
- if: $CI_COMMIT_BRANCH == "master"
|
||||
```
|
||||
|
||||
### `package.json` configuration
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Publishing on distribution channels
|
||||
|
||||
This recipe will walk you through a simple example that uses distribution channels to make releases available only to a subset of users, in order to collect feedbacks before distributing the release to all users.
|
||||
This recipe will walk you through a simple example that uses distribution channels to make releases available only to a subset of users, in order to collect feedback before distributing the release to all users.
|
||||
|
||||
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}]`
|
||||
|
||||
+2
-2
@@ -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:
|
||||
- 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
|
||||
|
||||
See the [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details on specific CI environments.
|
||||
@@ -153,7 +153,7 @@ Any npm compatible registry is supported with the [`@semantic-release/npm`](http
|
||||
|
||||
See [npm registry authentication](https://github.com/semantic-release/npm#npm-registry-authentication) for more details.
|
||||
|
||||
See [Artifactory - npm Registry](https://www.jfrog.com/confluence/display/RTF/Npm+Registry#NpmRegistry-AuthenticatingthenpmClient) documentation for Artifactiry configuration.
|
||||
See [Artifactory - npm Registry](https://www.jfrog.com/confluence/display/RTF/Npm+Registry#NpmRegistry-AuthenticatingthenpmClient) documentation for Artifactory configuration.
|
||||
|
||||
## Can I manually trigger the release of a specific version?
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Node version requirement
|
||||
|
||||
**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which requires **requires Node version 14.17 or higher**.
|
||||
**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which **requires Node version 14.17 or higher**.
|
||||
|
||||
**semantic-release** is meant to be used in a CI environment as a development support tool, not as a production dependency.
|
||||
Therefore, the only constraint is to run the `semantic-release` in a CI environment providing version of Node that meets our version requirement.
|
||||
|
||||
@@ -13,7 +13,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/ci-configurations/README.md) for more details.
|
||||
See [CI configuration recipes](../recipes/ci-configurations#ci-configurations) for more details.
|
||||
|
||||
## Authentication
|
||||
|
||||
@@ -26,7 +26,7 @@ See [CI configuration recipes](../recipes/ci-configurations/README.md) for more
|
||||
| `GH_TOKEN` or `GITHUB_TOKEN` | A GitHub [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line). |
|
||||
| `GL_TOKEN` or `GITLAB_TOKEN` | A GitLab [personal access token](https://docs.gitlab.com/ce/user/profile/personal_access_tokens.html). |
|
||||
| `BB_TOKEN` or `BITBUCKET_TOKEN` | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html). |
|
||||
| `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. |
|
||||
| `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 clarification `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 `<username>:<password>`. 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-hosted-services/git-auth-ssh-keys.md).
|
||||
@@ -44,6 +44,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/ci-configurations/README.md) for more details on how to configure environment variables in your CI service.
|
||||
See [CI configuration recipes](../recipes/ci-configurations#ci-configurations) 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).
|
||||
|
||||
@@ -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 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
|
||||
- prereleases 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 `beta` distribution channel from the branch `beta` 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.
|
||||
|
||||
@@ -116,7 +116,7 @@ Type: `Boolean`<br>
|
||||
Default: `false` if running in a CI environment, `true` otherwise<br>
|
||||
CLI arguments: `-d`, `--dry-run`
|
||||
|
||||
The objective of the dry-run mode is to get a preview of the pending release. Dry-run mode skips the following steps: prepare, publish, success and fail. In addition to this it prints the next version and release notes to the console.
|
||||
The objective of the dry-run mode is to get a preview of the pending release. Dry-run mode skips the following steps: prepare, publish, addChannel, success and fail. In addition to this it prints the next version and release notes to the console.
|
||||
|
||||
**Note**: The Dry-run mode verifies the repository push permission, even though nothing will be pushed. The verification is done to help user to figure out potential configuration issues.
|
||||
|
||||
|
||||
@@ -75,7 +75,7 @@ async function run(context, plugins) {
|
||||
}
|
||||
|
||||
logger[options.dryRun ? 'warn' : 'success'](
|
||||
`Run automated release from branch ${ciBranch} on repository ${options.repositoryUrl}${
|
||||
`Run automated release from branch ${ciBranch} on repository ${options.originalRepositoryURL}${
|
||||
options.dryRun ? ' in dry-run mode' : ''
|
||||
}`
|
||||
);
|
||||
@@ -263,6 +263,7 @@ module.exports = async (cliOptions = {}, {cwd = process.cwd(), env = process.env
|
||||
context.logger.log(`Running ${pkg.name} version ${pkg.version}`);
|
||||
try {
|
||||
const {plugins, options} = await getConfig(context, cliOptions);
|
||||
options.originalRepositoryURL = options.repositoryUrl;
|
||||
context.options = options;
|
||||
try {
|
||||
const result = await run(context, plugins);
|
||||
|
||||
@@ -27,6 +27,7 @@ module.exports = async (repositoryUrl, ciBranch, context) => {
|
||||
|
||||
const errors = [];
|
||||
const branchesByType = Object.entries(DEFINITIONS).reduce(
|
||||
// eslint-disable-next-line unicorn/no-fn-reference-in-iterator
|
||||
(branchesByType, [type, {filter}]) => ({[type]: branches.filter(filter), ...branchesByType}),
|
||||
{}
|
||||
);
|
||||
|
||||
@@ -16,6 +16,7 @@ const prerelease = {
|
||||
};
|
||||
|
||||
const release = {
|
||||
// eslint-disable-next-line unicorn/no-fn-reference-in-iterator
|
||||
filter: (branch) => !maintenance.filter(branch) && !prerelease.filter(branch),
|
||||
branchesValidator: (branches) => branches.length <= 3 && branches.length > 0,
|
||||
};
|
||||
|
||||
@@ -89,7 +89,7 @@ module.exports = async (context) => {
|
||||
try {
|
||||
debug('Verifying ssh auth by attempting to push to %s', repositoryUrl);
|
||||
await verifyAuth(repositoryUrl, branch.name, {cwd, env});
|
||||
} catch (_) {
|
||||
} catch {
|
||||
debug('SSH key auth failed, falling back to https.');
|
||||
const envVars = Object.keys(GIT_TOKENS).filter((envVar) => !isNil(env[envVar]));
|
||||
|
||||
|
||||
+2
-2
@@ -116,7 +116,7 @@ async function fetch(repositoryUrl, branch, ciBranch, execaOptions) {
|
||||
],
|
||||
execaOptions
|
||||
);
|
||||
} catch (_) {
|
||||
} catch {
|
||||
await execa(
|
||||
'git',
|
||||
[
|
||||
@@ -144,7 +144,7 @@ async function fetchNotes(repositoryUrl, execaOptions) {
|
||||
['fetch', '--unshallow', repositoryUrl, `+refs/notes/${GIT_NOTE_REF}:refs/notes/${GIT_NOTE_REF}`],
|
||||
execaOptions
|
||||
);
|
||||
} catch (_) {
|
||||
} catch {
|
||||
await execa('git', ['fetch', repositoryUrl, `+refs/notes/${GIT_NOTE_REF}:refs/notes/${GIT_NOTE_REF}`], {
|
||||
...execaOptions,
|
||||
reject: false,
|
||||
|
||||
Generated
+4572
-2664
File diff suppressed because it is too large
Load Diff
+4
-3
@@ -23,7 +23,7 @@
|
||||
"@semantic-release/commit-analyzer": "^9.0.2",
|
||||
"@semantic-release/error": "^3.0.0",
|
||||
"@semantic-release/github": "^8.0.0",
|
||||
"@semantic-release/npm": "^9.0.0-beta.3",
|
||||
"@semantic-release/npm": "^9.0.0",
|
||||
"@semantic-release/release-notes-generator": "^10.0.0",
|
||||
"aggregate-error": "^3.0.0",
|
||||
"cosmiconfig": "^7.0.0",
|
||||
@@ -57,7 +57,7 @@
|
||||
"dockerode": "3.3.1",
|
||||
"file-url": "3.0.0",
|
||||
"fs-extra": "9.1.0",
|
||||
"got": "11.8.3",
|
||||
"got": "11.8.5",
|
||||
"js-yaml": "4.1.0",
|
||||
"mockserver-client": "5.11.2",
|
||||
"nock": "13.2.1",
|
||||
@@ -67,7 +67,7 @@
|
||||
"sinon": "12.0.1",
|
||||
"stream-buffers": "3.0.2",
|
||||
"tempy": "1.0.1",
|
||||
"xo": "0.29.1"
|
||||
"xo": "0.32.1"
|
||||
},
|
||||
"engines": {
|
||||
"node": ">=16 || ^14.17"
|
||||
@@ -129,6 +129,7 @@
|
||||
"prettier": true,
|
||||
"space": true,
|
||||
"rules": {
|
||||
"unicorn/no-reduce": "off",
|
||||
"unicorn/string-content": "off"
|
||||
}
|
||||
},
|
||||
|
||||
@@ -2,6 +2,7 @@ const test = require('ava');
|
||||
const {maintenance, prerelease, release} = require('../../lib/definitions/branches');
|
||||
|
||||
test('A "maintenance" branch is identified by having a "range" property or a "name" formatted like "N.x", "N.x.x" or "N.N.x"', (t) => {
|
||||
/* eslint-disable unicorn/no-fn-reference-in-iterator */
|
||||
t.true(maintenance.filter({name: '1.x.x'}));
|
||||
t.true(maintenance.filter({name: '1.0.x'}));
|
||||
t.true(maintenance.filter({name: '1.x'}));
|
||||
@@ -15,6 +16,7 @@ test('A "maintenance" branch is identified by having a "range" property or a "na
|
||||
t.false(maintenance.filter({name: 'some-name'}));
|
||||
t.false(maintenance.filter({name: '1.0.0'}));
|
||||
t.false(maintenance.filter({name: 'x.x.x'}));
|
||||
/* eslint-enable unicorn/no-fn-reference-in-iterator */
|
||||
});
|
||||
|
||||
test('A "maintenance" branches must have a "range" property formatted like "N.x", "N.x.x" or "N.N.x"', (t) => {
|
||||
@@ -37,6 +39,7 @@ test('The "maintenance" branches must have unique ranges', (t) => {
|
||||
});
|
||||
|
||||
test('A "prerelease" branch is identified by having a thruthy "prerelease" property', (t) => {
|
||||
/* eslint-disable unicorn/no-fn-reference-in-iterator */
|
||||
t.true(prerelease.filter({name: 'some-name', prerelease: true}));
|
||||
t.true(prerelease.filter({name: 'some-name', prerelease: 'beta'}));
|
||||
t.true(prerelease.filter({name: 'some-name', prerelease: ''}));
|
||||
@@ -44,6 +47,7 @@ test('A "prerelease" branch is identified by having a thruthy "prerelease" prope
|
||||
t.false(prerelease.filter({name: 'some-name', prerelease: null}));
|
||||
t.false(prerelease.filter({name: 'some-name', prerelease: false}));
|
||||
t.false(prerelease.filter({name: 'some-name'}));
|
||||
/* eslint-enable unicorn/no-fn-reference-in-iterator */
|
||||
});
|
||||
|
||||
test('A "prerelease" branch must have a valid prerelease detonation in "prerelease" property or in "name" if "prerelease" is "true"', (t) => {
|
||||
@@ -66,6 +70,7 @@ test('The "prerelease" branches must have unique "prerelease" property', (t) =>
|
||||
});
|
||||
|
||||
test('A "release" branch is identified by not havin a "range" or "prerelease" property or a "name" formatted like "N.x", "N.x.x" or "N.N.x"', (t) => {
|
||||
/* eslint-disable unicorn/no-fn-reference-in-iterator */
|
||||
t.true(release.filter({name: 'some-name'}));
|
||||
|
||||
t.false(release.filter({name: '1.x.x'}));
|
||||
@@ -74,6 +79,7 @@ test('A "release" branch is identified by not havin a "range" or "prerelease" pr
|
||||
t.false(release.filter({name: 'some-name', range: '1.1.x'}));
|
||||
t.false(release.filter({name: 'some-name', prerelease: true}));
|
||||
t.false(release.filter({name: 'some-name', prerelease: 'beta'}));
|
||||
/* eslint-enable unicorn/no-fn-reference-in-iterator */
|
||||
});
|
||||
|
||||
test('There must be between 1 and 3 release branches', (t) => {
|
||||
|
||||
@@ -3,7 +3,7 @@ const getStream = require('get-stream');
|
||||
const pRetry = require('p-retry');
|
||||
const {initBareRepo, gitShallowClone} = require('./git-utils');
|
||||
|
||||
const IMAGE = 'pvdlg/docker-gitbox:latest';
|
||||
const IMAGE = 'semanticrelease/docker-gitbox:latest';
|
||||
const SERVER_PORT = 80;
|
||||
const HOST_PORT = 2080;
|
||||
const SERVER_HOST = 'localhost';
|
||||
|
||||
@@ -30,13 +30,13 @@ async function start() {
|
||||
minTimeout: 1000,
|
||||
factor: 2,
|
||||
});
|
||||
} catch (_) {
|
||||
} catch {
|
||||
throw new Error(`Couldn't start mock-server after 2 min`);
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Stop and remote the `mockserver` Docker container.
|
||||
* Stop and remove the `mockserver` Docker container.
|
||||
*/
|
||||
async function stop() {
|
||||
await container.stop();
|
||||
@@ -91,7 +91,7 @@ async function mock(
|
||||
}
|
||||
|
||||
/**
|
||||
* Verify the `mockserver` has been called with a requestion matching expectations. The `expectation` is created with the `mock` function.
|
||||
* Verify the `mockserver` has been called with a request matching expectations. The `expectation` is created with the `mock` function.
|
||||
*
|
||||
* @param {Object} expectation The expectation created with `mock` function.
|
||||
* @return {Promise} A Promise that resolves if the expectation is met or reject otherwise.
|
||||
|
||||
@@ -37,7 +37,7 @@ async function start() {
|
||||
minTimeout: 1000,
|
||||
factor: 2,
|
||||
});
|
||||
} catch (_) {
|
||||
} catch {
|
||||
throw new Error(`Couldn't start npm-registry-docker after 2 min`);
|
||||
}
|
||||
|
||||
|
||||
+7
-1
@@ -90,6 +90,7 @@ test('Plugins are called with expected values', async (t) => {
|
||||
const config = {
|
||||
branches: [{name: 'master'}, {name: 'next'}],
|
||||
repositoryUrl,
|
||||
originalRepositoryURL: repositoryUrl,
|
||||
globalOpt: 'global',
|
||||
tagFormat: `v\${version}`,
|
||||
};
|
||||
@@ -927,7 +928,12 @@ test('Log all "verifyConditions" errors', async (t) => {
|
||||
const error2 = new SemanticReleaseError('error 2', 'ERR2');
|
||||
const error3 = new SemanticReleaseError('error 3', 'ERR3');
|
||||
const fail = stub().resolves();
|
||||
const config = {branches: [{name: 'master'}], repositoryUrl, tagFormat: `v\${version}`};
|
||||
const config = {
|
||||
branches: [{name: 'master'}],
|
||||
repositoryUrl,
|
||||
originalRepositoryURL: repositoryUrl,
|
||||
tagFormat: `v\${version}`,
|
||||
};
|
||||
const options = {
|
||||
...config,
|
||||
plugins: false,
|
||||
|
||||
Reference in New Issue
Block a user