Тестирование Pull Requests

Последнее обновление Mar 3rd, 2021 | История страницы | Улучшить эту страницу | Сообщить о проблеме

Support the team building MODX with a monthly donation.

The budget raised through OpenCollective is transparent, including payouts, and any contributor can apply to be paid for their work on MODX.

Backers

Budget

$301 per month—let's make that $500!

Learn more

Участники по всему миру всегда создают новые pull-requests с исправлениями ошибок, новыми функциями и другими улучшениями.

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

К счастью, вы можете с этим помочь!

Проверяя pull-requests и сообщая о своих отзывах, вы помогаете интеграторам дать уверенность, необходимую для принятия изменений. Или вы можете просто найти проблему с предложением, которую участник должен сначала исправить, что не менее полезно.

В этом руководстве объясняется, как вы можете помочь в тестировании pull-requests. Также полезно ознакомиться с руководством для участников, в котором объясняется процесс, через который участник создает pull-request.

1. Найдите открытый pull-request¶

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

Почти все запросы на вытягивание помечаются тегом pr-state. Наиболее полезно сосредоточиться на тех, которые помечены как pr-state/review-required, так как они еще не прошли официальную проверку.

2. Прочтите - о чем это?¶

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

Прежде чем тестировать изменение, попробуйте воспроизвести проблему в соответствующей ветке выпуска, особенно для исправления ошибок. Это гарантирует, что вы понимаете, как воспроизвести и подтвердить, что pull-request действительно решает проблему.

(Более подробную информацию о различных ветвях выпуска можно найти в руководстве для участников)

Если вы не можете воспроизвести ошибку на основе предоставленной информации, спросите либо в исходной проблеме, либо в pull-request, как вы можете помочь ее протестировать.

Во время событий в реальном времени, таких как охота за ошибками (Bughunt), полезно (а иногда необходимо набирать очки) комментировать pull-request, чтобы «забрать» его и набрать очки, но в этом нет необходимости, если вы просто делаете доброе дело в течение дня.

3. Запустить запрос на перенос локально¶

Чтобы протестировать pull-request, вам нужно будет внести в локальная разработка сайта MODX предложенные изменения.

Самый простой способ сделать это - использовать GitHub CLI "gh". На локальном сайте разработки запустите команду gh pr checkout <id of pull request>, например gh pr checkout 12345. Это мгновенно загрузит код из pull-request.

Команда checkout не выполняет автоматическую перебазировку или объединение изменений, поэтому вам нужно сделать это, чтобы обнаружить конфликты с недавними изменениями:

git rebase upstream/2.x

Замените 2.x соответствующей базовой веткой.

Альтернатива без GitHub CLI: PR ветки¶

Используя текстовый редактор или терминал, отредактируйте файл .git/config в вашем репозитории. Для примера используйте nano .git/config из корня вашей локальной копии MODX.

Найдите [remote "upstream"] секцию (или [remote "origin"] если у вас нет отдельного upstream remote). Должно получиться так:

[remote "upstream"]
        url = [email protected]:modxcms/revolution.git
        fetch = +refs/heads/*:refs/remotes/upstream/*

Добавьте в выборку еще одну строку - обратите внимание на отступ.

[remote "upstream"]
        url = [email protected]:modxcms/revolution.git
        fetch = +refs/heads/*:refs/remotes/upstream/*
        fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*

(Если у вас нет upstream remote, замените его на origin.)

Теперь, когда вы это сделаете git fetch upstream или git pull upstream, вы получите специальные ветки для каждого pull request.

$ git fetch upstream
remote: Enumerating objects: 279, done.
remote: Counting objects: 100% (279/279), done.
remote: Total 355 (delta 278), reused 279 (delta 278), pack-reused 76
Receiving objects: 100% (355/355), 74.90 KiB | 6.81 MiB/s, done.
Resolving deltas: 100% (285/285), completed with 181 local objects.
From github.com:modxcms/revolution
   ab0da3bcf..73a5a8df3  2.x                  -> upstream/2.x
   dc184c801..bea16ac43  3.x                  -> upstream/3.x
   a4e22026b..558369bc5  refs/pull/14860/head -> upstream/pr/14860
 * [new ref]             refs/pull/14888/head -> upstream/pr/14888
 * [new ref]             refs/pull/14889/head -> upstream/pr/14889
 * [new ref]             refs/pull/14890/head -> upstream/pr/14890
...

При первом запуске он будет включать так называемую «ref» для каждого когда-либо созданного pull request. Это длинный список, который может занять минуту, но изменения будут извлечены только при следующем запуске.

Имея специальные ветки, теперь вы можете checkout или объединить их напрямую с Git.

В приведенных ниже командах замените name-of-branch либо с именем ветви pull request, созданным автором pull request (показано в верхней части представления pull request), либо со специальным upstream/pr/<id-of-pr> ref если вы использовали уловку, чтобы получить pull requests.

Преимущество использования git checkout в том, что вы загружаете определенную версию, которая уже существует, так что это проще. Вы можете оформить заказ с помощью:

git checkout name-of-branch

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

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

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

Чтобы объединить pull request локально, выполните:

git merge --no-ff --no-commit name-of-branch

В идеале вы увидите, что слияние прошло успешно («Automatic merge went well; stopped before committing as requested"), но на этом этапе можно столкнуться с ошибками.

Если вы видите сообщение error: Your local changes to the following files would be overwritten by merge:, у вас есть локальные незафиксированные изменения. Вы можете спрятать любые изменения, которые вы хотите сохранить, или выполните полный сброс, чтобы отменить все изменения с помощью git reset --hard upstream/2.x (замените 2.x с веткой версии, которую вы используете) и/или git checkout -- . - затем снова запустите команду слияния.
Если сообщение сообщает о конфликтах слияния, git попытался применить изменения из запроса на перенос, но не смог определить, как следует применить конфликтующие изменения. Сообщение должно указать вам на конкретные файлы: там вы найдете блоки дублированного кода, которые вам нужно будет исправить вручную.

На этом этапе вы запускаете предложенное изменение. Ура!

4. Выполнение шагов сборки и обновление кешей¶

В зависимости от pull request и того, что он изменился, вам может потребоваться выполнить одно (или несколько) из следующих действий, прежде чем вы сможете протестировать:

Запустите скрипт сборки ядра, с последующим прохождением установки
Запустите рабочий процесс сборки ресурсов
Очистить кеш браузера
Очистить кеш MODX
(MODX3) Запустите composer install, composer update, или composer dump-autoload для измененных зависимостей или других composer.json изменений.

5. Тестирование pull requests¶

Теперь вернитесь к pull request и проблемам, чтобы определить, как лучше всего протестировать изменения.

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

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

Если вас устраивает код, использованный при изменении (обычно PHP, JavaScript или Sass / CSS), вы также можете провести ревью кода.

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

6. Сообщите о своих выводах¶

Все вышеперечисленное бессмысленно, если вы не поделитесь своими результатами с сообществом, так что теперь пора поделиться!

Ошибка еще не исправлена?
А нужно ли что-то делать по-другому? (Не забудьте объяснить почему.)
Или работает именно так, как рекламируется?

Ответьте на pull request тем, что вы нашли.

7. Очистите локальную установку¶

Когда вы закончите тестирование, вы захотите восстановить локальную установку MODX в официальную ветку версии.

Если вы использовали подход git checkout, вы можете просто снова проверить ветку версии с помощью git checkout 2.x - если вам нужно было выполнить какие-либо шаги сборки, вам может потребоваться отменить эти изменения с помощью git reset - hard name-of-branch, прежде чем вы сможете оформить заказ.
Если вы использовали подход git merge, вы можете отменить слияние и вернуть все шаги сборки с помощью git reset --hard upstream / 2.x

Нужна помощь?¶

Если вы пытаетесь протестировать pull request, но застреваете, не забудьте попросить о помощи. Ваше тестирование очень ценно, и если мы сможем заставить вас работать, это будет лучше для всех.

Получите помощь в MODX Community Slack #development или в MODX Community Forums.