Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

slow repeated publishing due to Contents Indexes generation

オープン
  • 何か問題がありますか？
#1,446 コメント 5 件 リアクション 0 件 担当者 1 名 GitHub で見る

@neolynx がすでに取り組んでいます。

2025年5月1日 から。

評価

この issue はまだ評価されていません。

説明

bug

We use aptly v1.6.1.

We have debian packages that contain thousends of files >30'000 files per package. We have a repo that has dozens of those packages.

When using aptly publish update or aptly publish switch aptly generates the Contents Indexes. Which is the mapping of all the files in a debian package to the debian package name.

According to this issue https://github.com/aptly-dev/aptly/issues/599 there should be some kind of caching mechanism in place. Such that already indexed packages are not indexed again. But this doesn't seem to work, as repeated publishing without any changes to the repo takes always about 6min on a 4-core AWS machine. Now, if we use -skip-contents it speeds up the publishing to about 700ms. Which means it must be the Contents Indexes generation.

My question is, does the caching really work, or did I misunderstand somthing about the caching described in https://github.com/aptly-dev/aptly/issues/599? Could it be that the caching is broken? Or at least broken for debian packages with >30'000 files?

We publish to local storage (not S3).

We also have "normal" repos with thouseds of "normal" debian packages, where the packages do not have so many files. And for those repos the publishing is within seconds.

主要言語
Go
スター
2.9k
フォーク
436
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

aptly-dev/aptly のほかの issue

aptly-dev/aptly の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。