GithubHelp home page GithubHelp logo

qiwi / multi-semantic-release Goto Github PK

View Code? Open in Web Editor NEW
86.0 4.0 34.0 2.5 MB

Proof of concept that wraps semantic-release to work with monorepos.

License: BSD Zero Clause License

JavaScript 100.00%
semrel cicd

multi-semantic-release's Introduction

@qiwi/multi-semantic-release

hacky semantic-release for monorepos

Travis CI Maintainability Test Coverage npm (scoped)

This fork of dhoub/multi-semantic-release replaces setImmediate loops and execa.sync hooks with event-driven flow and finally makes possible to run the most release operations in parallel.
🎉 🎉 🎉

Status

We're still using this lib as a part of our release infra, but we're gradually migrating to bulk-release. This means that we do not have many resources to develop this implementation actively, but we will continue to do it on a leftover basis.

Install

yarn add @qiwi/multi-semantic-release --dev

Usage

multi-semantic-release

Configuring Multi-Semantic-Release

multi-semantic-release can be configured a number of ways:

  • A .multi-releaserc file, written in YAML or JSON, with optional extensions: .yaml/ .yml/ .json/ .js
  • A multi-release.config.js file that exports an object
  • A multi-release key in the workspace root package.json

Alternatively some options may be set via CLI flags.

Note: CLI arguments take precedence over options configured in the configuration file.

Options

Option Type CLI Flag Description
dryRun boolean --dry-run Dry run mode.
logLevel String --log-level Sets the internal logger verbosity level: error, warn, info, debug, trace. Defaults to info.
debug boolean --debug Output debugging information. Shortcut for --logLevel=debug.
silent boolean --silent Turns off any log outputs.
extends String | Array N/A List of modules or file paths containing a shareable configuration. If multiple shareable configurations are set, they will be imported in the order defined with each configuration option taking precedence over the options defined in the previous.
sequentialInit boolean --sequential-init Avoid hypothetical concurrent initialization collisions.
sequentialPrepare boolean --sequential-prepare Avoid hypothetical concurrent preparation collisions. True by default.
firstParent boolean --first-parent Apply commit filtering to current branch only.
ignorePrivate boolean --ignore-private Exclude private packages. True by default.
ignorePackages String | Array --ignore-packages Packages list to be ignored on bumping process (appended to the ones that already exist at package.json workspaces). If using the CLI flag, supply a comma seperated list of strings.
tagFormat String --tag-format Format to use when creating tag names. Should include "name" and "version" vars. Default: "${name}@${version}" which generates "[email protected]"
deps Object N/A Dependency handling, see below for possible values.

deps Options

Option Type CLI Flag Description
bump override | satisfy | inherit --deps.bump Define deps version updating rule. Allowed: override, satisfy, inherit. override by default.
release patch | minor | major | inherit --deps.release Define release type for dependent package if any of its deps changes. Supported values: patch, minor, major, inherit. patch by default
prefix '^' | '~' | '' --deps.prefix Optional prefix to be attached to the next version if bump is set to override. '' by default.
pullTagsForPrerelease boolean --deps.pullTagsForPrerelease Optional flag to use release tags for evaluating prerelease version bumping. Normally, this option will lead to dumping dependencies to a version past what was just released and tagged by semantic release. Only set this option to true if you previously had a workflow that compensated for the previous bug behavior. 'false' by default.

Examples

  • Via multi-release key in the project's package.json file:
{
	"multi-release": {
		"ignorePackages": [
			"!packages/b/**",
			"!packages/c/**"
		],
		"deps": {
			"bump": "inherit"
		}
	}
}
  • Via .multi-releaserc file:
{
	"ignorePackages": [
		"!packages/b/**",
		"!packages/c/**"
	],
	"deps": {
		"bump": "inherit"
	}
}
  • Via CLI:
$ multi-semantic-release --ignore-packages=packages/a/**,packages/b/** --deps.bump=inherit

Configuring Semantic-Release

MSR requires semrel config to be added in any supported format for each package or/and declared in repo root (globalConfig is extremely useful if all the modules have the same strategy of release).
NOTE config resolver joins globalConfig and packageConfig during execution.

// Load the package-specific options.
const { options: pkgOptions } = await getConfig(dir);

// The 'final options' are the global options merged with package-specific options.
// We merge this ourselves because package-specific options can override global options.
const finalOptions = Object.assign({}, globalOptions, pkgOptions);

Make sure to have a workspaces attribute inside your package.json project file. In there, you can set a list of packages that you might want to process in the msr process, as well as ignore others. For example, let's say your project has 4 packages (i.e. a, b, c and d) and you want to process only a and d (ignore b and c). You can set the following structure in your package.json file:

{
	"name": "msr-test-yarn",
	"author": "Dave Houlbrooke <[email protected]",
	"version": "0.0.0-semantically-released",
	"private": true,
	"license": "0BSD",
	"engines": {
		"node": ">=8.3"
	},
	"workspaces": [
      "packages/*",
      "!packages/b/**",
      "!packages/c/**"
	],
	"release": {
		"plugins": [
			"@semantic-release/commit-analyzer",
			"@semantic-release/release-notes-generator"
		],
		"noCi": true
	}
}

You can also ignore it with the CLI:

$ multi-semantic-release --ignore-packages=packages/b/**,packages/c/**

You can also combine the CLI ignore options with the ! operator at each package inside workspaces attribute. Even though you can use the CLI to ignore options, you can't use it to set which packages to be released – i.e. you still need to set the workspaces attribute inside the package.json.

Verified usage examples

We use this tool to release our JS platform code inhouse (GitHub Enterprise + JB TeamCity) and for our OSS (GitHub + Travis CI). Guaranteed working configurations available in projects.

License

0BSD

multi-semantic-release's People

Contributors

antongolub avatar chawyehsu avatar cid53 avatar clementprevot avatar csantos1113 avatar davikawasaki avatar dhoulb avatar gavmck avatar geewizwow avatar hanseltime avatar iporsut avatar killianhmyd avatar lbg-marco-massarotto avatar qiwibot avatar ukstv avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

multi-semantic-release's Issues

Duplicate release comments on old PRs

Issue type

  • bug report
  • idea
  • question
  • other

Expected behavior

Once a PR is released, I expect that MSR will leave a comment on that PR, for only the package that was released, and only the one comment for the release that PR went out in.

Actual behavior

MSR is leaving comments on PRs repeatedly for every single publish, even for packages that the PR was not scoped as. On my work repo it's doing this on a dozen PRs every release.

Example: Twipped/monorepo-sandbox#2

  • I've read the docs. This case is not mentioned
  • Similar issue does not exist

Steps to reproduce

Reproduction repo here: https://github.com/Twipped/monorepo-sandbox/
SR config is here: https://github.com/Twipped/semrel-config

Specifications

  • version: MSR 6.5.1, Node v16.14.0
  • platform: ubuntu
  • ci: Github Actions

Bug: Wrong comment of release commit if has multiple releases.

In the semantic-release the default behaviour of prepare step have the logic like this.

https://github.com/semantic-release/semantic-release/blob/4c7222d6484983abd3c066e5de41e5ba8ac21c43/lib/definitions/plugins.js#L52,L69

  prepare: {
    required: false,
    dryRun: false,
    pipelineConfig: ({generateNotes}) => ({
      getNextInput: async (context) => {
        const newGitHead = await getGitHead({cwd: context.cwd});
        // If previous prepare plugin has created a commit (gitHead changed)
        if (context.nextRelease.gitHead !== newGitHead) {
          context.nextRelease.gitHead = newGitHead;
          // Regenerate the release notes
          context.nextRelease.notes = await generateNotes(context);
        }

        // Call the next prepare plugin with the updated `nextRelease`
        return context;
      },
    }),
  },

The root cause of the bug is in this line context.nextRelease.notes = await generateNotes(context); that when we have multiple releases commit the gitHead will changed so the prepare state will try to generateNotes again with the context of prepare step.

But the inline plugin of multiple-semantic-release implements prepare function like this.

https://github.com/qiwi/multi-semantic-release/blob/5ce8eca70f2ed1360654343b00e2125c3b1b7a6f/lib/createInlinePluginCreator.js#L183,L197

		const prepare = async (pluginOptions, context) => {
			// Wait until the current pkg is ready to be tagged
			getLucky("_readyForTagging", pkg);
			await waitFor("_readyForTagging", pkg);

			updateManifestDeps(pkg);
			pkg._depsUpdated = true;

			const res = await plugins.prepare(context);
			pkg._prepared = true;

			debug(debugPrefix, "prepared");

			return res;
		};

Without

			// Set context.commits so analyzeCommits does correct analysis.
			// We need to redo this because context is a different instance each time.
			context.commits = commits;

in prepare function, So the context.commits is all changes not only the filtered commits of each workspace.

I will open the PR for fix this by set the context.commits = commits in the prepare function too.

Ignore certain packages to go through the workflow

@antongolub do we have a feature that enable the semantic release workflow to fully ignore packages we want? For instance, I have three packages:

  • lib
  • app
  • admin

What I'd want to have is have only app and admin be bumped and released, whilst the lib to maintain in the same version. If not, can you walk me through which points in the code should we tweak to enable such functionality?

Feature request: support Yarn 2 workspace prefix

Since Yarn 2, they allowed using declare workspace dependencies with workspace prefix:

{
  "dependencies": {
    "lib-a": "workspace:lib/a"
  }
}

Currently, if we defined dependencies like example above. multi-semantic-release will always rewrite it with dependencies version. It's good to see if it can detect workspace prefix and update only case workspace:^<major>.<minor>.<patch> (match semver rules).

Ref: https://yarnpkg.com/features/workspaces

6.0.X does not bump dependencies as expected

Our release broke after the second run on 6.0.X, and we tracked the cause down to dependencies not being bumped as expected.

With 6.0.X:

package A (no dependencies)
package B (depends on A)

make change in A

run release script

A gets a new release
B gets no new release, does not get a bumped dependency on A UNEXPECTED BEHAVIOUR

With 5.0.X (and earlier versions):

package A (no dependencies)
package B (depends on A)

make change in A

run release script

A gets a new release
B gets a new release (bumped dep A) EXPECTED BEHAVIOUR


The same issue applies even if we make changes to both package A and B, when on 6.0.X. B will not get a bumped dependency on A.

Is this expected behaviour? I'm not sure how to interpret the drop support for cycled monorepos line from the release notes.

Missing support for the new semantic-release esm packages

Issue type

  • bug report
  • idea
  • question
  • other

Expected behavior

@qiwi/multi-semantic-release should support the newest version of semantic-release, the newest versions swiched to be esm packages only

Actual behavior

@qiwi/multi-semantic-release cant run the newest version of semantic-release because of missing esm support

  • I've read the docs. This case is not mentioned
  • Similar issue does not exist

Steps to reproduce

Install semantic-release v21.0.2 and @qiwi/multi-semantic-release v6.7.0 and try to run the multi-semantic-release --dry command, you will get a error like

[19:53:48] › 🎉  msr: Started multirelease! Loading 9 packages...
[19:53:48] › ✖  msr: [multi-semantic-release]: Error [ERR_REQUIRE_ESM]: require() of ES Module /home/visulima/visulima/node_modules/.pnpm/@[email protected][email protected][email protected]/node_modules/@semantic-release/npm/index.js from /home/visulima/visulima/node_modules/.pnpm/@[email protected]/node_modules/@semrel-extra/npm/src/main/js/index.js not supported.
Instead change the require of /home/visulima/visulima/node_modules/.pnpm/@[email protected][email protected][email protected]/node_modules/@semantic-release/npm/index.js in /home/visulima/visulima/node_modules/.pnpm/@[email protected]/node_modules/@semrel-extra/npm/src/main/js/index.js to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/home/visulima/visulima/node_modules/.pnpm/@[email protected]/node_modules/@semrel-extra/npm/src/main/js/index.js:1:16)
    at loadPlugin (/home/visulima/visulima/node_modules/.pnpm/[email protected][email protected]/node_modules/semantic-release/lib/plugins/utils.js:51:36)
    at /home/visulima/visulima/node_modules/.pnpm/[email protected][email protected]/node_modules/semantic-release/lib/plugins/index.js:17:37
    at Array.reduce (<anonymous>)
    at module.exports (/home/visulima/visulima/node_modules/.pnpm/[email protected][email protected]/node_modules/semantic-release/lib/plugins/index.js:14:34)
    at module.exports (/home/visulima/visulima/node_modules/.pnpm/[email protected][email protected]/node_modules/semantic-release/lib/get-config.js:84:35)
    at async getConfigSemantic (file:///home/visulima/visulima/node_modules/.pnpm/@[email protected][email protected]/node_modules/@qiwi/multi-semantic-release/lib/getConfigSemantic.js:24:10)
    at async getPackage (file:///home/visulima/visulima/node_modules/.pnpm/@[email protected][email protected]/node_modules/@qiwi/multi-semantic-release/lib/multiSemanticRelease.js:173:31)
    at async Promise.all (index 0)
    at async multiSemanticRelease (file:///home/visulima/visulima/node_modules/.pnpm/@[email protected][email protected]/node_modules/@qiwi/multi-semantic-release/lib/multiSemanticRelease.js:102:19) {
  code: 'ERR_REQUIRE_ESM'
}

Specifications

  • version: 16.18
  • platform: Linux
  • ci:

Error: Cannot release because dependency config has not been released

Issue type

  • bug report
  • idea
  • question
  • other

Expected behavior

Release a package

Actual behavior

When I try to release a package I get this error:

An error occurred while running semantic-release: Error: Cannot release because dependency config has not been released

The package is part of a project on turborepo

Your case may be a known design limitation. -->

  • I've read the docs. This case is not mentioned
  • Similar issue does not exist

Failed while trying to release several packages on blank repo

travis#174292182

[3:49:55 PM] [@qiwi/nestjs-enterprise-common] › ✔  Allowed to push to the Git repository
[3:49:55 PM] [@qiwi/nestjs-enterprise-common] › ℹ  Start step "verifyConditions" of plugin "Inline plugin"
[3:49:55 PM] [@qiwi/nestjs-enterprise] › ✔  Allowed to push to the Git repository
[3:49:55 PM] [@qiwi/nestjs-enterprise] › ℹ  Start step "verifyConditions" of plugin "Inline plugin"
qiwibot
[3:49:56 PM] [@qiwi/nestjs-enterprise-common] › ✔  Completed step "verifyConditions" of plugin "Inline plugin"
[3:49:56 PM] [@qiwi/nestjs-enterprise-common] › ℹ  No git tag version found on branch master
[3:49:56 PM] [@qiwi/nestjs-enterprise-common] › ℹ  No previous release found, retrieving all commits
[3:49:56 PM] [@qiwi/nestjs-enterprise-common] › ℹ  Found 9 commits since last release
[3:49:56 PM] [@qiwi/nestjs-enterprise-common] › ℹ  Start step "analyzeCommits" of plugin "Inline plugin"
qiwibot
[3:49:56 PM] [@qiwi/nestjs-enterprise] › ✔  Completed step "verifyConditions" of plugin "Inline plugin"
[3:49:56 PM] [@qiwi/nestjs-enterprise] › ℹ  No git tag version found on branch master
[3:49:56 PM] [@qiwi/nestjs-enterprise] › ℹ  No previous release found, retrieving all commits
[3:49:56 PM] [@qiwi/nestjs-enterprise] › ℹ  Found 9 commits since last release
[3:49:56 PM] [@qiwi/nestjs-enterprise] › ℹ  Start step "analyzeCommits" of plugin "Inline plugin"
[3:49:56 PM] [@qiwi/nestjs-enterprise-common] › ✔  Completed step "analyzeCommits" of plugin "Inline plugin"
[3:49:56 PM] [@qiwi/nestjs-enterprise] › ✔  Completed step "analyzeCommits" of plugin "Inline plugin"
[3:49:56 PM] [@qiwi/nestjs-enterprise-common] › ℹ  There are no relevant changes, so no new version is released.
[3:49:56 PM] [@qiwi/nestjs-enterprise] › ℹ  There is no previous release, the next release version is 1.0.0
[3:49:56 PM] [@qiwi/nestjs-enterprise] › ℹ  Start step "generateNotes" of plugin "Inline plugin"
[3:49:56 PM] [@qiwi/nestjs-enterprise] › ✖  Failed step "generateNotes" of plugin "Inline plugin"
[3:49:56 PM] [@qiwi/nestjs-enterprise] › ✖  An error occurred while running semantic-release: Error: Cannot release because dependency @qiwi/nestjs-enterprise-common has not been released
    at /home/travis/build/qiwi/nestjs-enterprise/node_modules/@qiwi/multi-semantic-release/lib/createInlinePluginCreator.js:68:11
    at Array.forEach (<anonymous>)
    at updateManifestDeps (/home/travis/build/qiwi/nestjs-enterprise/node_modules/@qiwi/multi-semantic-release/lib/createInlinePluginCreator.js:62:18)
context.commits = await getCommits(context);

  const nextRelease = {
    type: await plugins.analyzeCommits(context),
    channel: context.branch.channel || null,
    gitHead: await getGitHead({cwd, env}),
  };
  if (!nextRelease.type) {
    logger.log('There are no relevant changes, so no new version is released.');
    return context.releases.length > 0 ? {releases: context.releases} : false;
  }

Running semantic release on the top level project

Issue type

  • idea / discussion

Acknowledgement

Great work guys, with this issue (actually discussion) I hope I can contribute to the library and its support of it as I am big fan of semantic release :)

Discussion

I have projects that have a global configuration, or shared local packages and we have a monorepo structure. Now, the monorepo release works as expected, with no issues, but the top level as a whole does not run.

Based on what I could find, this is intended, as this runs as part of a semantic release. However, I thought of a workaround which was to trigger semantic release for monorepo and traditional repository, which is the issue. When semantic release runs for the top level project, if it is before, semantic release monorepo will see the branch as behind and it if is after the traditional monorepo will see it as behind so, so unless they run in parallel and pull the repository before any of them run the semantic release git change, then it does not work.

Actual behavior

I would love to run semantic release monorepo and if I have 5 workspaces, it will identify 6 releases, including the top level project as a whole and that could be optional.

  • I've read the docs. This case is not mentioned
  • Similar issue does not exist

Steps to reproduce

Specifications

yarn2 berry issues with updating the `yarn.lock`

I am currently using this lib to release my packages in a mono repo using yarn berry.

The problem I have is that the semantic-release/npm plugin properly rewrites the package verisons however, it does not cause an update to the yarn.lock.
I played around with configuring an /exec task that runs yarn install however, this also does not work since semantic-release/git only checks the modified files in the package path.
Therefore, it cannot see modifications in the root yarn.lock file.

Therefore, the updated yarn.lock is never committed which causes build errors since yarn berry runs yarn install in CI via the -immutable flag automatically.

The only solution I can currently think of is running a yarn install+git commit on my own after MSR is done.
It would be nicer if we could somehow get the root yarn.lock into the commit that bumps the version number.

MSR cannot run own tests if PR based on project branch

env-ci relies on env=process.env and cwd, but the first has an advantage.

env-ci

configuration({env}) {
		// ...
		return {
                         ...
			prBranch: env.TRAVIS_PULL_REQUEST_BRANCH,
			slug: env.TRAVIS_REPO_SLUG,
			root: env.TRAVIS_BUILD_DIR,
		};

semantic-release

  const context = {
    cwd,
    env,
    stdout: stdout || process.stdout,
    stderr: stderr || process.stderr,
    envCi: envCi({env, cwd}),
  };
  // ...
  const {isCi, branch: ciBranch, isPr} = context.envCi;
  // ...
  // Verify config
  await verify(context);

  options.repositoryUrl = await getGitAuthUrl({...context, branch: {name: ciBranch}});
  context.branches = await getBranches(options.repositoryUrl, ciBranch, context);
  context.branch = context.branches.find(({name}) => name === ciBranch);

  if (!context.branch) {
    logger.log(
      `This test run was triggered on the branch ${ciBranch}, while semantic-release is configured to only publish from ${context.branches
        .map(({name}) => name)
        .join(', ')}, therefore a new version won’t be published.`
    );
    return false;
  }

jobs/353878770

FAIL test/lib/multiSemanticRelease.test.js
  ● multiSemanticRelease() › Initial commit (changes in all packages)
    expect(received).toMatch(expected)
    Expected substring: "Created tag [email protected]"
    Received string:    "[9:52:11 AM] › 🎉  Started multirelease! Loading 4 packages...
    [9:52:11 AM] › ✔  Loaded package msr-test-a
    [9:52:11 AM] › ✔  Loaded package msr-test-b
    [9:52:11 AM] › ✔  Loaded package msr-test-c
    [9:52:11 AM] › ✔  Loaded package msr-test-d
    [9:52:11 AM] › 🎉  Queued 4 packages! Starting release...
    [9:52:11 AM] [msr-test-a] › ℹ  Running semantic-release version 17.1.1
    [9:52:11 AM] [msr-test-b] › ℹ  Running semantic-release version 17.1.1
    [9:52:11 AM] [msr-test-c] › ℹ  Running semantic-release version 17.1.1
    [9:52:11 AM] [msr-test-d] › ℹ  Running semantic-release version 17.1.1
    [9:52:12 AM] [msr-test-c] › ℹ  This test run was triggered on the branch upd, while semantic-release is configured to only publish from master, therefore a new version won’t be published.
    [9:52:12 AM] [msr-test-a] › ℹ  This test run was triggered on the branch upd, while semantic-release is configured to only publish from master, therefore a new version won’t be published.
    [9:52:12 AM] [msr-test-b] › ℹ  This test run was triggered on the branch upd, while semantic-release is configured to only publish from master, therefore a new version won’t be published.
    [9:52:12 AM] [msr-test-d] › ℹ  This test run was triggered on the branch upd, while semantic-release is configured to only publish from master, therefore a new version won’t be published.
    [9:52:12 AM] › 🎉  Released 0 of 4 packages, semantically!

External changes to trigger release

Hi there!
Great library/fork!)

Is there a way to collect a list of extrnal deps to trigger release/bump versions of all or some packages via config?

For example:
edits in global babel config -> new build artifacts -> minor version bump for all packages

Bug: bumping dependencies when there wasn't an update on them

I'm having some problems when bumping dependencies.

My mono repo project has simply two packages: app and lib, whereas app depends on lib.

I started a new semantic release for a change only on the app package, which triggered the tag creation for that specific package:

image

Problem is that when running the workflow that calls multi-semantic-release, the updateDeps method bumps the lib dependency, even though it wasn't changed at all:

image

This meant having a lib tag bound in the app/package.json dependencies that is non-existent, which crashed the next workflow:

image

Version being used: 3.11.0
Repository: https://github.com/davikawasaki/multi-semantic-release-monorepo

Non Github Repos

How do you pass the verifyConditions step when using Bitbucket repo instead of Github?

I have created a bit bucket personal access token and set my GITHUB_TOKEN env var to that. But multi-semantic-release keeps failing saying I haven't set my GITHUB_TOKEN. Is this project depending on using Github for this? How do I configure this to accept Bitbucket?

[10:56:44] [@isode-common/widgets] › ✔  Allowed to push to the Git repository
[10:56:44] [@isode-common/widgets] › ℹ  Start step "verifyConditions" of plugin "Inline plugin"
[10:56:44] [@isode-common/i18n] › ✖  Failed step "verifyConditions" of plugin "Inline plugin"
[10:56:44] [@isode-common/i18n] › ⚠  Skip step "fail" of plugin "@semantic-release/github" in dry-run mode
[10:56:44] [@isode-common/i18n] › ✖  EINVALIDGHTOKEN Invalid GitHub token.
The GitHub token configured in the GH_TOKEN or GITHUB_TOKEN environment variable must be a valid personal token allowing to push to the repository com/frontend-common-libs.

Please make sure to set the GH_TOKEN or GITHUB_TOKEN environment variable in your CI with the exact value of the GitHub personal token.

[multi-semantic-release]: AggregateError: 
    SemanticReleaseError: Invalid GitHub token.
    ```

Subsequent releases are not tagged as latest

Issue type

  • bug report
  • idea
  • question
  • other

Not sure if this would be an issue with multi-semantic-release, or semantic-release, but have not observed it when using the latter.

Expected behavior

Publishing a new package, should result in it's GitHub release being tagged as latest.

Actual behavior

An older release is still tagged as latest

  • I've read the docs. This case is not mentioned
  • Similar issue does not exist

Steps to reproduce

  1. Create a new project, with one or more published workspaces, let multi-semantic-release create an initial 1.0.0 release for all workspaces.
  2. Add a commit to a single workspace, E.G. feat: blue
  3. Let multi-semantic-release create a new releases for the workspace.

Observe:

  • The initial 1.0.0 release is tagged as latest
  • The 1.1.0 release is not tagged as latest
  • The 1.1.0 release appears down the list of releases
  • The 1.1.0 tag appears down the list of tags
  • Visiting <repo_url>/releases/latest displays the 1.0.0 release

Demo:

https://github.com/GeeWizWow/multi-semrel

Screenshots:

image
image

CLI flags not taking any effect when also defined in `.releaserc.js` file

Issue type

  • bug report
  • idea
  • question
  • other

Expected behavior

flags passed to the CLI should override props configured in the config file when its passed down to semantic-release

Actual behavior

.releaserc.js config file is overriding the CLI glags

  • I've read the docs. This case is not mentioned
  • Similar issue does not exist

Steps to reproduce

I have a .releaserc.js with say this configuration:

module.exports = {
  branch: 'main',
  branches: [
    { name: 'alpha', prerelease: true },
    { name: 'beta', prerelease: true },
    'main',
    'next'
  ],
  debug: true,
  dryRun: false,
};

and I'm trying to run this command locally

NPM_TOKEN=my-token-with-write-access GITHUB_TOKEN=my-token-with-write-access multi-semantic-release --ci --debug --dry-run

While I see this at the start of my script (which is ok)

multi-semantic-release version: 3.17.1
semantic-release version: 17.4.7
flags: {
  "ignorePackages": [],
  "ci": true,
  "debug": true,
  "dryRun": true, //// HERE!
  "sequentialInit": false,
  "sequentialPrepare": false,
  "firstParent": false,
  "deps": {
    "bump": "override",
    "release": "patch"
  },
  "tagFormat": "${name}@${version}"
}

semantic-release gets dryRun: false THERE 👇

pkg.result = await semanticRelease(options, {

Possible solution

const options = { ...flags, ...pkgOptions, ...inlinePlugin };

I believe the order must be:

const options = { ...pkgOptions, ...flags, ...inlinePlugin };

Question: merging back into source?

Hey folks! I have a question; did you ever discuss merging this back into source with the original authors? We're evaluating a bunch of tools, and I'd like to understand what the plans re: long-term maintenance are. Thanks!

Releases should happen only on changed packages, and not for all

Hi,

We currently have a monorepo with 2 packages and the way we would like to publish them is by running the semantic-release-multi in the root of our lerna repo and based on the changes in each of the package(together with the angular commit messages), the semantic release should publish only the changed package.

The way we are spotting changes on the packages when we push to git is by having pipelines that get triggered on folder path changes - so for instance if there is a change on packages/icons it will trigger the pipeline devoted to this package.

When running the semantic-release-multi, it publishes both packages under the same version, and a work around for now is to use the --ignore-packages=packages/a/**,packages/b/** flag.

It would be nice if we can specify the list of packages that we want published too, and not only the ones that should be ignored... such that in the pipeline we specify only the given package that should be published instead of ignoring all the other ones.

Or maybe I missed out on something, is the multi-semantic-release supposed to spot the changes per package by itself?

generateNotes error after merging pull request

Good day.
Today I faced a problem, which is very similar to dhoulb/multi-semantic-release#64.
Is it possible to get a fix from here dhoulb/multi-semantic-release#65 into this fork?

I'm use @qiwi/multi-semantic-release v3.15.0

[2:02:27 PM] [yarn-workspace-release-pack-2] › ✖  Failed step "generateNotes" of plugin "Inline plugin"
[2:02:27 PM] [yarn-workspace-release-pack-2] › ✖  An error occurred while running semantic-release: TypeError: Cannot read property 'filter' of undefined
    at generateNotes (/Users/olegshilov/Documents/yarn-workspace-release/.yarn/unplugged/@semantic-release-release-notes-generator-virtual-dcd04af038/node_modules/@semantic-release/release-notes-generator/index.js:48:8)
    at processTicksAndRejections (node:internal/process/task_queues:94:5)
    at async validator (/Users/olegshilov/Documents/yarn-workspace-release/.yarn/cache/semantic-release-npm-17.4.4-8924e8d598-870b4df485.zip/node_modules/semantic-release/lib/plugins/normalize.js:34:24)
    at async /Users/olegshilov/Documents/yarn-workspace-release/.yarn/cache/semantic-release-npm-17.4.4-8924e8d598-870b4df485.zip/node_modules/semantic-release/lib/plugins/pipeline.js:37:34
    at async /Users/olegshilov/Documents/yarn-workspace-release/.yarn/cache/semantic-release-npm-17.4.4-8924e8d598-870b4df485.zip/node_modules/semantic-release/lib/plugins/pipeline.js:31:3
    at async Object.pluginsConf.<computed> [as generateNotes] (/Users/olegshilov/Documents/yarn-workspace-release/.yarn/cache/semantic-release-npm-17.4.4-8924e8d598-870b4df485.zip/node_modules/semantic-release/lib/plugins/index.js:80:11)
    at async generateNotes (/Users/olegshilov/Documents/yarn-workspace-release/.yarn/cache/@qiwi-multi-semantic-release-npm-3.15.0-78677a7411-a908a343bb.zip/node_modules/@qiwi/multi-semantic-release/lib/createInlinePluginCreator.js:166:17)
    at async validator (/Users/olegshilov/Documents/yarn-workspace-release/.yarn/cache/semantic-release-npm-17.4.4-8924e8d598-870b4df485.zip/node_modules/semantic-release/lib/plugins/normalize.js:34:24)
    at async /Users/olegshilov/Documents/yarn-workspace-release/.yarn/cache/semantic-release-npm-17.4.4-8924e8d598-870b4df485.zip/node_modules/semantic-release/lib/plugins/pipeline.js:37:34
    at async /Users/olegshilov/Documents/yarn-workspace-release/.yarn/cache/semantic-release-npm-17.4.4-8924e8d598-870b4df485.zip/node_modules/semantic-release/lib/plugins/pipeline.js:31:3 {
  pluginName: 'Inline plugin'
}

UPD:
Related release run: https://github.com/olegshilov/yarn-workspace-release-test/runs/3085563781?check_suite_focus=true#step:6:57

Async release version control

Is there a way to control major versions across multiple async release branches?

Problem:
We have stage1, stage2 branches. Each of these branches have divergent tags - stage1 have 1.x.x, stage2 have 2.x.x. So we will get error in CI if we bump stage1 tags up to next major version.

Solution:

  1. Prevent major version bump via some team convention or via some check in multi-semantic-release.
  2. Diverge versions via semver metadata (But 'two versions that differ only in the build metadata, have the same precedence') or some prefix (which is not very sem ver).

--no-ci doesn't seem to get passed through to semantic-release

Issue type

  • bug report
  • idea
  • question
  • other

Expected behavior

Invoking MSR with --no-ci --dry-run when running in a github action should bypass the CI checks and perform a dry-run for the repo.

Actual behavior

Each package fails, complaining that it is happening in a pull request. (This error).

> multi-semantic-release --deps.bump=inherit --no-ci --dry-run
multi-semantic-release version: 6.5.1
semantic-release version: 19.0.3
flags: {
  "sequentialInit": false,
  "sequentialPrepare": true,
  "firstParent": false,
  "debug": false,
  "ignorePrivate": true,
  "ignorePackages": [],
  "tagFormat": "${name}@${version}",
  "dryRun": true,
  "deps": {
    "bump": "inherit",
    "release": "patch",
    "prefix": ""
  },
  "ci": false
}
package paths [
  '/home/runner/work/redacted/redacted/packages/__tests__/package.json',
  '/home/runner/work/redacted/redacted/packages/analytics/package.json',
  '/home/runner/work/redacted/redacted/packages/hooks/package.json',
  '/home/runner/work/redacted/redacted/packages/intercom/package.json',
  '/home/runner/work/redacted/redacted/packages/utils/package.json'
]
[3:24:46 PM] › 🎉  Started multirelease! Loading 5 packages...
[3:24:47 PM] › ✔  Loaded package @redacted/redacted-repo-tests
[3:24:47 PM] › ✔  Loaded package @redacted/package-1
[3:24:47 PM] › ✔  Loaded package @redacted/package-2
[3:24:47 PM] › ✔  Loaded package @redacted/package-3
[3:24:47 PM] › ✔  Loaded package @redacted/package-4
[3:24:47 PM] › 🎉  Queued 4 packages! Starting release...
[3:24:47 PM] [@redacted/package-1] › ℹ  Running semantic-release version 19.0.3
[3:24:47 PM] [@redacted/package-1] › ✔  Loaded plugin "addChannel" from "@semantic-release/npm"
[3:24:47 PM] [@redacted/package-1] › ✔  Loaded plugin "addChannel" from "@semantic-release/github"
[3:24:47 PM] [@redacted/package-1] › ✔  Loaded plugin "success" from "@semantic-release/github"
[3:24:47 PM] [@redacted/package-1] › ✔  Loaded plugin "fail" from "@semantic-release/github"
[3:24:47 PM] [@redacted/package-1] › ℹ  This run was triggered by a pull request and therefore a new version won't be published.
[3:24:47 PM] [@redacted/package-3] › ℹ  Running semantic-release version 19.0.3
[3:24:47 PM] [@redacted/package-3] › ✔  Loaded plugin "addChannel" from "@semantic-release/npm"
[3:24:47 PM] [@redacted/package-3] › ✔  Loaded plugin "addChannel" from "@semantic-release/github"
[3:24:47 PM] [@redacted/package-3] › ✔  Loaded plugin "success" from "@semantic-release/github"
[3:24:47 PM] [@redacted/package-3] › ✔  Loaded plugin "fail" from "@semantic-release/github"
[3:24:47 PM] [@redacted/package-3] › ℹ  This run was triggered by a pull request and therefore a new version won't be published.
[3:24:47 PM] [@redacted/package-4] › ℹ  Running semantic-release version 19.0.3
[3:24:47 PM] [@redacted/package-4] › ✔  Loaded plugin "addChannel" from "@semantic-release/npm"
[3:24:47 PM] [@redacted/package-4] › ✔  Loaded plugin "addChannel" from "@semantic-release/github"
[3:24:47 PM] [@redacted/package-4] › ✔  Loaded plugin "success" from "@semantic-release/github"
[3:24:47 PM] [@redacted/package-4] › ✔  Loaded plugin "fail" from "@semantic-release/github"
[3:24:47 PM] [@redacted/package-4] › ℹ  This run was triggered by a pull request and therefore a new version won't be published.
[3:24:47 PM] [@redacted/package-2] › ℹ  Running semantic-release version 19.0.3
[3:24:47 PM] [@redacted/package-2] › ✔  Loaded plugin "addChannel" from "@semantic-release/npm"
[3:24:47 PM] [@redacted/package-2] › ✔  Loaded plugin "addChannel" from "@semantic-release/github"
[3:24:47 PM] [@redacted/package-2] › ✔  Loaded plugin "success" from "@semantic-release/github"
[3:24:47 PM] [@redacted/package-2] › ✔  Loaded plugin "fail" from "@semantic-release/github"
[3:24:47 PM] [@redacted/package-2] › ℹ  This run was triggered by a pull request and therefore a new version won't be published.
[3:24:47 PM] › 🎉  Released 0 of 4 packages, semantically!
  • I've read the docs. This case is not mentioned (Docs do not even mention the --no-ci flag)
  • Similar issue does not exist

Steps to reproduce

Run the following in a pull request github workflow for a monorepo.
multi-semantic-release --no-ci --dry-run

Specifications

  • version: 6.5.1
  • platform: ubuntu-20.04
  • ci: github actions

`--deps.bump=satisfy` not working as expected

Issue type

  • bug report
  • idea
  • question
  • other

Expected behavior

multi-semantic-release --deps.bump=satisfy

Should respect the semver.satisfies ranges defined in our package.json

Actual behavior

multi-semantic-release --deps.bump=satisfy

Still behaves as override

  • I've read the docs. This case is not mentioned
  • Similar issue does not exist

Steps to reproduce

I don't have a full code example, but here is my setup:

monorepo with 2 repositories:

  • @myapp/core
  • @myapp/web

@myapp/web/package.json

"peerDependencies": {
    "@myapp/core": ">=1.0.0-beta.1"
}

When I execute: multi-semantic-release --deps.bump=satisfy, peerDependencies is still overwritten.

Specifications

  • version: "@qiwi/multi-semantic-release": "3.17.1"
  • platform: Mac
  • ci: N/A - tested locally

Debugging

I debugged this library locally, and noticed the following:

  • resolveNextVersion, 3rd parameter (strategy) is supposed to be "inherit", "override", "satisfy"
    * @param {string|undefined} strategy Resolution strategy: inherit, override, satisfy

    const resolveNextVersion = (currentVersion, nextVersion, strategy = "override", prefix = "") => {
  • but it's been called from within getDependentRelease passing releaseStrategy ("patch", "minor", "major", "inherit") instead of bumpStrategy
    * @param {string} bumpStrategy Dependency resolution strategy: override, satisfy, inherit.
    * @param {string} releaseStrategy Release type triggered by deps updating: patch, minor, major, inherit.

    const resolvedVersion = resolveNextVersion(currentVersion, nextVersion, releaseStrategy, prefix);

Prevent updating dependencies in affected `package.json`

Issue type

  • bug report
  • idea
  • question
  • other

Expected behavior

We would like multi-semantic-release to provide the option to avoid updating cross-references between interdependent packages with the next release version. This is particularly useful when using yarn workspace: refs as versions in package.json, which yarn pack already takes care of resolving.

  • Before multi-semantic-release:
{
  "dependencies": {
    "@myorg/packageA": "workspace:^",
    "@myorg/packageB": "workspace:^",
    "express-winston": "^5.0.0"
  }
}
  • After multi-semantic-release:
{
  "dependencies": {
    "@myorg/packageA": "1.2.3",
    "@myorg/packageB": "2.4.1",
    "express-winston": "^5.0.0"
  }
}

Ideally, both @myorg/packageA and @myorg/packageB should continue pointing to workspace:^ after a full release.

Actual behavior

Versions of affected dependents always get overridden by multi-semantic-release removing workspace: references and, ultimately, pushing changes to the repository.

Regular tags in repo

Hi guys!
I try to manage a monorepo with multi-semantic-release inside a monolith repo. Transitional stages.
So there are regular tags already present (1.0.0).

Will there be any trouble with regular, non-scoped tags (@ui/[email protected])?
like this

error: cannot lock ref 'refs/tags/1.2.2': Unable to create '/builds/ui/.git/refs/tags/1.2.2.lock': File exists.

Should I delete regular tags or maybe scope them too?

feature request: don't ignore private packages

First of all, thank you for your awesome work!

Current behaviour: if package is set to private release will be skipped.

Desired behaviour: same as upstream if the package is set to private, release will not push the package to npm but still generate a release log.

Cheers

generateNotes "waitFor" condition might unreachable sometimes

generateNotes "waitFor" condition might unreachable if some packages do not trigger the release, but hang up and still present todo queue.
semrel

const nextRelease = {
    type: await plugins.analyzeCommits(context),
    channel: context.branch.channel || null,
    gitHead: await getGitHead({cwd, env}),
  };
  if (!nextRelease.type) {
    logger.log('There are no relevant changes, so no new version is released.');
    return context.releases.length > 0 ? {releases: context.releases} : false;
  }

multi-semrel

		const generateNotes = async (pluginOptions, context) => {
			// Set nextRelease for package.
			pkg._nextRelease = context.nextRelease;

			// Wait until all todo packages are ready to generate notes.
			await waitFor("_nextRelease");

So packages must be filtered by (p) => p._nextType.

Workflow to use main and next branches

Issue type

  • bug report
  • idea
  • question
  • other

Expected behavior

The next branch can be used for next major releases.

Actual behavior

There is a git tag collision.
Having release the first version from main and then starting a new feature and pushing to next collisions with the git tag/release of main.

How is it supposed to work with that workflow? if it is possible at all.

Thank you.

  • I've read the docs. This case is not mentioned
  • Similar issue does not exist

Prereleases not updating correctly

Issue type

  • bug report
  • idea
  • question
  • other

Expected behavior

When using prerelease, packages that are a dependency on one and other are updated using 1 commit, the prelease version for a should match the version of the new updated dependency.

Actual behavior

The parent dependency is updated as expected however when the next package is triggered and depends on the parent, MSR does to update the dependency but it adds an extra patch?

Example:

Parent package updated to 1.0.0-beta.1
Child package is told to update Parent to 1.0.0-beta.2 (it should be 1.0.0-beta.1)

  • I've read the docs. This case is not mentioned
  • Similar issue does not exist

Steps to reproduce

Create 2 packages
Have one dependent on the other
Create a prerelease release.rc for both
Run MSR

My example below:

image

image

Specifications

  • version: 6.4.0
  • platform: Linux (Docker)
  • ci: Gitlab runner

bug: `tagFormat` option is omitted from config (?)

Hey, @antongolub 👋

It will be a couple of days before I can do any thorough testing, but from just a single quick and dirty test, it does look like using v${version}+${name} does sort the tags correctly. Have only done prereleases, so can't confirm if it fixes the issue with release ordering, but I'd imagine it does given tags are now sorting correctly.

FYI. I was attempting to set tagFormat as an option from the root package.json, and noticed it was being ignored, instead it's only picked up as a CLI arg, this may be expected, but for me it was contrary to expectations.

Does not work

root/
    package.json
        "release": {
            "tagFormat": "v${version}+${name}",
            ...
        }

Works

multi-semantic-release --tag-format='v${version}+${name}'

Originally posted by @GeeWizWow in #71 (comment)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.