Auto: 커스텀 범프 커밋 메시지

나는 범프 커밋을 선호하지 않을 수도 있습니다( semantic-release 처럼):

{
  "skipBumpCommit": true
}

범프 커밋이 비활성화된 상태에서 최신 NPM 버전은 진실의 소스이며(또는 이미 그런 식으로 작동합니까?) package.json 의 "버전" 필드는 0.0.0-development 또는 이와 유사한 것으로 설정할 수 있습니다.

travis에서 skip CI가 다른가요? 커밋 메시지가 없으면 루프에 쉽게 빠질 수 있습니다.

auto 는 로컬 버전과 게시된 버전을 살펴보고 npm 오류를 피하기 위해 더 높은 버전을 선택합니다. 그것으로 충분합니까?

travis에서 skip CI가 다른가요? 커밋 메시지가 없으면 루프에 쉽게 빠질 수 있습니다.

확실하지 않습니다. 커밋 헤더에 필요하다면 그렇게 해야 합니다. 😆

auto 는 로컬 버전과 게시된 버전을 살펴보고 npm 오류를 피하기 위해 더 높은 버전을 선택합니다. 그것으로 충분합니까?

오, 진짜? 멋진. 이 경우 범프 커밋이 생성되지 않습니까?

아니요 이 경우 게시된 버전을 충돌하므로 이전 버전 위에 게시할 수 있습니다.

skipBumpCommit 이 어떻게 작동하는지 또는 최종 결과가 어떻게 보일지 시각화하는 데 문제가 있습니다. shipit 를 실행하려면 어떤 식으로든 버전을 변경해야 하므로 해당 커밋에서 어떻게 벗어날 수 있는지 알 수 없습니다.

당신은 어떻게 생각하십니까 shipit 의 버전 때 커밋 범프 건너 뛰는 package.json 같은 것입니다 0.0.0-development ?

1. 패키지는 0.0.0 개발에서 시작합니다.

2. version 를 실행하면 PR을 기반으로 범프를 반환하고 무엇이든 반환합니다(패치, 마이너, 메이저) - 패치라고 가정해 보겠습니다.

3. 변경 로그 생성 - (0.0.0-개발 => 0.0.0). 하지만 그런 일이 일어나지 않기를 원하십니까? 대신 '0.0.0-development' 변경 로그 제목 아래에 추가하시겠습니까?

4. 게시 후크 시간 - 0.0.0-development => 0.0.0이고 게시합니다. 하지만 development 이 감지되고 게시 단계를 모두 건너뛰기를 원합니다.

5. github 릴리스 만들기 - 새 릴리스를 만드는 대신 새 커밋으로 이전 릴리스를 업데이트합니다.

6. 패키지는 ???까지 0.0.0-development로 유지됩니다. 변경 사항이 누적되는 동안

원하는 경우 두 가지 옵션:

1. 릴리스 및 게시를 시작할 때까지 auto shipit 실행하지 마십시오. 여전히 PR에 레이블을 추가하십시오. 준비가 되면 CI 프로세스에 auto shipit 를 추가하면 첫 번째 릴리스의 모든 레이블 PR이 포함됩니다.

2. 플러그인을 작성합니다. 이 동작은 매우 독특하며 npm이 버전 관리를 수행하는 방식과 실제로 일치하지 않습니다. 이 작업을 수행하기 위해 플러그인을 만들 수 있다고 생각합니다. 비록 당신이 사용할 후크를 한두 개 추가해야 할 것입니다.

0.0.0-development 버전의 패키지는 다음을 나타냅니다.

• 가장 높은 게시된 NPM 버전은 "현재 버전"으로 간주됩니다.
• version 의 package.json 는 변경하면 안 됩니다.

새 NPM 버전이 게시되어야 하는 경우 Auto는 npm version $(auto version) 사용하여 "현재 버전"을 증가시켜야 합니다.

변경 로그는 package.json 대신 NPM의 "현재 버전"을 사용합니다.

항상 그렇듯이 모든 NPM 버전에 대해 새로운 Github 릴리스가 생성됩니다.

나는 충분히 명확하고 있습니까?

package.json의 버전은 절대 변경해서는 안 됩니다.

새 버전을 NPM에 게시하려면 이를 변경해야 합니다. "현재 버전"을 늘리고 로컬 버전을 변경하지 않는 유일한 방법은 다음과 같습니다.

• 현재 버전(NPM)으로 변경
• 범프를 하다
• 다시 변경
• 하지만 태그가 범프 현재 버전이 될 것이기 때문에 ???

나는 당신의 사용 사례를 이해하고 있다고 확신합니다.

NS. 여러 PRS를 통해 기능을 개발하는 동안 여러 버전을 게시하고 싶지 않습니다.
NS. 새 버전이 게시되면 모든 변경 사항이 포함되기를 원합니다.

내 눈에는 이미 두 가지 방법이 있습니다.

1. onlyPublishWithReleaseLabel 합니다. 이 레이블을 추가할 때까지 새 버전이 생성되지 않습니다. 따라서 레이블이 없는 모든 PR/코드를 VERSION-development

2. 큰 기능을 위해 PR을 병합할 때 버전에 대한 준비가 될 때까지 skip-release 를 사용한 다음 PR을 병합하기만 하면 됩니다. 새 릴리스에는 건너뛴 PR이 모두 포함되어 있습니다. 이 경우 버전이 VERSION-development 임을 나타내는 skip-release 레이블을 추가하는 것을 볼 수 있습니다.

이것은 당신이 원하는 행동과 어떻게 다릅니까?

요약하자면 다음과 같이 요약할 수 있습니다. 버전에 -development 를 추가하여 릴리스 건너뛰기를 시작하고 모든 변경 사항을 한 번에 릴리스할 준비가 되면 제거하려고 합니다.

내 마지막 문장을 완성하기 위해 beforeShipit 를 사용하여 버전에 -development 가 있는지 확인하고 있으면 오류가 발생하는 플러그인을 만들 수 있습니다. 이렇게 하면 -development 를 제거할 때까지 shipit 가 앞으로 이동하지 않습니다.

내가 볼 수있는 유일한 문제는 CI 작업도 실패한다는 것입니다.

흥미로운 해석이지만 내가 의도한 바는 아닙니다. 😂

기본적으로 semantic-release 작동 방식을 설명하고 있습니다.

" package.json 의 버전은 npm publish 가 성공하기 위해 일시적으로만 변경되었습니다"(" package.json 의 버전은 절대 변경되어서는 안 됨" 대신)라고 _해야_ 합니다. 내가 정말로 하려고 하는 것은 범프 커밋을 완전히 피하는 것입니다. :)

좋아, 당신이 끝날 상태는 다음과 같습니다.

repo: 버전 0.0.0-dev만 있습니다.

npm: 항상 실제 버전이 있습니다(이것이 무엇이든 사용됨)

옳은?

좀 좋아

        if (auto.options.skipBumpCommit) {
          // get published version
          // change local version to publish
        } else {
          await execPromise('npm', [
            'version',
            latestBump || version,
            '-m',
            '"Bump version to: %s [skip ci]"'
          ]);
        }

        await setTokenOnCI();

        await execPromise(
          'npm',
          !isPrivate && isScopedPackage
            ? ['publish', '--access', 'public']
            : ['publish']
        );

        if (auto.options.skipBumpCommit) {
          // change local version back to DEV
        } 

        await execPromise('git', [
          'push',
          '--follow-tags',
          '--set-upstream',
          'origin',
          '$branch'
        ]);
      }

예, 좋아 보입니다!

auto v4.0.0 여기 있습니다. publish 후크를 분리해야 할 것 같습니다. 이것은 또 다른 플러그인이 될 것입니다

원하는 경우 지금은 이 기능을 Auto로 굽고 다른 플러그인에서도 필요할 때까지 publish 후크를 분할할 때까지 기다릴 수 있습니다. 😛

이것은 #247(semver 기능)이 있는 플러그인을 통해 가능해야 합니다. 커밋 메시지는 약간의 구성 변경이 필요하며 실제로 많은 것을 얻지는 못합니다. 닫혀 있지만 PR에 열려 있습니다!