Auto: Vários plug-ins do gerenciador de pacotes em um repo

Pensando um pouco mais nisso, provavelmente faria mais sentido apresentar uma nova opção de configuração de nível superior.

{
  // 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"] }]
      ]
    }
  ]
}

Para fazer isso, acho que poderíamos usar funções de iterador para executar shipit em várias coisas e gerar a mesma quantidade de commits

ex para o mais recente:

1. correr tudo ao mesmo tempo
2. rendimento antes de comprometer o changelog
3. commitar changelog tudo de uma vez
4. rendimento até a versão bater
5. confirme a versão se necessário
6. correr até o fim

Com esta configuração, você poderia realmente pular de lerna todos juntos

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

Se nenhum commit corresponder a package então nenhuma liberação será feita. Isso realiza o gerenciamento monorepo independente de uma maneira muito mais simples e sem lerna . Se você quiser uma versão fixa monorepo seguir a rota clássica seria o caminho.

Outro recurso interessante disso é que você poderia ter dois projetos leran em seu repo com diferentes esquemas de controle de versão ( fixed e independent )

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

Isso significa que você pode usar o plug-in chrome-web-store e o plug-in npm em um repositório.

Estou supondo que você quer dizer que _não_ pode usar os dois no mesmo projeto?

Cada plugin atualmente submete, marca e empurra. isso criaria muito ruído. provavelmente teria que mover essas ações git para o núcleo para que isso aconteça apenas uma vez? embora você possa querer commits separados para cada pacote.

Pode fazer sentido fazer uma abordagem híbrida. Talvez cada plugin seja confirmado, mas só fazemos push uma vez?

Não tenho certeza de como as tags funcionariam no mundo em que cada pasta é seu próprio pacote de lançamento. Você cria uma tag para cada versão que você faz? Você faz um no final?

Pensando um pouco mais nisso, provavelmente faria mais sentido apresentar uma nova opção de configuração de nível superior.

Gosto da ideia de poder personalizar a experiência de lançamento por pacote. Definitivamente posso ver alguns benefícios de ser capaz de gerenciar uma implantação s3 / gh-pages para um pacote docs comparação com seus pacotes de biblioteca.

Uma coisa a ser tratada é a inclusão de um pacote em mais de um pipeline de lançamento. O que acontece no caso de:

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

O pacote chrome-ext é publicado em npm _e_ em webstore ? Ou o lançamento de npm ganha porque é declarado primeiro?

Não tenho certeza de como as tags funcionariam no mundo em que cada pasta é seu próprio pacote de lançamento. Você cria uma tag para cada versão que você faz? Você faz um no final?

Acho que podemos igualar o comportamento da lerna. apenas um monte de tags em um commit. cada tag torna-se então seu próprio lançamento

O pacote chrome-ext é publicado tanto no npm quanto na webstore? Ou o lançamento do npm ganha porque é declarado primeiro?

Nesse caso sim, tentaria fazer as duas coisas. Mas isso é apenas uma configuração ruim. Você pode usar isso como um recurso e dizer para publicar um pacote em dois registros diferentes (ex: npm e registro de pacote github)

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

Isso parece interessante ... e complicado 😅

Eu geralmente 👍 com a configuração em vez de tentar ser excessivamente inteligente com detecção (porque isso pode falhar de maneiras inesperadas e ser difícil de testar).

Acho que minha primeira pergunta é como é o estado padrão disso. Se você tem apenas um plug-in npm , precisa adicionar configuração para que funcione? Mesma pergunta com os outros.

Quanto à interação git, parece-me que as interações git geralmente devem ser apenas uma parte do pipeline de plug-ins. Se um plugin precisa fazer um commit, ele deve apenas ser capaz de tocar em um hook passível de commit. Provavelmente, o push deve ser tratado apenas no núcleo, pois tem implicações em coisas como a forma como o CI é executado.

Se você tem apenas um plug-in npm, precisa adicionar configuração para que funcione?

A configuração que funciona hoje deve funcionar no mundo packages . Portanto, nenhuma mudança é necessária. A maioria das mudanças significativas seria do lado da API do nó e não visíveis para usuários normais.

Se um plugin precisa fazer um commit, ele deve apenas ser capaz de tocar em um hook passível de commit.

Eu gosto desta ideia. Formalizar essa interação git dentro de auto provavelmente é útil. E se eles não usarem este gancho, isso significa apenas um pouco mais de ruído (ex: um commit extra e um push extra)

Eu também estava pensando em como usar o Auto com um monorepo e vim com uma abordagem um pouco diferente que pode funcionar para sua necessidade.

Basicamente, se você tiver um monorepo, poderá ter vários subdiretórios, cada um com seu próprio arquivo .autorc que pode configurar quaisquer plug-ins que cada subprojeto precise.

Você pode então escolher ter um prefixo diferente para cada projeto, de modo que cada projeto possa ser lançado em momentos diferentes, se necessário. Por exemplo, uma versão do sub-projeto1 poderia ser marcada com sub-project/v1.4.5 e outro projeto receberia a tag sub-project2/v9.9.9

O Auto pode então usar algo como git describe --tags --matches "sub-project1/*" para obter e atualizar as tags de cada projeto de acordo.

Apenas um pensamento.

Na verdade, isso é muito próximo da abordagem que estou adotando. Eu tenho
tenho trabalhado nisso esta semana.

Tive que adicionar esse sinalizador a alguns dos comandos até agora (—matches) e
está indo muito bem.

Eu optei pela abordagem de campo de "pacotes" e é basicamente apenas e
matriz de “autorc” s

Para obter o prefixo, adicionei um gancho para plug-ins para fornecer um nome. Esse
também ajudará a sinalizar para auto se o plugin é compatível com vários pacotes

Na quarta-feira, 29 de janeiro de 2020 às 21h11 Alejandro Barrientos <
notificaçõ[email protected]> escreveu:

Eu também estava pensando em como usar o Auto com um monorepo e pensei
uma abordagem ligeiramente diferente que pode funcionar para sua necessidade.

Basicamente, se você tiver um monorepo, você pode ter vários subdiretórios
que cada um tenha seu próprio arquivo .autorc que pode configurar quaisquer plug-ins
cada subprojeto precisaria.

Você pode então escolher ter um prefixo diferente para cada projeto para que
cada projeto pode ser lançado em momentos diferentes, se necessário. Por exemplo um
a liberação do subprojeto1 pode ser marcada com subprojeto / v1.4.5 e
outro projeto obteria a tag subprojeto2 / v9.9.9

Auto pode então usar algo como git describe --tags --matches
"sub-project1 / *" para obter e atualizar as tags de cada projeto de acordo.

Apenas um pensamento.

-
Você está recebendo isto porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/intuit/auto/issues/917?email_source=notifications&email_token=AAJDEBGUZR5HF6P3OKRILTDRAJOOXA5CNFSM4KMLWYF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKJWTQI#issuecomment-580086209 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAJDEBDX72NB5Z7ZJPTDHVLRAJOOXANCNFSM4KMLWYFQ
.

Voltando e lendo isso novamente, estou realmente muito animado! As várias tags prefixadas com o nome do pacote parecem muito boas. Além disso, gosto muito do campo packages .

@hipstersmoothie : existe uma maneira fácil hoje de publicar para registros de 2 npm com o shipit, que você viu? ou algum recurso muda para automático que não tenho uma boa visão geral no momento.

@vincentbriglia um plug-in publicado no pacote GitHub funcionaria? ele poderia muito bem pegar carona no plug-in npm. Seria fácil para o lançamento de next e latest , canários não fazem tanto sentido. Pensamentos?

@hipstersmoothie , temos um caso em que publicamos o mesmo pacote no registro NPM e no registro GHPR. A razão aqui é que o GHPR, embora anunciado como tal, não faz proxy de pacotes corretamente. O problema subjacente é que temos o mesmo escopo no npm e no github.

Estamos desenvolvendo principalmente a portas fechadas, usamos as compilações canário para ter conversas / aprovações com nossa equipe de design de feature branches > next portanto, as compilações canário ainda são úteis para nós neste contexto. O plugin npm atualmente fornece essa funcionalidade, então seria uma pena perdê-la.

Suponho que o contexto com o uso de GHPR geralmente é o local principal para publicar no contexto de "organização" privada e, se um componente for tornado público, npmjs.org é secundário. (Eu não vi ninguém instalar componentes públicos do github). No contexto de código aberto, geralmente é npmjs, sem GHPR ou outro registro de pacote privado.

em uma nota lateral, já que você mencionou um plugin GHPR específico: reservamos algum tempo para a próxima semana para criar um plugin automático que removeria versões de pacotes com base em algumas regras (organizações são limitadas a 50 GB de pacotes, e isso inclui docker imagens)

• remova o último canário no alcance
• remova o enésimo último próximo no intervalo
• ...

Eu também ficaria feliz em esperar com você para criar um editor de ghpr específico até que o trabalho comece na v10. As ideias apresentadas aqui parecem muito interessantes e talvez sejam mais "preparadas para o futuro".

poderíamos viver sem publicar público e privado ao mesmo tempo por enquanto, mas pelo menos para que você saiba este é o meu caso de uso.

Eu estava mais pensando em um plugin de "registro de pacote secundário". Portanto, o plug-in npm funcionaria como está, publicando em qualquer registro configurado. Então, esse novo plug-in seria publicado em um segundo registro (seja npm ou ghpr, não importa) liberando quaisquer versões que estejam no commit HEAD.

em uma nota lateral, já que você mencionou um plugin GHPR específico: reservamos algum tempo para a próxima semana para criar um plugin automático que removeria versões de pacotes com base em algumas regras (organizações são limitadas a 50 GB de pacotes, e isso inclui docker imagens)

Este parece ser um bom recurso. Eu não sabia que esses limites existiam!

este novo plug-in seria publicado em um segundo registro (seja npm ou ghpr, não importa) liberando quaisquer versões que estejam no commit HEAD

bem, isso definitivamente funcionaria! editar: também para nosso (s) cenário (s)

Oi! Qual é o estado atual do Auto em relação a este tópico? É possível publicar mais de uma coisa no mesmo lançamento?

já que cada plugin do gerenciador de pacotes depende de algum arquivo extra para o gerenciador de pacotes (todos exceto git-tag )

Acho que essa é uma suposição errada. O plugin docker depende de algum arquivo? Pode ser desnecessário para isso, então talvez seja um mau exemplo. Aqui está outro então: Estou interessado em usar Auto com sbt (a ferramenta de compilação mais comum para Scala) e ele não tem nenhuma configuração JSON / XML legível por máquina. Um build sbt é configurado com o código Scala e para extrair qualquer informação sobre o build, você precisaria se comunicar com o sbt de alguma forma.

Isso realiza o gerenciamento monorepo independente de uma maneira muito mais simples

Também parece, a partir deste tópico, que o objetivo é acomodar projetos monorepo com vários subprojetos que têm necessidades de publicação diferentes. Que tal um único projeto que produza diferentes tipos de artefatos? Por exemplo, uma imagem Docker e um arquivo de configuração (para ser carregado em algum lugar). Ou uma ação do GitHub que pode ser publicada como uma biblioteca para o NPM e como uma ação nas versões do GitHub.

Cada plugin atualmente submete, marca e empurra. isso criaria muito ruído. provavelmente teria que mover essas ações git para o núcleo para que isso aconteça apenas uma vez? embora você possa _querer_ commits separados para cada package .

Acho que esse é o principal problema com a implementação atual de plug-ins. Isso remonta à minha confusão sobre a afirmação de que cada comando "só faz uma coisa muito bem". Na minha opinião, o gancho publish deve realmente _apenas publicar_ para o gerenciador de pacotes fornecido, não criar commits ou enviar tags git. Se cada plugin de publicação puder se concentrar apenas na implementação de seus específicos gerenciadores de pacotes, partes comuns do processo podem ser reutilizadas e / ou compartilhadas. Ainda é possível conseguir isso com o Auto ou é muito tendencioso para os projetos do tipo NPM?