Auto: [RFC] 简化标签配置

我喜欢第一个选项。 这是一个超级简单和干净的，我无法区分none和skip之间的区别。 如果我理解正确， skip与变更日志无关，需要带有 semver 标签，而none将跳过一个版本，但会创建一个唯一的变更日志条目。

这种方法摆脱了大部分速记，但我认为我们仍然可以支持一些？

例如，以下内容将覆盖默认的major标签，但也会继承描述和 changelogTitle

{
  labels: [
    {
      name: 'Breaking change',
      releaseType: 'major'
    }
  ]
}

或者只是编辑标题

{
  labels: [
    {
      releaseType: 'major',
      changelogTitle: 'Super Big Changes'
    }
  ]
}

skip不做发布。 none表示标签对发布没有影响...所以可能会发布也可能不会发布，这取决于其他标签的存在。 它确实需要一个更好的名字。

因此，根据您的建议，标签具有基于releaseType存在的默认后备？ 我认为这是有道理的。

因此，根据您的建议，标签具有基于存在的 releaseType 的默认后备？ 我认为这是有道理的。

是的

@zephraph它确实需要一个更好的名字。

我认为这是一个伟大的。 没有什么比说“没有，因为它对发布过程没有影响，例如杂务/依赖/任何东西”更好。

认为这是有道理的。

是的，完全。

这个提议很棒。
我认为name和chagelogTitle都应该有基于releaseType默认值。

我现在有一个 PR。 它没有解决以下问题

1. 更改日志标题可以添加到标签中，但并不清楚它们的优先顺序。 如果次要标签和文档标签都存在，哪个变更日志标题优先？

2. Logic此处描述的大部分验证可能都存在于 autobot 中。 我认为汽车本身不应该强制执行此操作

3. （与 1 相关）> 可以包含多个无标签以在变更日志的不同部分下添加 PR

我不明白。 _“跳过标签仅在与 semver 标签配对时才有效，否则是无操作的。”_有意义吗？ 如果我有deps标签或infra ，类型是skip并且我想跳过发布为什么我也需要添加 semver 标签？ 我猜我应该使用none ，但这也允许添加 semver 标签，所以...... WAT？！ :D

目前我有

    "skipReleaseLabels": [
      "documentation",
      "skip-release",
      "devDeps",
      "infra"
    ],
    "labels": {
      "deps": {
        "name": "deps",
        "title": "🔩 Dependency Updates"
      },
      "devDeps": {
        "name": "devDeps",
        "title": "🔩 Dependency Updates"
      },
      "documentation": {
        "name": "documentation",
        "title": "🗒️ Documentation"
      },
      "core": {
        "name": "core",
        "title": "📦 Core"
      }
    },

我想跳过 docs、skip-release、devDeps 和 infra，但不想跳过例如deps 。 因为我正在使用 renovate 并希望在fix(deps)上发布补丁。

无论如何，我也启用了onlyPublishWithReleaseLabel ，所以这对我来说不是什么大问题。

还有一两件事，是changelogTitle的next DIST标签？ 我只是要求澄清，因为它没有显示在 PR 中。

@tunnckoCore我认为您的设置将以新方式如下所示：

{
  "labels": [
    {
      "name": "deps",
      "title": "🔩 Dependency Updates",
      // when deps are merged create a patch release
      "releaseType": "patch"
    },
    {
      "name": "devDeps",
      "title": "🔩 Dependency Updates",
      "releaseType": "none"
    },
    {
      "name": "documentation",
      "title": "🗒️ Documentation",
      "releaseType": "none"
    },
    {
      "name": "core",
      "title": "📦 Core",
      "releaseType": "patch"
    }
  ]
}

none 有效地充当skip 。 但是，如果您确实需要发布devDep更新，则可以添加patch并进行发布。 这与添加skip标签不同，后者会跳过发布而不考虑其他标签。

更改日志标题

我也没有这样做。 它仍然只是标题。 我会将它添加到我的 PR 中以进行重构（仍然不会在下一个。我会在 changelogTitle 之后将其取出）

对。 好，太棒了 ：）

问题已在 v8.0.0-next.8 中发布

现在是吗？ 我猜prerelease是在next ？ :thinking: 无论如何，我并不着急。 仍在与 Yarn v2+pnp 和构建/捆绑作斗争。

编辑：缺少title/changelogTitle仍然意味着它不会在发行说明中占据一席之地？

@tunnckoCore根据您发布的版本，更改日志标题有默认值。

我问的是我们从配置中添加的其他“自定义标签”，而这些标签与 semver 无关。 如果我有没有标题的infra标签，它不会被添加，对吧？ 当我有标题（如在 devDeps 中）时，它将被添加。

:rocket: 问题已在 v8.0.0 中发布 :rocket:

@adierkens ，看起来这个问题是 v8 主要版本背后的主要推动力，所以我在这里问这个问题......从 v7.x 升级到 v8 有什么特别的我需要做的吗？

如果您有任何额外的labels或skipReleaseLabels您将需要使用新格式

https://intuit.github.io/auto/pages/autorc.html#label -customization

呜呜呜！ :tada: 我周末试试。

首先，v8 的酷变化！

关于

更改日志标题可以添加到标签中，但并不清楚它们的优先顺序。 如果次要标签和文档标签都存在，哪个变更日志标题优先？

从本地测试来看，目前的行为似乎是：

• 给定的PR的一个分配与truthy第一标签changelogTitle中的优先级顺序releaseType （ major ， minor ， patch ，然后所有其他人）
• 如果 PR 有多个标签与上述相同的releaseType优先级相关联，那么 PR 将首先包含在配置中定义的标签部分中（默认标签在所有其他标签之前）

下面是几个例子：

(1)：次要和无标签
配置：

"labels": [
  { "name": "typescript", "changelogTitle": "Typescript Change", "releaseType": "none" },
  { "name": "minor", "changelogTitle": "Enhancement", "releaseType": "minor" }
]

PR 上的标签：

minor

变更日志标签部分： minor

• 因为minor releaseType具有更高的优先级

(2)：多个补丁标签
配置：

"labels": [
  { "name": "typescript", "changelogTitle": "Typescript Change", "releaseType": "patch" },
  { "name": "core", "changelogTitle": "Core Change", "releaseType": "patch" }
]

PR 上的标签：

core

变更日志标签部分： typescript

• 因为typescript标签出现在core之前的配置中

(3)：无标签和默认无标签
配置：

"labels": [
  { "name": "typescript", "changelogTitle": "Typescript Change", "releaseType": "none" }
]

PR 上的标签：

internal

变更日志标签部分： internal

• 因为internal标签出现在typescript之前的配置中（它出现在默认配置中，它在相同的releaseType之间具有最高优先级

@hipstersmoothie ，上述行为/优先顺序是否有意？

如果是这样，最好添加到文档中，以便清楚更改日志标签部分的生成方式以及部分的优先级（如果需要，我可以提供帮助）

如果没有，我们是否可以努力定义优先顺序，作为这个问题的一部分或另一个？

我不认为这是特别的或错误的。 它似乎足够直观。 唯一重要的是major 、 minor和patch总是在更新日志中排在第一位，因为它是一种标准的东西。 但即使订单是可配置的，也没关系。