Auto: Несколько плагинов диспетчера пакетов в 1 репо

Поразмыслив еще немного, я, вероятно, имел бы смысл ввести новую опцию конфигурации верхнего уровня.

{
  // 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 для нескольких вещей и генерировать одинаковое количество коммитов.

ex для последнего:

1. работать все одновременно
2. уступить перед фиксацией журнала изменений
3. зафиксировать журнал изменений сразу
4. доходность до выхода версии
5. при необходимости зафиксировать версию
6. бежать до конца

С такой настройкой вы действительно можете полностью отказаться от lerna

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

Если никакие коммиты не совпадают с package то выпуск не будет произведен. Это обеспечивает независимое управление монорепозиторием гораздо более простым способом и без lerna . Если вы хотите, чтобы монорепозиторий с фиксированной версией пошел по классическому пути.

Еще одна интересная особенность этого заключается в том, что в вашем репо может быть два проекта leran с разными схемами управления версиями ( fixed и independent ).

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

Это означает, что вы можете использовать плагин chrome-web-store плагин npm в одном репо.

Я предполагаю, вы имеете в виду, что _не__ использовать оба в одном проекте?

Каждый плагин в настоящее время выполняет коммиты, теги и отправляет. это создало бы много шума. вероятно, придется переместить эти действия git в ядро, чтобы это происходило только один раз? хотя вам может понадобиться отдельная фиксация для каждого пакета.

Возможно, имеет смысл применить гибридный подход. Может быть, каждый плагин фиксируется, но мы нажимаем только один раз?

Я не совсем уверен, как теги будут работать в мире, где каждая папка является собственной упакованной версией. Вы создаете тег для каждой версии, которую делаете? Вы делаете один в конце?

Поразмыслив еще немного, я, вероятно, имел бы смысл ввести новую опцию конфигурации верхнего уровня.

Мне нравится возможность настраивать процесс выпуска для каждого пакета. Определенно можно увидеть некоторые преимущества возможности управлять развертыванием s3 / gh-страниц для пакета docs сравнению с пакетами вашей библиотеки.

Одна вещь, которую нужно решить, - это включение пакета в более чем 1 конвейер выпуска. Что происходит в случае:

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

Публикуется ли пакет chrome-ext как в npm _, так и в 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 , нужно ли вам добавить конфигурацию, прежде чем он заработает? Тот же вопрос с остальными.

Что касается взаимодействия с git, мне кажется, что взаимодействия с git обычно должны быть просто частью конвейера надстройки. Если плагину нужно выполнить фиксацию, он должен просто иметь возможность подключиться к ловушке, допускающей фиксацию. Отправку, вероятно, следует обрабатывать только в ядре, поскольку это влияет на такие вещи, как работа CI.

Если у вас просто плагин npm, нужно ли вам добавить конфигурацию, чтобы он заработал?

Конфигурация, которая работает сегодня, должна работать в мире packages . Так что никаких изменений не требуется. Большинство критических изменений будут связаны с API узла и не будут видны обычным пользователям.

Если плагину нужно выполнить фиксацию, он должен просто иметь возможность подключиться к ловушке, допускающей фиксацию.

Мне нравится эта идея. Формализация этого взаимодействия git в auto, вероятно, будет полезна. И если они не используют этот хук, это просто означает немного больше шума (например, дополнительная фиксация и дополнительный толчок).

Я также думал о том, как использовать Auto с монорепозиторием, и придумал немного другой подход, который может сработать для ваших нужд.

В основном, если у вас есть одно монорепозиторий, у вас может быть несколько подкаталогов, каждый из которых имеет свой собственный файл .autorc который может устанавливать любые плагины, которые потребуются каждому подпроекту.

Затем вы можете выбрать разные префиксы для каждого проекта, чтобы каждый проект мог быть выпущен в разное время, если это необходимо. Например, выпуск подпроекта 1 может быть помечен тегом sub-project/v1.4.5 а другой проект получит тег sub-project2/v9.9.9

Затем Auto может использовать что-то вроде git describe --tags --matches "sub-project1/*" для получения и обновления тегов для каждого проекта соответственно.

Просто мысль.

На самом деле это довольно близко к тому подходу, который я использовал. Я
работал над этим на этой неделе.

Мне пришлось добавить этот флаг к некоторым командам до сих пор (—соответствует) и
все идет довольно гладко.

Я использовал полевой подход «пакетов», и в основном это просто и
массив «autorc»

Чтобы получить префикс, я добавил ловушку для плагинов, чтобы указать имя. Этот
также поможет сигнализировать о том, что плагин совместим с несколькими пакетами

В среду, 29 января 2020 г., в 21:11 Alejandro Barrientos <
[email protected]> написал:

Я также думал о том, как использовать Auto с монорепозиторием, и придумал
немного другой подход, который может сработать для ваших нужд.

В основном, если у вас есть одно монорепозиторий, у вас может быть несколько подкаталогов.
что у каждого есть свой собственный файл .autorc, который может устанавливать любые плагины
каждому подпроекту потребуется.

Затем вы можете выбрать разные префиксы для каждого проекта, чтобы
при необходимости каждый проект может быть выпущен в разное время. Например,
выпуск подпроекта1 можно пометить тегами 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=AAJDEBGUZR5HF6P3OKRILTDRAJOOXA5CNFSM4KMLWYF2YY3PNVWWK3TUL52HS4DFVREXIWL8
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AAJDEBDX72NB5Z7ZJPTDHVLRAJOOXANCNFSM4KMLWYFQ
.

Возвращаясь и перечитывая это снова, я на самом деле очень взволнован! Несколько тегов с префиксом к имени пакета звучат действительно хорошо. Также мне очень нравится поле packages .

@hipstersmoothie есть ли сегодня простой способ опубликовать в 2 реестрах npm с помощью shipit, который вы видели? или некоторые функции переключаются в автоматическом режиме, о которых у меня нет хорошего обзора прямо сейчас.

@vincentbriglia будет ли next и latest , канарейки не имеют такого большого смысла. Мысли?

@hipstersmoothie: у нас есть случай, когда мы публикуем один и тот же пакет в реестре NPM и GHPR. Причина в том, что GHPR, даже если он рекламируется как таковой, неправильно передает пакеты. Основная проблема в том, что у нас одинаковая область видимости для npm и github.

В основном мы разрабатываем за закрытыми дверями, мы используем канареечные сборки для обсуждения / согласования с нашей командой дизайнеров с feature branches > next поэтому канареечные сборки по-прежнему полезны для нас в этом контексте. Плагин npm в настоящее время предоставляет эту функцию, поэтому было бы жаль потерять ее.

Я полагаю, что контекст использования GHPR обычно заключается в том, что это основное место для публикации в частном контексте «организации», а если компонент должен быть опубликован, npmjs.org является второстепенным. (Я не видел, чтобы кто-нибудь устанавливал общедоступные компоненты из github). В контексте открытого исходного кода это обычно npmjs, а не GHPR или другой частный реестр пакетов.

на стороне примечания, поскольку вы упоминаете конкретный плагин GHPR: мы выделили некоторое время на следующую неделю, чтобы создать автоматический плагин, который будет удалять версии пакетов на основе некоторых правил (организации ограничены 50 ГБ пакетов, включая докер изображений)

• удалить последнюю канарейку в диапазоне
• удалить n-ый последний следующий в диапазоне
• ...

Я бы также с радостью подождал, пока вы создадите конкретного издателя ghpr, пока не начнется работа над v10, идеи, представленные здесь, кажутся очень захватывающими и, возможно, являются более «перспективным».

мы могли бы жить без публичной и частной публикации одновременно, но, по крайней мере, чтобы вы знали, что это мой вариант использования.

Я больше думал о плагине "вторичного реестра пакетов". Таким образом, плагин npm будет работать так же, как он, публиковать в любом настроенном реестре. Затем этот новый плагин опубликует во втором реестре (неважно, npm или ghpr), выпуская все версии, которые есть в фиксации HEAD.

на стороне примечания, поскольку вы упоминаете конкретный плагин GHPR: мы выделили некоторое время на следующую неделю, чтобы создать автоматический плагин, который будет удалять версии пакетов на основе некоторых правил (организации ограничены 50 ГБ пакетов, включая докер изображений)

Кажется, это хорошая особенность. Я не знал, что существуют эти ограничения!

этот новый плагин будет публиковаться во втором реестре (независимо от того, npm или ghpr не имеет значения), выпуская любые версии, которые находятся в фиксации HEAD

хорошо, это определенно сработает! изменить: также для нашего сценария (ов)

Привет! Каково текущее состояние Auto по отношению к этой теме? Можно ли опубликовать более одной публикации из одного выпуска?

поскольку каждый плагин диспетчера пакетов полагается на какой-то дополнительный файл для диспетчера пакетов (все, кроме git-tag )

Я считаю, что это ошибочное предположение. Плагин docker полагается на какой-либо файл? Возможно, это не нужно, так что, возможно, это плохой пример. Вот еще один: мне интересно использовать Auto с sbt (наиболее распространенный инструмент сборки для Scala), и у него нет машиночитаемой конфигурации JSON / XML. Сборка sbt настраивается с помощью кода Scala и для извлечения любой информации о сборке вам может понадобиться каким-либо образом взаимодействовать с sbt.

Это значительно упрощает независимое управление монорепозиториями.

Из этой темы также кажется, что цель состоит в том, чтобы приспособить монорепозиционные проекты с несколькими подпроектами, которые имеют разные потребности в публикации. А как насчет одного проекта, который производит разные виды артефактов? Например, образ Docker и архив конфигурации (куда-то загружать). Или действие GitHub, которое можно опубликовать как библиотеку в NPM и как действие в выпусках GitHub.

Каждый плагин в настоящее время выполняет коммиты, теги и отправляет. это создало бы много шума. вероятно, придется переместить эти действия git в ядро, чтобы это происходило только один раз? хотя вы можете _ захотеть_ разделить коммиты для каждого package .

Я думаю, что это основная проблема текущей реализации плагинов. Это восходит к моему заблуждению по поводу утверждения, что каждая команда «действительно хорошо выполняет только одну вещь». На мой взгляд, ловушка publish действительно должна _only publish_ для данного диспетчера пакетов, а не создавать коммиты или отправлять теги git. Если каждый плагин публикации может сосредоточиться только на реализации специфики своего диспетчера пакетов, общие части процесса можно повторно использовать и / или совместно использовать. Можно ли добиться этого с помощью Auto или он слишком предвзято относится к проектам, подобным NPM?