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

Mirror release archives to S3 from the release workflow

オープン
#995 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
aws, github-actions, rust

調査の方向性

Start with .github/workflows/release.yml, AGENTS.md, and the referenced upstream ci/jobs/upload_clickhousectl.py and workflow sources; trace how the exact tagged release assets are produced and published. Done means all four archives are mirrored and integrity-verified before release announcement and npm publication, retries are safe, credentials are protected, and the upstream nightly job is retired after cutover.

索引モデルが issue の本文から書いたものです。

説明

bug good first issue

Problem

A new clickhousectl release can be advertised before its downloadable archives exist on builds.clickhouse.com. The CLI discovers new versions through GitHub Releases (including its background update notice), but clickhousectl update, the quick-install script, npm installation, and cargo-binstall download from the builds mirror. During the gap, users see an available update and then hit a missing download.

Today the main ClickHouse repository's NightlyUpload workflow runs daily at 06:13 UTC. Its Upload clickhousectl job discovers the latest GitHub release, copies missing assets to s3://clickhouse-builds/clickhousectl/, and skips objects already present. Most runs do nothing; a new release can wait until the next daily run.

Move ownership of that mirroring into this repository's release workflow so the same release run uploads and verifies the assets immediately. This is a scoped onboarding task for a new CLI engineer; the owner will select the assignee.

Existing implementation and consumers

The current contract is four .tar.gz archives, one each for x86_64-unknown-linux-musl, aarch64-unknown-linux-musl, x86_64-apple-darwin, and aarch64-apple-darwin. Preserve clickhousectl-{target}-{tag}.tar.gz and the existing internal archive layout. Public URLs are https://builds.clickhouse.com/clickhousectl/<archive-name>. Copy the release bytes; do not rebuild or repackage them. PyPI wheels are a separate output.

Work

  1. Adapt the existing uploader into this repo and integrate it with the release workflow for the exact tag being released, rather than discovering whichever release happens to be latest. Reuse the complete, smoke-tested artifact set from that run or its tagged GitHub release assets.
  2. Coordinate with the S3/infrastructure owner to obtain and configure upload credentials for this repository. Prefer an approved GitHub OIDC role if available, otherwise the approved release-secret mechanism. Scope access to the clickhousectl bucket prefix and use the appropriate protected release environment. The existing self-hosted runner's access must not be assumed to transfer to this repo. Record the owner/setup dependency; never place credential values in the issue or repository.
  3. Make publication ordering close the race: all expected public builds URLs must serve the matching archives before GitHub advertises the version as latest and before dependent package publication such as npm. A draft-release → upload/verify → publish sequence, or uploading the same workflow artifacts before public release creation, can achieve this. Simply adding a job after the current public release step leaves an update-availability window.
  4. Support safe retries and partial-upload recovery for a specific tag. Validate existing objects rather than silently accepting a mismatched archive. Report failures clearly and prevent publication from proceeding when mirroring/verification fails. Keep uploads restricted to valid release-tag runs; a manual workflow run on a branch must not upload branch-named artifacts.
  5. Coordinate cutover with the main ClickHouse repository: after the replacement is proven, retire its clickhousectl nightly upload job through the workflow's source/generation path. Preserve old release objects. Record both implementation and upstream cleanup PRs here.

Acceptance criteria

  • Approved S3 access is configured for this repository and its setup/ownership documented.
  • One release run automatically uploads all four exact archives to the existing S3 prefix; no daily poll or manual copy is required.
  • Each public builds.clickhouse.com URL is verified for availability and byte/content integrity before latest-release announcement and npm publication.
  • Missing assets, an upload failure, or a partially visible mirror prevents announcement/publication and produces an actionable job failure; rerunning the same tag safely completes recovery.
  • Focused checks cover complete uploads, missing assets, retry/existing-object behavior and workflow ordering. A controlled end-to-end release verifies CLI update/quick-install and npm download paths immediately after publication.
  • New Actions dependencies use SHA pins and upload credentials are unavailable to untrusted PRs/non-release runs, following AGENTS.md.
  • The upstream nightly uploader is retired after successful cutover, and the release workflow documentation is updated.

Milestone: v0.5.1. Follow-up tracker: #939. No credential provisioning or workflow implementation is performed by raising this issue.

主要言語
Rust
スター
80
フォーク
9
平均マージ
4日 13時間
マージ済み PR(30日)
59

環境構築

はじめの一歩

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

ClickHouse/clickhousectl のほかの issue

ClickHouse/clickhousectl の issue をすべて見る

似ている issue

Rust の issue をもっと見る

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

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