问题标签 [semantic-release]

当我尝试使用另一个发布分支来触发具有语义发布的发布时。语义释放告诉我

此测试运行是在分支 jose 上触发的，而语义发布配置为仅从 master 发布，因此不会发布新版本。`

有没有办法建立另一个发布分支？

这是我的 release.config.js 文件

我正在使用语义发布，并且正在尝试使用配置创建预发布

如您所见，branches它只是一个具有名称和预发布的对象（我也尝试用作数组，同样的问题）

有错误的公共存储库：
https ://github.com/Ridermansb/react-firebase-ssr/runs/813996442?check_suite_focus=true

错误

语义发布“--dry-run”“--debug”

[6:31:02 PM] [semantic-release] › ℹ 运行语义发布版本 17.1.1 [6:31:02 PM] [semantic-release] › ✔ 从“@semantic-release/”加载插件“verifyConditions” github" [6:31:02 PM] [semantic-release] › ✔ 从“@semantic-release/commit-analyzer”加载插件“analyzeCommits” [6:31:02 PM] [semantic-release] › ✔ 加载插件“generateNotes”来自“@semantic-release/release-notes-generator”[6:31:02 PM] [semantic-release] › ✔ 从“@semantic-release/github”加载插件“publish”[6:31： 02 PM] [semantic-release] › ✔ 从“@semantic-release/github”加载插件“addChannel” [6:31:02 PM] [semantic-release] › ✔ 从“@semantic-release”加载插件“success” /github" [6:31:02 PM] [semantic-release] › ✔ 从“@semantic-release/github”加载插件“失败”[6:31:10 PM] [semantic-release] › ⚠ 跳过插件“@semantic-”的步骤“失败”发布/github”在试运行模式下

分支配置（ https://github.com/semantic-release/semantic-release/blob/master/docs/usage/configuration.md#branches）中需要最少 1 个和最多 3 个发布分支。

如果您的存储库没有发布分支（例如 master），则可能会发生这种情况。

您对有问题的分支的配置是 []。

{ AggregateError: SemanticReleaseError: 发布分支在branches配置中无效。在 module.exports (/Users/ridermansb/Projects/meve.ai/web/node_modules/semantic-release/lib/get-error.js:6:10) 在 Object.entries.reduce (/Users/ridermansb/Projects/ meve.ai/web/node_modules/semantic-release/lib/branches/index.js:44:19) 在 Array.reduce () 在 module.exports (/Users/ridermansb/Projects/meve.ai/web/node_modules/ semantic-release/lib/branches/index.js:34:46) 在 module.exports (/Users/ridermansb/Projects/meve.ai/web/node_modules/semantic-release/lib/branches/index.js:66: 11) 在 process._tickCallback (internal/process/next_tick.js:68:7) 名称：'AggregateError'}npm ERR！代码生命周期

我还在语义发布/github和语义发布/语义发布repo上创建票证

大家好，

我正在尝试使用 GitLab CI 实现 NodeJS 项目的版本控制，但是在运行 npx semantic-release 时遇到了一个奇怪的问题，有人可以帮我解决这个问题。

错误信息 ：

谁能帮帮我！

此致，

我将 AWS CodeArtifact 用于私有 npm 注册表。项目有大量的依赖关系，所有这些都得到了正确的解决。我们正在成功地将包发布到我们的注册表，并将它们用作其他项目中的依赖项，在决定引入之前，一切都按预期工作semantic-release，这里发生了什么：

这仅在使用私有注册表时发生。如果我们检查 CodeArtifact 中的上游和下游存储库 - 此包只有一个版本可用/缓存（最新），而公共 npm 持有registry-auth-token@^3.0.1并且可以使用公共 npmjs 注册表安装此版本。

AWS 文档说

1. 如果my-repo包含请求的包版本，则返回给客户端。
2. 如果my-repo不包含请求的包版本，CodeArtifact 会在我的 repo 的上游存储库中查找它。
3. 如果找到包版本，则将对它的引用复制到my-repo，并将包版本返回给客户端。

根据这些点，如果公共 npm 中存在版本，它将被拉到下游并缓存，并且它确实可以与其他随机包一起使用，我尝试安装丢失/旧/未使用的版本，但仅缓存最新版本和任何registry-auth-token尝试registry-url安装其他版本最终得到

为什么 CodeArtifact 无法解析特定包版本而可以解析其他版本？是 CodeArtifact 的问题还是我在做什么？错误的？

我已经尝试了所有已知的（对我而言）解决此类问题的方法：

• npm ci
• 删除package-lock.json, node_modules+npm i
• npm cache clean -f
• npm -d ping（是的，它正在工作）
• ...

任何帮助深表感谢。

我开始使用semantic-release我拥有的一些项目，有没有办法在docs:提交时“强制”发布补丁？

为什么在文档上？因为它也在 npm 上发布，我想在那里获得最新的文档。

我还使用dependabot 使我的依赖项保持最新，也应该为更新的依赖项提供补丁版本，因为依赖项中的修复也是我项目中的潜在修复。

我在我的项目中使用 npm semantic-release ( https://www.npmjs.com/package/semantic-release )。虽然我知道这个想法不是修补计算版本，但我想创建一个特定版本作为一次性版本。有谁知道这是否以及如何可能？

例如，假设我正在使用 version 1.0.1，我想创建 version 1.0.2-desc.1。在此发布后，我想继续1.0.3/ 1.1.0/2.0.0或接下来的任何内容。

我正在为我们的 .Net Core 解决方案使用语义发布。Semantic-release 用作 GitLab 存储库上 CI 管道的一部分。

这是我的 .releaserc.json

如您所见，我使用的是简化的 GitFlow。我有一个master分支，release用于发布候选版本的单个分支和develop具有最新开发代码的分支。也有从中创建的功能分支，develop但它们没有版本控制。

我遇到的问题是，一旦我将代码从任何提交合并到develop分支将导致语义发布无法找到合并到.releasedeveloprelease

让我试着解释发生了什么。develop使用 squash 为功能分支（从 中创建）创建合并到，并develop带有提交消息，feat(Products): Add tag support此提交将导致新版本v1.10.0-beta.11。接下来，我会将develop分支合并到release，这将导致1.10.0-RC.1创建版本。接下来，我将对分支进行新的提交，develop这将导致语义发布无法创建新版本。

所有未来的提交都develop将失败。唯一的解决方案是合并release到master分支。develop如果我再次合并release。这将发生：

它将在 RC 频道上发布 beta 版本。

对我来说，这看起来像是配置问题或者分支模型问题。任何帮助，将不胜感激！

注意：最初我想使用 vanilla GitFlow 分支模型，但在语义发布方面遇到了更多问题，因此我对其进行了一些简化。

我正在尝试在暂存和生产环境中遵循 GitLab 流程。我还想要两个环境的语义发布插件（这样我还需要每个环境都有一个分支，所以语义发布可以工作，对吧？）

我已经成功地使语义发布适用于暂存分支，它vX.X.X-rc.x按预期创建，并且还生成更改日志。伟大的！

但是我应该如何正确使用这些分支？我想我明白我将如何仅使用 master 分支和两个环境来做到这一点，但我找不到任何关于使用单独的分支执行此操作的信息。

我创建功能分支，完成功能，合并到主控。怎么办？我是否应该有部署作业，在每次合并到 master 时自动将 master 合并到 staging，运行语义发布然后部署它？然后进行手动部署，自动将登台合并到生产，运行语义发布，然后部署生产？

第二个想法：我将如何处理强制提交消息约定？如果我将功能合并到主控，则有提交消息feat(x): something something。但是，那些自动主控到分期和分期到生产合并应该是什么？

我已被添加到一个使用语义发布来自动提升 NPM 包版本的存储库中。该 repo 使用Conventional Commits 规范，并且 README 非常有限。

如果我要创建一个feature/ABC-123包含新功能的分支，这是否意味着我所做的每一次提交都应该有一个提交结构，feat: my message related to this commit或者我应该只有一个feat提交，其余的chore或其他类型不会增加 repo 的版本?

或者我不需要担心这个分支feature/ABC-123，因此语义发布知道将包提升 1 个次要版本，因为它位于功能文件夹中？

希望以上内容有意义，但如果不是，这里是一个提交历史示例：

上面的这个例子会将 NPM 包提升 3 个次要版本，因为我已经使用了feat3 次，或者一个它只提升了 1 个次要版本？还是这无关紧要，唯一重要的是压缩提交并确保feat: added product card例如压缩的提交消息？

在我们的 Github 工作流程中使用语义发布。

它们的设置如下：

推送到development部署到环境development等。stagingstaging

现在每次更新版本时使用上面的包，使用语义发布/更改日志semantic-release创建一个更改日志。

我们现在应该如何处理不同分支中相互冲突的变更日志？

1. release选项：仅在分支上启用更改日志创建。（我不知道怎么做。插件没有这个选项。）
2. 选项：自动将更改日志合并回“分层”较低的分支。例如staging回到development.

我想知道有没有人有类似的问题？