Это настоящий вебхук GitHub?

Нет. Это один статичный коммит с вашего мок-URL, без заголовка X-Hub-Signature-256, без sender, head_commit и compare URL, которые несёт реальное push-событие.

Как протестировать пуш в другую ветку?

Поменяйте ref в теле ответа — например, на refs/heads/release. Фильтрация по ветке — самая частая логика в обработчике пушей и самая лёгкая, чтобы ошибиться.

Подойдёт ли он для событий тегов или удаления?

Только если отредактировать тело — у них другая форма. Для обработчика, который разветвляется по типу события, заведите отдельный мок на каждое событие, чтобы у каждого случая был свой стабильный URL.

Замокать push-вебхук GitHub

GET-мок в духе push-события GitHub: один коммит в refs/heads/main.

Шаблон отдаёт push-событие в форме GitHub с одним коммитом в refs/heads/main, чтобы можно было разрабатывать триггер CI или обработчик бота, не пушая в настоящий репозиторий. В нём есть поля, на которых обработчики реально ветвятся — ref, after и имя репозитория, — и нет заголовка подписи, так что проверяется разбор, а не верификация.

Отдаёт готовое событие — скормите его прямо своему обработчику.

Тело ответа

{
  "ref": "refs/heads/main",
  "before": "a10867b14bb761a232cd80139fbd4c0d33264240",
  "after": "b7e1a2c3d4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9",
  "repository": {
    "full_name": "octocat/quickmock-demo"
  },
  "pusher": {
    "name": "octocat"
  },
  "commits": [
    {
      "id": "b7e1a2c3d4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9",
      "message": "fix: handle empty payload",
      "timestamp": "2024-05-01T12:00:00Z"
    }
  ]
}

Поля, на которые стоит обратить внимание

Поле	Что означает
ref	Ветка, в которую был push, например refs/heads/main.
after	SHA коммита после push — на него ссылаются в дальнейших вызовах API GitHub.
repository.full_name	Имя репозитория в формате owner/repo; поправьте под свой тестовый репозиторий.
pusher.name	Логин пользователя GitHub, который сделал push.
commits	Коммиты, входящие в этот push — здесь урезано до одного.

Создать мок

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "GET",
  "response_status": 200,
  "content_type": "application/json",
  "response_body": "{\"ref\":\"refs/heads/main\",\"before\":\"a10867b14bb761a232cd80139fbd4c0d33264240\",\"after\":\"b7e1a2c3d4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9\",\"repository\":{\"full_name\":\"octocat/quickmock-demo\"},\"pusher\":{\"name\":\"octocat\"},\"commits\":[{\"id\":\"b7e1a2c3d4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9\",\"message\":\"fix: handle empty payload\",\"timestamp\":\"2024-05-01T12:00:00Z\"}]}"
}'

Вызвать

curl https://quickmock.dev/m/<slug>

Что вы получите

GET /m/<slug> -> 200 a GitHub-style push event
one commit on refs/heads/main

Чем это отличается от настоящего

Это один статичный коммит вместо полного набора полей настоящего push-события — без заголовка X-Hub-Signature-256, без sender и head_commit, без ссылки compare.

Источники

Частые вопросы

Это настоящий вебхук GitHub?: Нет. Это один статичный коммит с вашего мок-URL, без заголовка X-Hub-Signature-256, без sender, head_commit и compare URL, которые несёт реальное push-событие.
Как протестировать пуш в другую ветку?: Поменяйте ref в теле ответа — например, на refs/heads/release. Фильтрация по ветке — самая частая логика в обработчике пушей и самая лёгкая, чтобы ошибиться.
Подойдёт ли он для событий тегов или удаления?: Только если отредактировать тело — у них другая форма. Для обработчика, который разветвляется по типу события, заведите отдельный мок на каждое событие, чтобы у каждого случая был свой стабильный URL.

Готовы попробовать?

Открыть в конструкторе моков и сначала поправить

Хорошо сочетается с гайдом: Протестировать приём вебхуков