В уведомлениях GitHub как мне отфильтровать по состоянию слияния?

Вопрос или проблема

Ответ или решение

Вопрос о том, как в GitHub фильтровать уведомления на основе факторов, таких как "is:unread" с параметром "isMerged", является достаточно актуальным, особенно для разработчиков, активно использующих эту платформу для совместной работы над проектами.

Теория:

GitHub предоставляет мощные возможности для управления уведомлениями, обеспечивая разработчиков и команды всех уровней удобным инструментом для отслеживания изменений в репозиториях. Обычно уведомления в GitHub касаются различных событий: открытие нового pull request, закрытие issues, комментарии и, конечно же, слияния (merge) pull requests. Эти события можно настраивать и фильтровать по множеству параметров, таких как "is:unread" (непрочитанные) или "is:open" (открытые).

Однако, что касается специфичного фильтрации уведомлений на основании состояния "isMerged" (то есть, был ли pull request слит в основной код), то данная функция на момент текущей документации GitHub не представлена как доступный параметр для прямого использования в интерфейсе уведомлений.

Пример:

Рассмотрим типичную ситуацию, когда замотивированная команда разработчиков интегрировала процесс code review в свой рабочий процесс. Pull requests создаются ежедневно, и большая часть команды заинтересована именно в тех запросах, которые завершились успешным слиянием, особенно в нечитаемых уведомлениях. Например, Джон, ведущий разработчик, хочет видеть только переписки по pull requests, которые были слиты и ранее помечены как нечитанные. На данный момент в стандартном интерфейсе GitHub он мог бы вручную просматривать уведомления, что неудобно, когда есть сотни новых уведомлений ежедневно.

Применение:

В условиях текущего функционала, один из путей решения этой задачи — использование GitHub API для создания персонализированных инструментов фильтрации. Существуют языки и библиотеки, такие как Python и requests библиотека, которые позволяют взаимодействовать с GitHub API:

1. Создание и настройка гитхаб токена для аутентификации запросов API.
2. Запросы к API GitHub, получающие данные по pull requests, включая их состояние (merged, не merged и т.д.).
3. Разработка скрипта или приложения, которое будет получать уведомления о pull requests и фильтровать их по нужным пользователю параметрам, например, "is:unread" и "isMerged".

import requests

def get_merged_pr_notifications(token):
    headers = {
        'Authorization': f'token {token}',
        'Accept': 'application/vnd.github.v3+json',
    }
    response = requests.get('https://api.github.com/notifications', headers=headers)

    if response.status_code == 200:
        notifications = response.json()
        merged_prs = []

        for notification in notifications:
            # Проверка конкретно на тип pull request и статус merged
            if notification['subject']['type'] == 'PullRequest':
                pr_data = requests.get(notification['subject']['url'], headers=headers).json()

                if pr_data.get('merged_at') is not None:
                    merged_prs.append(notification)

        return merged_prs

    else:
        print("Ошибка запроса к API")

Использование GitHub API позволит более полно управлять уведомлениями и внедрять кастомизированные решения, которые будут соответствовать необходимым критериям, таким как статус "isMerged".

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