Auto: Исправления - Патчи поддержки старых миноров и патчей

@hipstersmoothie
Есть ли у вас какие-либо подробности того, как это будет реализовано / как это будет выглядеть на практике?

Кроме того, я не уверен, что понимаю, что означает merge into a tag ... не могли бы вы уточнить? Насколько я понимаю, вы можете создать PR только с веткой в ​​качестве цели.

Нет, я особо не задумывался о проблеме.

Кроме того, я не уверен, что понимаю, что означает объединение в тег

Пользовательский интерфейс заставил меня поверить, что вы можете объединить в тег, но при дальнейшем просмотре это кажется невозможным. Если бы мы могли, это сделало бы это возможным.

Вспомнив немного, думаю, вот о чем я думал:

1. Тег 1.2.3 существует, текущая версия - 2.0
2. PR превращается в тег 1.2.3, производит 1.2.3-0 (0 - это сборочная часть semver)

хорошо, использование build части semver определенно имеет смысл. 👍

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

Можно использовать аналогичный подход к старой основной поддержке ( versionBranches ), когда в конфигурации можно указать префикс ветки. Похоже, что эта функция может быть больше ориентирована на выпуски типа исправлений, поэтому, возможно, имеет смысл хранить конфигурацию отдельно от старой основной поддержки. Что вы думаете?

Примерный поток может выглядеть так:

• пользователь указывает в автоконфигурации для сборки с использованием идентификаторов сборки для веток с префиксом hotfix-
• существующий журнал фиксации
  <ul> <li>(tag: v2.0.0) (master)<br /> |</li> <li>(tag: v1.2.0)<br /> |</li> <li>(tag: v1.1.0)<br /> |</li> <li>(tag: v1.0.0)<br />

Можно использовать аналогичный подход к старой основной поддержке (versionBranches), где префикс ветки может быть указан в config.

Мне нравится эта идея, но на практике я не думаю, что ее было бы так весело использовать. Поскольку auto выпускает много, вы получите сумасшедшее количество веток.

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

Я согласен с тем, что такой выпуск выходит за рамки нормы. что делает автоматическое создание веток менее полезным. Вы получили бы много шума (больше веток), если бы вообще их не использовали.

Что касается предложенного вами выше потока, похоже, он работает хорошо. К сожалению, мы не можем превратить PR в теги! упростит этот рабочий процесс.

Подумав об этом, эта функция, вероятно, потребует нескольких вещей в auto чтобы полностью конкретизировать:

1. Новая команда auto hotfix : при запуске выпустит проект с новой версией исправления на основе последнего тега в ветке
2. Новые функции для auto shipit : определить, находимся ли мы в hotfixBranch и запустить auto hotfix

Что касается того, как должен работать auto hotfix он может быть следующим:

1. способ next или canary => Новый хук, который позволяет плагину контролировать выпуск исправления, поддерживается ли оно вообще
2. повторно использовать хуки version и publish и сделать так, чтобы они могли выпустить build semver

Из двух вариантов, я думаю, я склоняюсь к 1 поскольку вызов хуков version и pubish по-новому можно считать критическим изменением. Недостатком этого является то, что некоторые из хуков не будут называться afterVersion чего некоторые плагины не будут работать. В настоящее время это проблема как для canary и для next . поскольку они тоже не называют этот крючок. Так что не о чем сразу беспокоиться.

Вы заинтересованы в попытке добавить это?

Мне нравится эта идея, но на практике я не думаю, что ее было бы так весело использовать. Поскольку авто выпускает много, вы получите сумасшедшее количество веток.

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

Если подумать об этом, то, вероятно, для полной реализации этой функции потребуется несколько вещей в автоматическом режиме:

1. Автоматическое исправление новой команды: при запуске проект будет выпущен с новой версией исправления на основе последнего тега в ветке.
2. Новая функциональность для автоматической доставки: определение того, находимся ли мы в ветке исправления, и запуск автоматического исправления

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

Что касается того, как должно работать автоматическое исправление, оно может быть следующим:

1. the way of next или canary => Новый хук, который позволяет плагину контролировать выпуск исправления, поддерживается ли оно вообще
2. повторно использовать версию и опубликовать хуки и сделать так, чтобы они могли выпускать сборку семвера

Из двух вариантов, я думаю, я склоняюсь к одному, поскольку вызов версии и публикации хуков по-новому можно было бы считать критическим изменением. Недостатком этого является то, что некоторые из хуков не будут вызываться afterVersion, из-за чего некоторые плагины не будут работать. В настоящее время это проблема как для канарейки, так и для следующей. поскольку они тоже не называют этот крючок. Так что не о чем сразу беспокоиться.

Высокий уровень, я думаю, что 1 тоже имеет смысл. Мне нужно было бы проследить код, чтобы лучше понять, какие хуки вызываются для какой команды, но если next , canary , & hotfix все следуют аналогичным шаблонам, тогда любые болевые точки, вероятно, будет легче решить позже.

Вы заинтересованы в попытке добавить это?

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

Потрясающие! Никакой запланированной работы над этим нет, так что это все вы

FWIW - Я собирался попытаться сконструировать это как плагин, выполнив именно то, что вы считали второстепенным выбором - создав ветвь version-MAJOR-MINOR . Это не похоже на слишком много шума по нашему текущему процессу, TBH. Мы уже создаем ветки для каждой линии выпуска.

Большую часть versionBranches сейчас составляет этот плагин :

    this.hooks.beforeCommitChangelog.tapPromise(
      "Old Version Branches",
      async ({ bump }) => {
        if (bump === SEMVER.major && this.config?.versionBranches) {
          const branch = `${this.config.versionBranches}${major(
            await this.hooks.getPreviousVersion.promise()
          )}`;

          await execPromise("git", [
            "branch",
            await this.git?.getLatestTagInBranch(),
          ]);
          await execPromise("git", ["push", this.remote, branch]);
        }
      }
    );

Добавление поддержки для SEMVER.minor выглядит тривиальным, но я признаю, что не знаю, какие другие части auto могут потребоваться изменения.

Это часть того, что происходит со старой версией, но тогда эта проверка в shipit также должна пройти.

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1442

Которая затем идет сюда и в основном просто отменяет, с чего начать вычисление выпуска из

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1509

Единственное соображение, которое мы должны сделать со старым второстепенным / патчем, а не основным, - это потенциальное несоответствие версии. С несовершеннолетними это, наверное, меньшая проблема.

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *  (tag: v1.1.2) <- Need to add logic to find an available tag 
| /
*  (tag: v1.1.0) (hotfix-feature)
|
*  (tag: v1.0.0)

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

Правила :

1. не может выпускать мажор в любой старой ветке минорного / патч-релиза (обязательно)
2. не может выпускать минор в какой-либо старой ветке выпуска исправлений (может быть, ненужно?)

@hipstersmoothie
Знаете ли вы, каково поведение по умолчанию, если у вас есть настройка ci для создания более старого тега, когда следующий тег недоступен?

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

то есть:

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *   <- what is current behavior if I try to release this commit
| /
*  (tag: v1.1.0) 
|
*  (tag: v1.0.0)

Помимо соблюдения правил, указанных в @hipstersmoothie , я вижу одну потенциальную проблему / путаницу со стратегией / реализацией try to unique version number . В примере, приведенном @hipstersmoothie , v1.1.2 будет восприниматься другими как выпуск исправления от v1.1.1 , но, поскольку развитие не было линейным, это не гарантируется. Потенциально может быть даже обратное несовместимое изменение с v1.1.1 на v1.1.2 поскольку вполне вероятно, что v1.1.2 не имеет изменений с v1.1.1 . Это может обостриться и запутаться, если следующая уникальная версия находится на большем расстоянии от v1.1.0 (то есть: что, если следующая уникальная версия будет v1.1.100 ?)

Использование части метаданных сборки в semver ограничило бы эту путаницу, поскольку, согласно спецификации semver, она игнорируется при вычислении приоритета версии. Если увеличивается номер метаданных сборки, то, возможно, вместо увеличивающегося номера можно использовать commit sha.

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

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

Знаете ли вы, каково поведение по умолчанию, если у вас есть настройка ci для создания более старого тега, когда следующий тег недоступен?

Обычно теги не создаются, потому что в сообщении коммита есть [skip ci]

Это может обостриться и запутаться, если следующая уникальная версия будет дальше от v1.1.0.

Это отличный момент. Определенно делает правильную стратегию частью метаданных сборки версии.

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

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

Может быть, если мы сделаем микс, это может сработать. Патч и старые второстепенные должны быть легкими. Он может работать точно так же, как oldVersionBranches для мейджоров:

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.2.0)
|
|  *  (tag: v1.1.5) <- Can merge patched into old minor branch, maybe error when PR has `minor`
| /
*  (tag: v1.1.4) <- branch: version-1.1
|
*  (tag: v1.0.0)

Затем нам нужно только сделать часть метаданных сборки для исправления патчей.

Есть ли встроенный способ исправления при объединении параметров from и useVerion ? Мне просто нужно было сделать его сегодня, и я решил сделать это вручную.

Для контекста мой проект находится на 7.7. Один из основных потребителей нашего проекта в настоящее время выпускает версию на 7.5, обнаружил проблему и потребовал 7.5.1, поэтому им не пришлось повторно проверять все в середине выпуска. Не оптимально, но иногда случается.

Насколько мне известно, по-прежнему невозможно сделать это без ручного вмешательства. Я думаю, что кто-то из сотрудников компании intuit планирует в конечном итоге добавить это. Я согласен, что это функция, которой очень не хватает в авто

Приятно слышать! Спасибо 🙏

Мы (я и @ 10hendersonm) разработали решение для этого, но оно довольно
вовлеченный. Однако он использует только авто и плагины!

Мы только что исправили 7.2.1, 8.1.1 и 8.2.2 нашего проекта, используя только PR.
(очень осторожно).

Мы могли бы изучить, как поделиться этим, если людям интересно?

В чт, 14 января 2021 г., 19:27 Мэтт Фелтен [email protected] написал:

Приятно слышать! Спасибо 🙏

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/intuit/auto/issues/1054#issuecomment-760583830 или
отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AACI3Q6RKDONYJVH6UWUPFLSZ6KZNANCNFSM4LFJ4ULQ
.

Мне было бы очень интересно!

Всем здравствуйте! Я заинтересован в этом. Мое предложение следующее:

1. Как правило, auto будет пытаться уважать любые ветки version-* . Например, слияние патча из любой ветки в version-1.1.4 приведет к выпуску версии 1.1.5 . Если эта версия уже была создана, либо выпуск NPM, либо тег Git завершится ошибкой, но это нормальный и ожидаемый случай ошибки.
2. Мы можем обновить versionBranches чтобы принять "major" | "minor" | "patch" , что создаст потенциальные ветки исправлений в зависимости от того, что вы укажете. Это позволяет вам выбирать компромисс между созданием ветки version-* вручную и слишком большим количеством веток, которые нужно поддерживать, когда вам не нужны исправления.

Мысли?

но это нормальный и ожидаемый случай ошибки \

Я все еще ожидаю, что это создаст какую-то версию. Недавно у меня был случай, когда я хотел выпустить исправление из определенного коммита, чтобы ничего больше не тянуть. Я думаю, что в этом случае мы могли бы использовать сборочную часть semver из разговора выше.

Мы можем обновить versionBranches, чтобы принять "основные" | «минор» | "пластырь"

Текущая конфигурация может быть либо true либо строкой для префикса основных ветвей. Думаю, новый конфиг должен выглядеть примерно так

{
  "versionBranches": {
      "branchPrefix": "version-",
      "types": ["major", "minor"] // defaults to just major   
   }
}

Последний вопрос, на который нужно ответить, - это обработчик исправлений или вызов хуков версии + публикации, глядя на код для реализации ветки текущей старой версии, мы выполняем вариант 2 и вызываем версию + публикацию (и я думаю, что это ошибочно публикуется в последний тег).

@lshadler Нам многим нужно немного

@bmuenzenmeyer Не могли бы вы рассказать о своем подходе?

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

Для старых выпусков нам нужен полный последний конвейер для запуска с журналом изменений, afterVersion и всеми или их хуками, вызванными во время последнего выпуска.

Вероятно, нам следует сделать так, чтобы в следующих выпусках была такая же версия после публикации версии после публикации потока последней версии. Это тоже может быть частью v11. Он должен соответствовать последнему рабочему процессу, чтобы вы могли добавить аналогичную автоматизацию.

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

Привет всем, с сумасшествием этого прошлого года, к сожалению, эта проблема ускользнула от меня.

Что касается различных подходов, я думаю, что будет полезно рассмотреть различные варианты использования, для которых решаются эти функции. На мой взгляд, я вижу 2 варианта использования:

• (1) долгосрочная поддержка старой ветки (например, старая основная версия)
• (2) краткосрочная поддержка конкретной версии (например, исправление)

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

(1) Я считаю, что versionBranches сможет решить проблему для долгосрочной поддержки ветки / выпуска. Если есть желание расширить это поведение для второстепенных версий (как некоторые уже упоминали выше), то это могло бы быть улучшением этой функциональности.

(2) Для краткосрочной поддержки / исправления, основываясь на приведенных выше потоках, я думаю, что должен быть стандартный способ для пользователей всегда использовать сборочную часть semver для создания выпуска исправления. Это обеспечивает согласованное поведение владельцев кода и позволяет избежать нескольких сложных сценариев крайних случаев. В этом случае, я думаю, можно использовать новую команду исправления и ловушку. Это могло быть явным улучшением. В общем, этот вариант использования должен быть относительно редким, поскольку следует поощрять потребителей использовать последнюю версию, если это возможно.

edit _ (Для краткосрочного использования потенциально versionBranches config можно расширить, чтобы разрешить параметр / переключатель / флаг, который указывает, следует ли соблюдать метки semver для веток version- или всегда использовать часть сборки semver и игнорируйте любые метки для этих веток) _

Есть ли какие-либо другие варианты использования, кроме этих 2, которые следует учитывать?

Следует ли рассматривать разные подходы для разных случаев использования?

(Кроме того, я все еще могу помочь с некоторыми из этих изменений, но определенно не хочу блокировать кого-либо еще от принятия изменений для этого)

также косвенная мысль о паттернах ветвления:

auto сгенерирует тег git (релиз) для выпусков. Это означает, что действительный git ref помещается в github. В случае использования краткосрочной поддержки (например, краткосрочная ветвь / ветвь исправления) это означает, что пользователь может удалить короткоживущую ветку после того, как был отправлен тег release / git.

• учитывая главную ветку со следующими тегами
  <ul> <li>(tag: v1.3.0) (master)<br /> | </li> <li>(tag: v1.2.3)<br />

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

Недавно я играл с кодом, чтобы использовать сборочную часть semver для создания сборок. При этом я натолкнулся на вариант использования, когда последний выпуск github не обязательно был последней / высшей семантической версией.

Например, в примере, упомянутом здесь: https://github.com/intuit/auto/issues/1054#issuecomment -780286683, последний выпуск github будет отображаться как v1.2.3+1 поскольку он был временно создан после самого высокого версия семантическая версия: v1.3.0 .

Поскольку довольно много мест в коде ссылки getLatestRelease , это может привести к различному поведению, если конвейер явно не устанавливает параметр from . то есть:

• что включено в примечания к выпуску
• как рассчитывается предыдущая версия
• потенциально нарушающая функциональность, если последняя версия github недоступна из фиксации HEAD

Я не тестировал, но считаю, что эти типы сценариев также будут доступны через существующее поведение versionBranches . Я считаю, что это связано с комментарием о том, какие потоки должны генерировать теги git / выпуски github:

Последний вопрос, на который нужно ответить, - это обработчик исправлений или вызов хуков версии + публикации, глядя на код для реализации ветки текущей старой версии, мы выполняем вариант 2 и вызываем версию + публикацию (и я думаю, что это ошибочно публикуется в последний тег).

Что касается решения, эту проблему, вероятно, можно решить независимо от рефакторинга хуков, заменив логику getLatestRelease на:

• (1) получить выпуски github, используя listReleases а затем отсортировать, чтобы найти самую высокую версию выпуска (без предварительных выпусков или частей сборки), которая доступна
• (2) или получить теги git, а затем отсортировать, чтобы найти самую высокую версию выпуска (без предварительных выпусков или частей сборки), которая доступна

Разница здесь будет заключаться в том, рассматривает ли auto выпуски github или теги git как источник истины, что связано с обсуждением https://github.com/intuit/auto/discussions/1867#discussioncomment -684192.

Я бы изначально склонялся к (2), так как

• (а) в конечном итоге мы следуем за git ref (tag), а не за другими элементами выпуска github
• (б) это уменьшит количество сетевых вызовов

@hipstersmoothie ,
Если нам нужно изменить логику getLatestRelease , что вы думаете по поводу (1) использования выпусков github vs (2) использования тегов git vs (3) чего-то еще?

Да, чтобы автоматическая работа с несколькими пакетами работала, потребуется рефакторинг всех последних выпусков GitHub, чтобы они были просто тегами. 2 - это вариант, с помощью которого можно выполнить эту работу.