Виправлення PR оновлення refcache

Виконайте ці кроки, щоб вирішити проблему з невирішеними записами, що не належать до кодів 2XX, у static/refcache.json у цільовому PR otelbot. Цей процес може включати оновлення або видалення недійсних посилань на сайті, а потім повторне оновлення кешу посилань, поки не залишиться жодного запису, що не належить до кодів 2XX.

Цільовий PR

Якщо не вказано інше, цільовим є PR для upstream гілки otelbot/refcache-refresh. Якщо потрібно виправити гілку інтеграції spec або semconv, цільовим є відкритий PR, чия головна гілка відповідає otelbot/spec-integration-* або otelbot/semconv-integration-*, відповідно. Якщо збігається більше ніж один PR, запитайте, який саме мається на увазі. Щоб перелічити відкриті PR otelbot:

gh pr list --search head:otelbot/

У кроках нижче TARGET_BRANCH — це головна гілка цільового PR.

Підготовка

Ці кроки передбачають, що у вас є локальна копія репозиторію з налаштованим віддаленим репозиторієм upstream, який вказує на основний репозиторій. Виконуйте ці кроки локально з кореня репозиторію.

1. Визначте PR, повʼязаний з upstream TARGET_BRANCH.

2. Якщо жодного не існує, зупиніться.

3. Якщо локальна гілка TARGET_BRANCH вже існує і містить коміти, яких немає в upstream гілці, зробіть їх резервну копію або зупиніться перед скиданням будь-яких змін.

4. Перейдіть на гілку PR за допомогою gh pr checkout <num>. Якщо це не вдається через те, що локальна гілка розійшлася і ви вже зробили резервну копію будь-яких локальних комітів, вирівняйте її з upstream:

   git fetch upstream
   git checkout TARGET_BRANCH
   git reset --hard upstream/TARGET_BRANCH
   

5. Якщо будь-які модулі контенту застаріли, запустіть npm run get:submodule.

Обробка відповідей 5XX

Статус 5XX зазвичай є тимчасовим. Якщо static/refcache.json або ./scripts/double-check-refcache-4XX.mjs (нижче) повідомляє про статус 5XX для URL, вважайте його ймовірно тимчасовим (сервер недоступний, помилки шлюзу, перевантаження). Не змінюйте вміст сайту або посилання лише для обходу 5XX; краще повторно запустити скрипт подвійної перевірки (з --retry-404, якщо це корисно) або npm run fix:refcache пізніше. Досліджуйте 5XX як реальний дефект лише якщо він продовжує виникати протягом кількох запусків і ви підтвердили, що URL в іншому випадку не працює.

Розвʼязання записів, що не належать до кодів 2XX

1. Запустіть ./scripts/double-check-refcache-4XX.mjs --retry-404, щоб повторно отримати URL-адреси, які все ще кешуються як 4XX, та фрагментовані URL-адреси, позначені як INVALID FRAGMENT, а потім оновіть static/refcache.json. Див. примітку про LinkedIn нижче.

2. Перевірте static/refcache.json на наявність залишкових статусів, що не належать до кодів 2XX.

3. Якщо жодного не залишилося, тобто скрипт подвійної перевірки успішний:

   • Поділіться підсумком подвійної перевірки: у вашій відповіді або коментарі до PR (повторно отримані URL-адреси, оновлені записи, остаточні підрахунки HTTP-статусів та “Оброблено N URL-адрес”, коли показано).
   • Якщо static/refcache.json змінився, зафіксуйте зміни та надішліть їх до upstream TARGET_BRANCH (на цьому етапі).
   • Тільки для otelbot/refcache-refresh — PR гілок інтеграції залишаються чернетками, поки їх робочий процес не завершить їх у момент релізу:
     • Позначте PR як готовий до перегляду: gh pr ready <num>.
     • Увімкніть автоматичне злиття, щоб PR був об’єднаний після отримання всіх схвалень і проходження перевірок: gh pr merge <num> --auto.
     • Нагадайте підтримувачу схвалити PR, щоб автоматичне злиття могло завершитися. Надішліть посилання на PR: https://github.com/open-telemetry/opentelemetry.io/pull/<num>.

   Потім зупиніться, якщо ви також не залишаєте нотатки для рецензентів.

4. Інакше (якщо після кроку 2 залишилися записи, що не належать до кодів 2XX), перераховуйте залишкові URL-адреси та їх статуси:

   jq -r 'to_entries[] | select(.value.StatusCode < 200 or .value.StatusCode >= 300) | "\(.key) \(.value.StatusCode)"' \
     static/refcache.json
   

   URL LinkedIn

   Відповіді з LinkedIn.com часто ненадійні (агенти та боти можуть бачити 403 або 404 навіть тоді, коли профілі існують). Не видаляйте та не редагуйте посилання LinkedIn 4XX, натомість дозвольте підтримувачу вручну запустити ./scripts/double-check-refcache-4XX.mjs --retry-404 локально спочатку.

5. Аналіз та рекомендації. Для кожного URL з попереднього кроку створіть нумерований або маркований список, який включає принаймні:

   • URL та HTTP-статус.
   • Звідки він походить: надайте посилання на файли або сторінки.
   • Рекомендацію. Для посилань на github.com рекомендуйте заміну посилання на основі останнього коміту, що містить зазначений ресурс.
   • Для гілки інтеграції: де належить виправлення — у гілці, окремому PR проти main або upstream у репозиторії специфікації.

   Зачекайте відгуку від рецензента.

6. Застосування затверджених виправлень. Після затвердження редагуйте запропоновані джерела:

   • Для 404, оновіть або видаліть посилання, де ви його виявили.
   • Для інших статусів, що не належать до кодів 2XX, застосуйте переглянуту рекомендацію (може знадобитися ручна перевірка для неоднозначних випадків).
   • Якщо будь-яка змінена сторінка знаходиться поза content/en/, дотримуйтесь рекомендацій зі сторінки Локалізація для цього редагування (наприклад, # patched на default_lang_commit).

7. Запустіть npm run fix:refcache, щоб оновити static/refcache.json після цих змін джерел посилань, а потім повторіть кроки в цьому розділі (з кроку 1), поки не залишиться статусів, що не належать до кодів 2XX.