Auto: 하나의 리포지토리에 여러 패키지 관리자 플러그인

조금 더 생각해보면 새로운 최상위 구성 옵션을 도입하는 것이 더 합리적일 것입니다.

{
  // Still have some global config at root
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  // Plugins used for every package
  "plugins": ["conventional-commits"],
  "packages": [
    // Target specific directories and apply a set of plugins to them
    {
      "target": "www",
      "plugins": ["git-tag"]
    },
    {
      "target": "api",
      "plugins": ["npm"]
    },
    // Specify a pattern or even and array of patterns or directories
    {
      "target": ["packages/**",  "utils"],
      "plugins": ["npm"]
    },
    {
      "target": "web-store",
      "plugins": [
        "chrome-web-store",
        // Whole lifecycle is run for each package so you can have package plugins
        ["upload-assets", { "assets": ["./path/to/file"] }]
      ]
    }
  ]
}

이를 달성하기 위해 반복자 함수를 사용하여 여러 항목에 대해 shipit 를 실행하고 동일한 양의 커밋을 생성할 수 있다고 생각합니다.

예: 최신:

1. 모두 동시에 실행
2. 변경 로그를 커밋하기 전에 양보
3. 변경 로그를 한 번에 커밋
4. 버전이 충돌할 때까지 양보
5. 필요한 경우 커밋 버전
6. 끝까지 달리다

이 설정을 사용하면 lerna를 함께 건너뛸 수 있습니다.

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    }
  ]
}

package 와 일치하는 커밋이 없으면 릴리스가 이루어지지 않습니다. 이것은 lerna 없이 훨씬 간단한 방식으로 독립적인 모노레포 관리를 수행합니다. 고정 버전 모노레포를 원하신다면 클래식 루트를 선택하는 것이 좋습니다.

이것의 또 다른 멋진 기능은 리포지토리에 서로 다른 버전 관리 체계( fixed 및 independent )를 사용하여 두 개의 leran 프로젝트를 가질 수 있다는 것입니다.

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "fixed-monorepo",
      "plugins": ["npm"]
    },
    {
      "target": "independent-monorepo",
      "plugins": ["npm"]
    }
  ]
}

이것은 하나의 저장소에서 chrome-web-store 플러그인과 npm 플러그인을 사용할 수 있음을 의미합니다.

나는 당신이 같은 프로젝트에서 둘 다 사용할 수 _없다는 것을 의미한다고 가정하고 있습니까?

각 플러그인은 현재 커밋, 태그 및 푸시합니다. 이것은 많은 소음을 발생시킬 것입니다. 한 번만 발생하도록 해당 자식 작업을 코어로 이동해야 합니까? 각 패키지에 대해 별도의 커밋을 원할 수도 있습니다.

하이브리드 접근 방식을 사용하는 것이 합리적일 수 있습니다. 각 플러그인이 커밋할 수 있지만 한 번만 푸시합니까?

각 폴더가 자체 패키지 릴리스인 세계에서 태그가 어떻게 작동하는지 잘 모르겠습니다. 당신은 당신이 만드는 각 버전에 대한 태그를 생성합니까? 마지막에 하나 만드나요?

조금 더 생각해보면 새로운 최상위 구성 옵션을 도입하는 것이 더 합리적일 것입니다.

패키지별로 릴리스 경험을 사용자 정의할 수 있다는 아이디어가 마음에 듭니다. docs 패키지와 라이브러리 패키지에 대한 s3/gh-pages 배포를 관리할 수 있다는 이점을 확실히 알 수 있습니다.

한 가지 처리해야 할 것은 둘 이상의 릴리스 파이프라인에 패키지를 포함하는 것입니다. 다음과 같은 경우 어떻게 됩니까?

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    },
    {
      "target": "packages/chrome-ext",
      "plugins": ["chrome-web-store"]
    },
  ]
}

chrome-ext 패키지가 npm _and_ webstore 모두에 게시됩니까? 아니면 npm 릴리스가 먼저 선언되었기 때문에 승리합니까?

각 폴더가 자체 패키지 릴리스인 세계에서 태그가 어떻게 작동하는지 잘 모르겠습니다. 당신은 당신이 만드는 각 버전에 대한 태그를 생성합니까? 마지막에 하나 만드나요?

나는 우리가 lerna의 행동을 일치시킬 수 있다고 생각합니다. 하나의 커밋에 많은 태그가 있습니다. 각 태그는 자체 릴리스가 됩니다.

chrome-ext 패키지가 npm과 웹스토어 모두에 게시되나요? 아니면 npm 릴리스가 먼저 선언되었기 때문에 승리합니까?

이 경우 예, 두 가지 모두를 시도합니다. 그러나 그것은 단지 나쁜 구성입니다. 이를 기능으로 사용하고 두 개의 다른 레지스트리(예: npm 및 github 패키지 레지스트리)에 패키지를 게시할 수 있습니다.

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://npm" }]]
    },
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://github-package-registry" }]]
    },
  ]
}

재미있고... 복잡해보이네요 😂

나는 일반적으로 감지 기능을 지나치게 똑똑하게 하려고 하는 것보다 구성을 가지고 있습니다(예기치 않은 방식으로 고장날 수 있고 테스트하기 어려울 수 있기 때문에).

내 첫 번째 질문은 이것의 기본 상태가 어떻게 생겼는지입니다. npm 플러그인만 있다면 작동하기 전에 구성을 추가해야 합니까? 다른 사람들과 같은 질문입니다.

자식 상호 작용에 관해서는 자식 상호 작용이 일반적으로 플러그인 파이프라인의 일부여야 한다고 생각합니다. 플러그인이 커밋을 수행해야 하는 경우 커밋 가능한 후크를 사용할 수 있어야 합니다. 푸시는 CI 실행 방식과 같은 사항에 영향을 미치기 때문에 코어에서만 처리해야 합니다.

npm 플러그인만 있다면 작동하기 전에 구성을 추가해야 합니까?

현재 작동하는 구성은 packages 세계에서 작동해야 합니다. 따라서 변경이 필요하지 않습니다. 대부분의 주요 변경 사항은 노드 API 측이며 일반 사용자에게는 표시되지 않습니다.

플러그인이 커밋을 수행해야 하는 경우 커밋 가능한 후크를 사용할 수 있어야 합니다.

나는 이 아이디어를 좋아한다. auto 내에서 이 git 상호 작용을 형식화하는 것이 아마도 유용할 것입니다. 그리고 그들이 이 후크를 사용하지 않는다면 그것은 단지 약간 더 많은 노이즈를 의미합니다(예: 추가 커밋 및 추가 푸시)

또한 Monorepo와 함께 Auto를 사용하는 방법에 대해 생각하고 있었고 필요에 따라 작동할 수 있는 약간 다른 접근 방식을 생각해 냈습니다.

기본적으로 하나의 monorepo가 ​​있는 경우 각 하위 프로젝트에 필요한 플러그인을 설정할 수 있는 각각의 .autorc 파일이 있는 여러 하위 디렉터리를 가질 수 있습니다.

그런 다음 필요한 경우 각 프로젝트가 다른 시간에 릴리스될 수 있도록 각 프로젝트에 대해 다른 접두사를 갖도록 선택할 수 있습니다. 예를 들어 sub-project1의 릴리스에는 sub-project/v1.4.5 태그가 지정되고 다른 프로젝트에는 sub-project2/v9.9.9 태그가 지정됩니다.

그런 다음 Auto는 git describe --tags --matches "sub-project1/*" 와 같은 것을 사용하여 그에 따라 각 프로젝트에 대한 태그를 가져오고 업데이트할 수 있습니다.

그냥 생각.

그것은 실제로 내가 취한 접근 방식에 매우 가깝습니다. 나는
이번 주에 작업했습니다.

지금까지 일부 명령(-일치)에 해당 플래그를 추가해야 했습니다.
꽤 순조롭게 진행되고 있습니다.

저는 "패키지" 필드 접근 방식을 사용했으며 기본적으로
"autorc" 배열

접두사를 가져오기 위해 플러그인에 대한 후크를 추가하여 이름을 제공했습니다. 이것
플러그인이 다중 패키지와 호환되는 경우 자동으로 신호를 보내는 데 도움이 됩니다.

2020년 1월 29일 수요일 오후 9시 11분 Alejandro Barrientos <
[email protected]>은 다음과 같이 썼습니다.

저도 모노레포에서 Auto를 어떻게 사용할지 고민하다가
귀하의 필요에 따라 작동할 수 있는 약간 다른 접근 방식입니다.

기본적으로 하나의 monorepo가 ​​있는 경우 여러 하위 디렉토리를 가질 수 있습니다.
각각의 플러그인을 설정할 수 있는 자체 .autorc 파일이 있습니다.
각 하위 프로젝트가 필요합니다.

그런 다음 각 프로젝트에 대해 서로 다른 접두사를 갖도록 선택할 수 있습니다.
각 프로젝트는 필요한 경우 다른 시간에 릴리스될 수 있습니다. 예를 들어
sub-project1의 릴리스는 sub-project/v1.4.5로 태그가 지정될 수 있으며
다른 프로젝트는 sub-project2/v9.9.9 태그를 가져옵니다.

Auto는 git describe --tags --matches와 같은 것을 사용할 수 있습니다.
"sub-project1/*"을 사용하여 그에 따라 각 프로젝트에 대한 태그를 가져오고 업데이트합니다.

그냥 생각.

—
스레드를 작성했기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/intuit/auto/issues/917?email_source=notifications&email_token=AAJDEBGUZR5HF6P3OKRILTDRAJOOXA5CNFSM4KMLWYF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNNMVXH
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAJDEBDX72NB5Z7ZJPTDHVLRAJOOXANCNFSM4KMLWYFQ
.

다시 돌아가서 이 글을 읽고 있는데, 저는 사실 꽤 흥분됩니다! 패키지 이름 앞에 접두어가 붙은 여러 태그는 정말 좋습니다. 또한 packages 필드를 정말 좋아합니다.

@hipstersmoothie 오늘 shipit을 사용하여 2 npm 레지스트리에 게시하는 쉬운 방법이 있습니다. 보셨나요? 또는 내가 지금 좋은 개요를 가지고 있지 않은 자동의 일부 기능 토글.

@vincentbriglia 는 GitHub 패키지에 게시하는 플러그인이 작동할까요? npm 플러그인을 거의 피기백할 수 있습니다. next 및 latest 릴리스에는 쉬울 것입니다. 카나리아는 그다지 의미가 없습니다. 생각?

@hipstersmoothie NPM 레지스트리와 GHPR 레지스트리에 동일한 패키지를 게시하는 경우가 있습니다. 그 이유는 GHPR이 그렇게 광고되더라도 패키지를 올바르게 프록시하지 않기 때문입니다. 근본적인 문제는 npm과 github에서 동일한 범위를 가지고 있다는 것입니다.

우리는 주로 비공개로 개발 중이며 feature branches > next 부터 디자인 팀과 대화/승인을 받기 위해 canary 빌드를 사용하므로 canary 빌드는 이러한 맥락에서 여전히 유용합니다. npm 플러그인은 현재 이 기능을 제공하므로 이를 잃는 것은 부끄러운 일입니다.

GHPR을 사용하는 컨텍스트는 일반적으로 비공개 "조직" 컨텍스트에서 게시할 기본 위치이고 구성 요소가 공개되어야 하는 경우 npmjs.org가 보조 위치라고 가정합니다. (나는 github에서 공개 구성 요소를 설치하는 사람을 본 적이 없습니다). 오픈 소스 컨텍스트에서 일반적으로 npmjs이며 GHPR 또는 다른 개인 패키지 레지스트리가 없습니다.

참고로, 특정 GHPR 플러그인을 언급하셨기 때문에 다음 주에 일부 규칙에 따라 패키지 버전을 제거하는 자동 플러그인을 만들기 위해 시간을 따로 마련했습니다(조직은 50Gb 패키지로 제한되며 여기에는 docker 포함 이미지)

• 범위의 마지막 카나리아 제거
• 범위에서 n번째 마지막 다음 제거
• ...

나는 또한 v10에서 작업이 시작될 때까지 특정 ghpr 게시자를 만드는 것을 기쁘게 기다립니다. 여기에 제시된 아이디어는 매우 흥미롭고 아마도 더 "미래 증거"일 것입니다.

우리는 당분간 공개 및 비공개를 동시에 게시하지 않고 살 수 있지만 적어도 이것이 저의 사용 사례임을 알 수 있습니다.

"보조 패키지 레지스트리" 플러그인에 대해 더 많이 생각했습니다. 따라서 npm 플러그인은 그대로 작동하여 구성된 레지스트리에 게시합니다. 그런 다음 이 새 플러그인은 HEAD 커밋에 있는 모든 버전을 릴리스하는 두 번째 레지스트리(npm이든 ghpr이든 상관 없음)에 게시합니다.

참고로, 특정 GHPR 플러그인을 언급하셨기 때문에 다음 주에 일부 규칙에 따라 패키지 버전을 제거하는 자동 플러그인을 만들기 위해 시간을 따로 마련했습니다(조직은 50Gb 패키지로 제한되며 여기에는 docker 포함 이미지)

이것은 좋은 기능인 것 같습니다. 그런 한계가 있는 줄 몰랐어요!

이 새 플러그인은 HEAD 커밋에 있는 모든 버전을 릴리스하는 두 번째 레지스트리(npm이든 ghpr이든 상관 없음)에 게시합니다.

글쎄, 그것은 확실히 효과가있을 것입니다! 편집: 또한 우리의 시나리오(들)

안녕하세요! 이 스레드와 관련하여 Auto의 현재 상태는 무엇입니까? 동일한 릴리스에서 둘 이상의 것을 게시할 수 있습니까?

각 패키지 관리자 플러그인은 패키지 관리자를 위한 몇 가지 추가 파일에 의존하기 때문에( git-tag 제외)

이것은 잘못된 가정이라고 생각합니다. docker 플러그인이 파일에 의존합니까? 필요하지 않을 수 있으므로 나쁜 예일 수 있습니다. 다음은 또 다른 것입니다. 저는 sbt (Scala의 가장 일반적인 빌드 도구)와 함께 Auto를 사용하는 데 관심이 있으며 기계가 읽을 수 있는 JSON/XML 구성이 없습니다. sbt 빌드는 Scala 코드로 구성되며 어떤 방식으로든 sbt와 통신하는 데 필요한 빌드에 대한 정보를 추출합니다.

이것은 훨씬 간단한 방식으로 독립적인 모노레포 관리를 수행합니다.

또한 이 스레드에서 목표는 게시 요구 사항이 서로 다른 여러 하위 프로젝트가 있는 모노레포 프로젝트를 수용하는 것 같습니다. 다양한 종류의 아티팩트를 생성하는 단일 프로젝트는 어떻습니까? 예를 들어 Docker 이미지와 구성 아카이브(어딘가에 업로드 예정). 또는 NPM에 라이브러리로 게시할 수 있고 GitHub 릴리스에서 작업으로 게시할 수 있는 GitHub 작업입니다.

각 플러그인은 현재 커밋, 태그 및 푸시합니다. 이것은 많은 소음을 발생시킬 것입니다. 한 번만 발생하도록 해당 자식 작업을 코어로 이동해야 합니까? 각 package 에 대해 별도의 커밋을 _원할_ 수 있지만.

이것이 현재 플러그인 구현의 주요 문제라고 생각합니다. 이것은 각 명령이 "단 한 가지만 정말 잘 한다"는 주장에 대한 나의 혼란 으로 돌아갑니다. 제 생각에 publish 후크는 커밋을 생성하거나 git 태그를 푸시하지 않고 주어진 패키지 관리자에 대해 실제로 _만 게시_해야 합니다. 각 게시 플러그인이 패키지 관리자 세부 사항의 구현에만 집중할 수 있는 경우 프로세스의 공통 부분을 재사용 및/또는 공유할 수 있습니다. Auto로 이것을 달성할 수 있습니까? 아니면 NPM과 같은 프로젝트에 너무 편향되어 있습니까?