Это первый из четырех сценариев, которые я решил написать, как указано в архитектуре системы. Чувствовал себя накачанным! это был шаг в направлении создания «вики» интерфейса, который вносит вклад в открытый исходный код без взаимодействия с пользовательским интерфейсом GitHub?.

Что это за скрипты?

Это js-файлы, содержащие некоторые связанные функции многократного использования, специально предназначенные для взаимодействия с API GitHub; они либо используются в рамках одного и того же сценария, либо экспортируются для использования для выполнения своих базовых функций в другом месте проекта. Они принимают аутентифицированный экземпляр Octokit пользователя в качестве параметров среди других. Этот экземпляр используется для выполнения действий/функций через API GitHub от имени аутентифицированного пользователя.

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

1. Репозиторий форка проекта
2. Создать ветку
3. Зафиксировать изменения в ветке (в нашем случае добавить новый mdx-файл в каталог src/pages/word/ для нового слова или отредактировать существующие)
4. Создайте запрос на включение (в нашем случае отправьте изменения слов)

Истина, достойная упоминания

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

Сценарий

Задачей здесь было создать «Скрипт форка», конечная цель которого — создать/получить форк репозитория jargons.dev в/из учетной записи пользователя. Он должен содержать все функции, которые будут делать следующее.

• Проверьте, существует ли уже форк jargons.dev в учетной записи пользователя
  • Если форк существует
    • Проверьте, синхронизирован ли форк с восходящим потоком (т. е. актуален ли основной веткой репозитория jargons.dev); ЕСЛИ НЕТ — обновите форк
  • Если вилка НЕ ​​найдена
    • Создать вилку

Поняв задание, я «углубился» сразу в работу над сценарием.

Я уже очень привык к API GitHub из-за того, что часто использую их в повседневной работе над Hearts ❤️... Итак, документация по форку GitHub выглядела для меня как брошки?...

Шаги

• Я создал основную функцию forkRepository, которая была основной точкой входа для выполнения функциональности вилки — она ведет куда угодно
• Я добавил следующие функции, которые в основном служили помощниками для очевидной основной функции forkRepository
  • isRepositoryForked — эта функция проверяет, уже ли репозиторий jargons.dev разветвлен на учетную запись текущего аутентифицированного пользователя
  • isRepositoryForkUpdated — чтобы проверить, обновлен ли форк (если он найден) (синхронизирован с главным репозиторием) с основным репозиторием jargons.dev
  • updateRepositoryFork — используется для обновления (синхронизации) репозитория до состояния основного (головного) репозитория jargons.dev
  • getBranch — это базовая утилита (необходимая на момент написания этого сценария), используемая для получения сведений о ветке/ссылки для репозитория jargons.dev и пользовательской вилки для использования в сравнении, которое выполняется в помощнике isRepositoryForkUpdated для выполнения своей основной функции; он использует конечную точку GitHub References.

Мое странное предположение

У меня в голове? когда я писал этот сценарий, я придерживался мысли, которую я придерживался после прочтения цитируемого ниже абзаца в документации по форку GitHub

Примечание: Форкирование репозитория происходит асинхронно. Возможно, вам придется подождать некоторое время, прежде чем вы сможете получить доступ к объектам git. Если это занимает больше 5 минут, обязательно обратитесь в службу поддержки GitHub.

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

Это предположение вынудило меня не возвращать какие-либо данные из основной функции forkRepository, и на этом этапе я уже начал думать — как мне заставить детали вилки обрабатываться на следующем этапе процесса внесения!? Хм, может, я воспользуюсь вебхуками?!?

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

ПР

Основной:

подвиг: реализовать скрипт репозитория `fork` #3

болтун опубликовано 31 декабря 2023 г.

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

Внесены изменения

• Реализована основная функция forkRepository в скрипте; эта функция является основной экспортируемой функцией, выполняющей основную операцию вилки; он принимает экземпляр userOctokit (объект, аутентифицированный пользователем с разрешением действовать от имени пользователя) и данные репозитория проекта, то есть объект repoDetails, и делает следующее...
  • Он проверяет, был ли репозиторий проекта уже разветвлен на учетную запись пользователя, с помощью вспомогательной функции isRepositoryForked; это возвращает вилку нуля
    • Если репозиторий уже был разветвлен, мы проверяем, является ли форк актуальным/синхронизированным с репозиторием основного проекта, используя вспомогательную функцию isRepositoryForkUpdated; это возвращает обновленный SHA и логическое свойство isUpdated, которые подтверждают, актуальна ли вилка.
      • Если форк не обновлен; затем мы выполняем обновление, синхронизируя его с основным репозиторием проекта, используя вспомогательную функцию updateRepositoryFork
    • Если репозиторий актуален/синхронизирован с основным репозиторием проекта; на этом этапе мы отменяем операцию с досрочным возвратом;
  • Если репозиторий проекта не разветвлен на учетную запись пользователя; затем мы переходим к инициированию процесса разветвления, вызывая конечную точку «POST /repos/{owner}/{repo}/forks» с использованием экземпляра userOctokit. (Это запускает процесс форка, мы не знаем точно, когда процесс завершится?)
• Реализуйте следующие вспомогательные функции, используемые в основной функции forkRepository, а также в других вспомогательных функциях.
  • updateRepositoryFork — используется для обновления (синхронизации) репозитория до состояния основного (головного) репозитория
  • isRepositoryForkUpdated — используется для проверки того, обновлен ли форк (синхронизирован с главным репозиторием) с основным репозиторием
  • getBranch — используется для получения сведений о ветке или ссылке
  • isRepositoryForked — используется для проверки наличия определенного репозитория в списке репозиториев ветки пользователя
• Добавлен getRepoParts в /lib/utils; это служебная функция, которая используется для разрешения repoOwner и repoName из полного имени репозитория.

Связанная проблема

Решение №2

Скринкаст/Снимок экрана

https://github.com/babblebey/jargons.dev/assets/25631971/16221b7e-3c28-4c6c-a1f3-24d583ce7e3a

?

Просмотреть на GitHub

подвиг: вернуть репозиторий `полное имя` в скрипте вилки #29

болтун опубликовано 4 апреля 2024 г.

Этот PR является продолжением отсутствующего шага в первоначальной реализации скрипта форка в #3; скрипту fork не удалось вернуть репозиторий, который можно использовать на следующем этапе вычислений. Это произошло из-за странного предположения, которое у меня было во время первоначальной реализации. ?См. мое предположение ниже...

Я предполагаю, что вызов конечной точки «POST /repos/{owner}/{repo}/forks» гарантирует только запуск процесса разветвления, вообще не гарантируя нам ответа. Это означает, что мы можем не получить ответ.данные после вызова

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

Внесены изменения

• Возвращенное репозиторий вилки — это значение полного имени репозитория, возвращаемое вспомогательной функцией isRepositoryForked; Настоящим я возвращаю его как основное возвращаемое значение при выполнении функции forkRepository в состоянии, когда репо уже разветвлено на исполняющей учетной записи пользователя
• Возвращённый ответ.data.full_name — это полное имя вновь созданного репозитория форка; Это значение из ответа на вызов конечной точки «POST /repos/{owner}/{repo}/forks»; Настоящим я возвращаю его как основное перенастроенное значение при выполнении функции forkRepository в тех случаях, когда в учетной записи исполняющего пользователя уже не было найдено форка
• Черри выбрала некоторые изменения из номера 25, чтобы использовать их здесь.
  • f12f25f548a5c5836e9be7d601ed226c5269f5ee
  • 436ceea649b67812c0ec1164fde95d443ce556e0

?

Просмотреть на GitHub