This PR refactors the `verifyAuth` function replacing the normal push
dry-run (which could result in a branch outdated error/notice) with a
tags dry-run push. It does this by separating the push permission check
operation in the `verifyAuth` logic from the `isBranchUpdated` logic
that lived in thesame execution block via a `try-catch` into standalone
operations; this branch status check only occured when the push
permission check fails.
### Changes Made
- Modify `verifyAuth` logic to do a tags dry run instead of a branch
dry-run push
- Separate `verifyAuth` to a standalone block to throw a
`"EGITNOPERMISSION"` if no push permission is found
- Improved the `isBranchUpdated` helper to ensure it checks for cases
where local branch is either behind, ahead or diverged of head remote
branch and return appropriate boolean response which in this case is...
- `false` - when local branch is behind remote branch
- `true` - when local branch is ahead of remote branch
- `false` - when local branch and remote branch have commits that the
other doesn't
- Make the branch up to date check a standalone process in the release
verification process returning `false` when branch is considered not
up-to-date - with a message
```js
if (!(await isBranchUpToDate(options.repositoryUrl, context.branch.name,
{ cwd, env }))) {
logger.log(
`The local branch ${context.branch.name} is behind the remote one,
therefore a new version won't be published.`
);
return false;
}
```
### Related Issue
Fixes#3437
BREAKING CHANGE: `semantic-release` now checks if your local branch is
up-to-date with your remote repo branch after of push permission
verification.
* fix: ensure percent-encoded secrets get masked
Co-authored-by: Gregor Martynus <39992+gr2m@users.noreply.github.com>
* fix: mask secrets in the exact form url.format() embeds them in git URLs
The authenticated repository URL is built with the legacy url.format(),
which encodes the auth field like encodeURIComponent() except that ":"
separators are kept as is. A GIT_CREDENTIALS value such as
"user:abc@def-secret" therefore appears as "user:abc%40def-secret" in a
failing git command, a form matched by neither the raw value, encodeURI(),
nor encodeURIComponent() candidates, and leaked unmasked.
Add the colon-preserving encoded form to the redaction candidates, assert
the unit tests against URLs built the same way get-git-auth-url.js builds
them, and add an integration test reproducing the leak end-to-end with a
git remote on a closed loopback port.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Matt Travi <programmer@travi.org>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* ci: win32 escape slash as doubleslash for test
Pathing in stderr output has double backslash in the filename. The test
will now use double backslash in the existence test.
Signed-off-by: Chris. Webster <chris@webstech.net>
* ci: avoid Windows pop-up in credential tests
Windows uses a `credential.helper` that will open a pop-up for
credentials if they are missing. A git config parameter will now be set
to avoid the pop-up.
Signed-off-by: Chris. Webster <chris@webstech.net>
---------
Signed-off-by: Chris. Webster <chris@webstech.net>
for #2543
BREAKING CHANGE: semantic-release is now ESM-only. since it is used through its own executable, the impact on consuming projects should be minimal
BREAKING CHANGE: references to plugin files in configs need to include the file extension because of executing in an ESM context
BREAKING CHANGE: this feature change the way semantic-release keep track of the channels on which a version has been released.
It now use a JSON object stored in a [Git note](https://git-scm.com/docs/git-notes) instead of Git tags formatted as v{version}@{channel}.
The tags formatted as v{version}@{channel} will now be ignored. If you have made releases with v16.0.0 on branches other than the default one you will have to update your repository.
The changes to make consist in:
- Finding all the versions that have been released on a branch other than the default one by searching for all tags formatted v{version}@{channel}
- For each of those version:
- Create a tag without the {@channel} if none doesn't already exists
- Add a Git note to the tag without the {@channel} containing the channels on which the version was released formatted as `{"channels":["channel1","channel2"]}` and using `null` for the default channel (for example.`{"channels":[null,"channel1","channel2"]}`)
- Push the tags and notes
- Update the GitHub releases that refer to a tag formatted as v{version}@{channel} to use the tag without it
- Delete the tags formatted as v{version}@{channel}
- Add only the most recent release to a channel (rather than adding all the one not added yet)
- Avoid attempting to ad the version twice in case that version is already present in multiple upper branches
- Allow to configure multiple branches to release from
- Allow to define a distribution channel associated with each branch
- Manage the availability on distribution channels based on git merges
- Support regular releases, maintenance releases and pre-releases
- Add the `addChannel` plugin step to make an existing release available on a different distribution channel
BREAKING CHANGE: the `branch` option has been removed in favor of `branches`
The new `branches` option expect either an Array or a single branch definition. To migrate your configuration:
- If you want to publish package from multiple branches, please the configuration documentation
- If you use the default configuration and want to publish only from `master`: nothing to change
- If you use the `branch` configuration and want to publish only from one branch: replace `branch` by `branches` (`"branch": "my-release-branch"` => `"branches": "my-release-branch"`)
- Allow to run semantic-release (via API) from anywhere passing the current working directory.
- Allows to simplify the tests and to run them in parallel in both the core and plugins.
Even the user set Git credentials via environment variable, use the configured URL (with authentication) if it works.
This allow users to push tags and commits via ssh while still using the GitHub/GitLab API.
- Replace `commander.js` with `yargs`
- Add CLI unit tests
- Add a `--version` option
- Improve `--help` output
- Remove `commander.js` related workaround
- Allow to set list option with arg repetition or space separated list
- Maintain the list options defined as comma separated list
- Allow `publish` plugins to return an `Object` with information related to the releases
- Add the `success` plugin hook, called when all `publish` are successful, receiving a list of release
- Add the `fail` plugin hook, called when an error happens at any point, receiving a list of errors
- Add detailed message for each error
- Remove the `getLastRelease` plugin type
- Retrieve the last release based on Git tags
- Create the next release Git tag before calling the `publish` plugins
BREAKING CHANGE: Remove the `getLastRelease` plugin type
The `getLastRelease` plugins will not be called anymore.
BREAKING CHANGE: Git repository authentication is now mandatory
The Git authentication is now mandatory and must be set via `GH_TOKEN`, `GITHUB_TOKEN`, `GL_TOKEN`, `GITLAB_TOKEN` or `GIT_CREDENTIALS` as described in [CI configuration](https://github.com/semantic-release/semantic-release/blob/caribou/docs/usage/ci-configuration.md#authentication).
- Remove `@semantic-release/condition-travis` from the default plugins
- Verify the current branch in the core
- Verify the build is not triggered by a PR in the core
- Run in dry-run mode if not triggered on CI
- Dry-run mode runs the `verifyConditions` plugins, allowing to detect configuration error locally
- Return without error when no version has to be released due to no changes
- Return without error if the build is triggered from a PR
- Return without error if the current branch is not the configured branch
- CLI return with exit code 1 if there is a `semanticReleaseError`, allowing to fail builds in case of config error, missing token etc...
BREAKING CHANGE: `semantic-release` doesn't make sure it runs only on one Travis job anymore.
The CI configuration has to be done such that `semantic-release`
- runs only once per build
- runs only after all tests are successful on every jobs of the build
- runs on Node >=8
This can easily be done with [travis-deploy-once](https://github.com/semantic-release/travis-deploy-once).
Migration Guide
Modify your `.travis.yml` to use `travis-deploy-once`.
Replace:
```yaml
after_success:
- npm run semantic-release
```
by:
Replace
```yaml
after_success:
- npm install -g travis-deploy-once@4
- travis-deploy-once "npm run semantic-release"
```
Adds the options `extends`, which can be defined via configuration file or CLI arguments to a single path or an array of paths of shareable configuration.
A shareable configuration is a file or a module that can be loaded with `require`.
Options is defined by merging in the following order of priority:
- CLI/API
- Configuration file
- Shareable configuration (from right to left)
Options set in a shareable configuration can be unset by setting it to `null` or `undefined` in the main configuration file. If a default value applies to this property it will be used.
Olabode Lawal-Shittabey