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. Changelog 제목은 레이블에 추가할 수 있지만 우선 순위가 어떤 순서인지 명확하지 않습니다. 부 및 문서 레이블이 모두 존재하는 경우 어떤 변경 로그 제목이 우선합니까?

2. Logic 여기에 설명된 대부분의 유효성 검사는 아마도 autobot에 있어야 합니다. 나는 자동 자체가 이것을 강제해야한다고 생각하지 않습니다.

3. (1 관련) > 변경 로그의 다른 섹션 아래에 PR을 추가하기 위해 여러 개의 없음 레이블을 포함할 수 있습니다.

나는 그것을 이해하지 못한다. 어떻게 _"건너뛰기 레이블은 semver 레이블과 짝을 이룰 때만 유효하고 그렇지 않으면 no-op입니다."_ 의미가 있습니까? deps 레이블 또는 infra 경우 유형은 skip 이고 릴리스를 건너뛰고 싶습니다. 왜 semver 레이블도 추가해야 합니까? 그러면 none 를 사용해야 할 것 같은데, 이렇게 하면 semver 레이블도 추가할 수 있으므로... WAT?! :디

현재 나는

    "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"
      }
    },

문서, skip-release, devDeps 및 인프라를 건너뛰고 싶지만 예를 들어 deps 는 건너뛰고 싶지 않습니다. 나는 renovate를 사용하고 있고 fix(deps) 에 패치 릴리스를 원하기 때문입니다.

또한 어쨌든 onlyPublishWithReleaseLabel 활성화했으므로 큰 문제가 되지 않습니다.

그리고 한 가지 더, next dist-tag에 changelogTitle 가 있습니까? 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 에 게시된 것

편집: 그리고 title/changelogTitle 누락

@tunnckoCore 릴리스하는 버전에 따라 변경 로그 제목에 대한 기본값이 있습니다.

구성에서 추가하고 semver에 대한 것이 아닌 다른 "사용자 정의 레이블"에 대해 묻고 있습니다. 제목이 없는 infra 레이블이 있으면 추가되지 않겠죠? 그리고 devDeps와 같이 제목이 있으면 추가됩니다.

:rocket: v8.0.0에서 문제가 릴리스되었습니다.

@adierkens , 이 문제가 v8 Major rev의 주요 원동력인 것 같아서 여기에 질문을

추가 labels 또는 skipReleaseLabels 가 있는 경우 새 형식을 사용해야 합니다.

https://intuit.github.io/auto/pages/autorc.html#label - 사용자 정의

우훗! :tada: 주말에 해봐야겠습니다.

먼저 v8의 멋진 변경 사항!

에 관하여

Changelog 제목은 레이블에 추가할 수 있지만 우선 순위가 어떤 순서인지 명확하지 않습니다. 부 및 문서 레이블이 모두 존재하는 경우 어떤 변경 로그 제목이 우선합니까?

로컬 테스트에서 현재 동작은 다음과 같습니다.

• truthy와 제 라벨 PR 주어진 ㄱ 할당 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 가 일종의 표준이기 때문에 변경 로그에서 항상 첫 번째 항목이 되어야 한다는 것입니다. 그러나 순서가 구성 가능하더라도 괜찮습니다.