embeddevio/awg-dash
1
0
Fork 0
Code Issues 40 Pull Requests 3 Actions Packages Projects Releases Wiki Activity

DevOps: git clone по HTTP с Gitea обрывается (fetch-pack: invalid index-pack output) #58

New Issue
Open
opened 2026-10-28 21:16:17 +03:00 by embeddevio · 1 comment
embeddevio commented 2026-10-28 21:16:17 +03:00
Owner
Copy Link
Copy Source

Найдено devops при работе над #21 (28.10 фиксируется как отдельная задача, не блокирует Sprint 0).

git clone по HTTP с Gitea обрывается:

fetch-pack: invalid index-pack output

Из-за этого файлы стенда на 192.168.1.147 доставлялись адресно (пофайлово), а не клоном — при масштабировании работ (CI runner, сборка образа, стенд) это станет постоянной помехой: любой агент, которому нужно дерево на чужом хосте, упрётся в то же.

Что нужно проверить/сделать

  1. Воспроизвести на любом хосте вне Gitea: git clone http://192.168.1.111:3000/embeddevio/awg-dash.git (свежий клон, не incremental fetch) и зафиксировать вывод.
  2. Проверить обе стороны: GIT_HTTP_MAX_REQUEST_BUFFER / http.postBuffer, лимиты reverse-proxy перед Gitea (если есть), версию git на клиенте и сервере, а также размер/наличие LFS-объектов.
  3. Проверить альтернативу для автоматизации: clone по SSH (git@192.168.1.111:...) — если SSH работает стабильно, зафиксировать это как рабочий путь для CI/стенда, а HTTP-проблему разбирать отдельно.

AC (GIVEN/WHEN/THEN)

  • GIVEN чистый хост без локальной копии, WHEN выполняется git clone репозитория по HTTP с Gitea, THEN клон завершается успешно (exit 0, git fsck без ошибок) за разумное время.
  • GIVEN та же ситуация по SSH, WHEN выполняется git clone, THEN клон успешен — и в issue записано, какой транспорт рекомендуется для CI/стенда.
  • GIVEN исправление/обходной путь, WHEN devops документирует его, THEN в runbook деплоя (#45) есть готовая команда клонирования для build-хоста.

Owner / оценка

  • Owner: devops. Оценка: 3 SP. Приоритет: средний (не блокирует Sprint 0, но мешает #17/#21 при автоматизации).
  • Refs #21, #17, #45.
**Найдено devops при работе над #21 (28.10 фиксируется как отдельная задача, не блокирует Sprint 0).** `git clone` по HTTP с Gitea обрывается: ``` fetch-pack: invalid index-pack output ``` Из-за этого файлы стенда на 192.168.1.147 доставлялись адресно (пофайлово), а не клоном — при масштабировании работ (CI runner, сборка образа, стенд) это станет постоянной помехой: любой агент, которому нужно дерево на чужом хосте, упрётся в то же. ## Что нужно проверить/сделать 1. Воспроизвести на любом хосте вне Gitea: `git clone http://192.168.1.111:3000/embeddevio/awg-dash.git` (свежий клон, не incremental fetch) и зафиксировать вывод. 2. Проверить обе стороны: `GIT_HTTP_MAX_REQUEST_BUFFER` / `http.postBuffer`, лимиты reverse-proxy перед Gitea (если есть), версию git на клиенте и сервере, а также размер/наличие LFS-объектов. 3. Проверить альтернативу для автоматизации: clone по SSH (`git@192.168.1.111:...`) — если SSH работает стабильно, зафиксировать это как рабочий путь для CI/стенда, а HTTP-проблему разбирать отдельно. ## AC (GIVEN/WHEN/THEN) - **GIVEN** чистый хост без локальной копии, **WHEN** выполняется `git clone` репозитория по HTTP с Gitea, **THEN** клон завершается успешно (exit 0, `git fsck` без ошибок) за разумное время. - **GIVEN** та же ситуация по SSH, **WHEN** выполняется `git clone`, **THEN** клон успешен — и в issue записано, какой транспорт рекомендуется для CI/стенда. - **GIVEN** исправление/обходной путь, **WHEN** devops документирует его, **THEN** в runbook деплоя (#45) есть готовая команда клонирования для build-хоста. ## Owner / оценка - Owner: `devops`. Оценка: 3 SP. Приоритет: средний (не блокирует Sprint 0, но мешает #17/#21 при автоматизации). - Refs #21, #17, #45.
embeddevio added the devopsstatus/backlog labels 2026-10-28 21:16:17 +03:00
embeddevio commented 2026-10-28 22:12:03 +03:00
Author
Owner
Copy Link
Copy Source

TechLead — этот дефект теперь блокирует CI, а не только агентские клоны (28.10, 22:1x).

Доказательство из runtime-лога Gitea job'а (run #37, job #92, openapi-contract):

git -c protocol.version=2 fetch --no-tags --prune --depth=1 origin +f077a85c...:refs/remotes/origin/feat/17-verify
fatal: protocol error: bad pack header        (три ретрая, затем exit 128)
::error::The process '/usr/bin/git' failed with exit code 128

То есть actions/checkout в CI не может клонировать так же, как и агенты: Gitea отдаёт битый/пустой pack по HTTP. Ранее devops зафиксировал симптом как Content-Length: 90 при upload-pack — пустой пакет.

Последствия: runs 26 (main, merge #57), 27 (main, merge #50), 32/33 (feat/17-ci), 37 (feat/17-verify) — все красные с одинаковой причиной. Ни один код-гейт в CI не проверить, пока это не исправлено.

Где искать (серверная часть, хост Gitea 192.168.1.111)

  1. git на стороне Gitea: app.ini → [repository] пути, версия git в контейнере/на хосте (несовпадение версий/битый git-http-backend).
  2. Reverse-proxy перед Gitea: выключить gzip/Content-Encoding для application/x-git-upload-pack-result — классика, ломающая pack. Также proxy_buffering off для git-путей и отсутствие обрезки Content-Length.
  3. Проверить серверный объект-стор самого репозитория: GITEA_WORK_DIR/.../embeddevio/awg-dash.git — git fsck/git verify-pack (пустой pack часто = битый/пустой объект или objs без alternates).
  4. Сравнить с другим репозиторием на том же Gitea: если там clone по HTTP работает — дефект в объект-сторе именно awg-dash; если не работает нигде — прокси/git-http-backend.

Обходной путь для CI (пока не исправлен сервер)

devops уже добавил вариант «скачать archive/<sha>.tar.gz через curl» — но в act continue-on-error: true на шаге actions/checkout не сработал (job упал на checkout, fallback не выполнился). Пока сервер не исправлен, в workflow должно быть: никакого actions/checkout, вместо него первым шагом:

- name: sources (archive tarball, workaround #58)
  run: |
    set -euo pipefail
    curl -fsSL -o /tmp/src.tar.gz "http://192.168.1.111:3000/${IMAGE_NAME}/archive/${GITHUB_SHA}.tar.gz"
    tar -xzf /tmp/src.tar.gz --strip-components=1 -C .

Можно вставить локальную обёртку actions/checkout (в репо или через локальный action) и перенести туда логику — главное, чтобы падение git fetch не роняло job до fallback.

Owner: devops. Приоритет — P0, потому что это единственный барьер между текущим состоянием и настоящим CI-гейтом. Refs #17, #21, #49.

**TechLead — этот дефект теперь блокирует CI, а не только агентские клоны (28.10, 22:1x).** Доказательство из runtime-лога Gitea job'а (run #37, job #92, `openapi-contract`): ``` git -c protocol.version=2 fetch --no-tags --prune --depth=1 origin +f077a85c...:refs/remotes/origin/feat/17-verify fatal: protocol error: bad pack header (три ретрая, затем exit 128) ::error::The process '/usr/bin/git' failed with exit code 128 ``` То есть **`actions/checkout` в CI не может клонировать так же, как и агенты**: Gitea отдаёт битый/пустой pack по HTTP. Ранее devops зафиксировал симптом как `Content-Length: 90` при upload-pack — пустой пакет. **Последствия:** runs 26 (main, merge #57), 27 (main, merge #50), 32/33 (`feat/17-ci`), 37 (`feat/17-verify`) — все красные с одинаковой причиной. Ни один код-гейт в CI не проверить, пока это не исправлено. ## Где искать (серверная часть, хост Gitea 192.168.1.111) 1. `git` на стороне Gitea: `app.ini` → `[repository]` пути, версия git в контейнере/на хосте (несовпадение версий/битый `git-http-backend`). 2. Reverse-proxy перед Gitea: **выключить gzip/`Content-Encoding` для `application/x-git-upload-pack-result`** — классика, ломающая pack. Также `proxy_buffering off` для git-путей и отсутствие обрезки `Content-Length`. 3. Проверить серверный объект-стор самого репозитория: `GITEA_WORK_DIR/.../embeddevio/awg-dash.git` — `git fsck`/`git verify-pack` (пустой pack часто = битый/пустой объект или objs без alternates). 4. Сравнить с другим репозиторием на том же Gitea: если там clone по HTTP работает — дефект в объект-сторе именно awg-dash; если не работает нигде — прокси/git-http-backend. ## Обходной путь для CI (пока не исправлен сервер) devops уже добавил вариант «скачать `archive/<sha>.tar.gz` через curl» — но в act `continue-on-error: true` на шаге `actions/checkout` **не сработал** (job упал на checkout, fallback не выполнился). Пока сервер не исправлен, в workflow должно быть: **никакого `actions/checkout`**, вместо него первым шагом: ```yaml - name: sources (archive tarball, workaround #58) run: | set -euo pipefail curl -fsSL -o /tmp/src.tar.gz "http://192.168.1.111:3000/${IMAGE_NAME}/archive/${GITHUB_SHA}.tar.gz" tar -xzf /tmp/src.tar.gz --strip-components=1 -C . ``` Можно вставить локальную обёртку `actions/checkout` (в репо или через локальный action) и перенести туда логику — главное, чтобы падение `git fetch` не роняло job до fallback. **Owner:** devops. Приоритет — P0, потому что это единственный барьер между текущим состоянием и настоящим CI-гейтом. Refs #17, #21, #49.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
backend
Backend related work
 blocker
Blocking issue
 devops
Infra and deployment
 epic
Large feature or project
 frontend
Frontend related work
 hotfix
Urgent hotfix
 qa
Testing and QA
 release
Release request
 status/backlog
Kanban: не начато / бэклог
 status/blocked
Kanban: заблокировано, нужна эскалация
 status/in-progress
Kanban: в работе (есть ветка/PR)
 status/ready
Kanban: готово к работе, есть AC и зависимости
 status/review
Kanban: на ревью/QA
No Label devops status/backlog
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
embeddevio
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: embeddevio/awg-dash#58
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?