本文へ移動
cccskills
無料GitHub で公開日本語紹介

release-and-versioning

VERSIONの確認からリリース準備、成果物の版管理、GoReleaserによるパッケージ作成と公開までを扱うスキルです。

原文原文の説明を見る

Maintain VERSION, release notes, release targets, versioned artifacts, GoReleaser packaging, and publication. Use for release-note drafts, release preparation, version checks, and explicitly requested releases; dependency refresh is separate.

greenpau/caddy-securityスター 2,270(GitHub 2,270 + cccskills 0)

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • リリース前に版番号とタグを確認したいとき
  • パッチ・マイナー更新を準備したいとき
  • 成果物がどの版に対応するか調べたいとき
  • GoReleaserやCIの公開手順を確認したいとき

日本語での紹介

できること

リポジトリのVERSIONを基準に、版番号の検証、成果物IDの確認、リリースターゲットの選択、GoReleaserによるパッケージ作成と公開の流れを扱います。VERSION、Gitタグ、READMEのダウンロードリンク、認証コマンドのバージョン表示、依存ライブラリの版がそれぞれ別の役割を持つことを整理し、どの値を確認すべきか案内します。パッチ版とマイナー版の更新、通常リリースとテストを省略する高速リリースの違い、CIや公開処理の前提も説明します。

こんなときに便利

リリース前に現在のブランチや作業ツリー、タグ、版番号の整合性を確認したいときに向いています。バージョンを上げるだけの依頼と、実際にコミット・タグ付け・公開する依頼を区別し、影響範囲を把握できます。GoReleaserの成果物やCIの検証内容を確認したい場合にも使えます。

使い方の例

  • 「現在のVERSIONとタグに矛盾がないか確認してください」
  • 「パッチリリースの手順と事前条件を整理してください」
  • 「この成果物IDがどの版とコミットに対応するか説明してください」

注意点

実際のリリースでは、mainブランチ、変更のない作業ツリー、意図したリモート、タグの未使用などが前提です。公開にはコミット、タグ付け、リモートへのpushが伴います。依存関係の更新は別の作業として扱います。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

含まれるファイル(4)

  • SKILL.md10.7 KB
  • agents/openai.yaml300 B
  • references/ci-and-packaging.md11.7 KB
  • references/final-qualification.md9.1 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Release and Versioning

Follow the repository scope. Version edits, dependency refreshes, commits, tags, and publication apply only to caddy-security. Read sibling versions/history as inputs; do not bump, sync, fetch into, tag, or release a sibling to unblock this module. Missing upstream releases are separate work. Keep chosen snapshot and report destinations here.

Version Authority

VERSION owns the caddy-security release number. Preserve the existing 1.<minor>.<patch> release line, with no v in the file and v<VERSION> for the Git tag. A feature change or dependency update alone does not request a version bump or publication. Read current values from the checkout instead of copying versions from examples or the sibling repository.

Keep these version surfaces distinct:

  • Makefile reads VERSION into PLUGIN_VERSION; release recipes read it again for the commit subject and annotated tag.
  • assets/scripts/generate_downloads.sh projects VERSION into README Caddy download URLs. It separately hard-codes the caddy-trace version. Verify its <!-- caddy-security-downloads --> marker occurs exactly once on its own line before regenerating links, and inspect their placement afterward. The visible download caption can change independently. Run bash assets/scripts/generate_downloads.sh --check to validate it without changing files; release preflight uses this same check before bumping. Missing or duplicate markers also stop direct generation before deleting existing links. The macOS branch requires gsed as well as BSD sed.
  • go.mod selects the go-authcrunch dependency version; ../go-authcrunch/VERSION is the sibling library's release number. Neither sets this module's version. make sync updates dependency references and removes local replacements; it is a separate dependency refresh, not caddy-security version synchronization.
  • cmd/authcrunch/main.go delegates to Caddy. It has no application version fallback declarations to synchronize. The Makefile does not inject its PLUGIN_VERSION with linker flags, so bin/authcrunch version alone does not establish this module's release identity.
  • bin/authcrunch security version reads the linked go-authcrunch module from embedded Go build metadata. It retains pseudo-versions and shows replacements, including (devel) for unversioned local paths. This is dependency identity, distinct from Caddy's version and this repository's release number; see security dependency version.
  • cmd/caddy-authenticator/main.go initializes *versioned.PackageManager with a literal fallback for ordinary go install builds. make build injects VERSION into main.appVersion; caddy-authenticator version prints its banner. GoReleaser builds separate platform archives and injects release/snapshot version, commit and build metadata; see CI and packaging. Keep the fallback synchronized using make version-sync after an explicit VERSION change. Sync validates VERSION first and changes only the existing fallback; it neither bumps the release nor stages files.

make version-check validates the fixed-major namespace through assets/scripts/version.py without rewriting files. It accepts a single optional trailing newline, rejects leading zeros and prerelease/build suffixes, and bounds components for versioned. check --tag additionally requires the exact v<VERSION> tag. It does not validate README link placement or contents. The check also rejects a missing, ambiguous or stale authenticator fallback; artifact identity validation enforces the same consistency without rewriting it.

make artifact-id validates the version and produces v<VERSION>_<UTC YYYYMMDDTHHMMSSZ>_<12-character SHA> for branch/PR/manual builds. An exact v<VERSION> tag produces v<VERSION>; another tag fails. GITHUB_SHA provides the checked CI revision (including PR merge commits), with local HEAD as fallback. Validated version and artifact_id values go to GITHUB_OUTPUT.

make release increments the patch; make minor-release increments the minor and resets the patch to zero. Both preserve the major release line. assets/scripts/version.py next --kind patch|minor computes the candidate without writing files and rejects an increment beyond the supported range. version-sync projects VERSION into the authenticator fallback only.

Existing Release Targets

Read the current Makefile before executing release operations. The targets have different side effects:

TargetActual behavior
make release-git-checkRead-only local check of main, a clean worktree/index including untracked files, and synchronized version values. Does not check the remote or run the quality gate.
make releaseRuns assets/scripts/release.sh patch for the complete checked patch release.
make minor-releaseRuns the same script with minor, resetting the patch to zero.
make fast-releaseRuns the patch workflow with --skip-tests, skipping local make ci-check.
make fast-minor-releaseRuns the minor workflow with --skip-tests, skipping local make ci-check.
make release-update-version, make release-git-commitFail with instructions to use a complete release target; partial publication paths are disabled.

The shared script serializes checks, bump, synchronization, download generation, make ci-check, commit, tag, and push even under parallel Make. It requires main with no tracked, staged, or untracked changes, fetches origin/main, rejects behind/diverged history and an existing candidate tag locally or on origin, and checks the README marker and macOS gsed prerequisite before bumping. The pinned go tool versioned command comes from go.mod; release operations do not depend on a globally installed versioned executable.

For regular releases, the gate runs once against the bumped version, including the binary build. Fast releases skip the entire local gate (automation tests, Go tests/reports, and build); GitHub release validation still runs before GoReleaser publication. All version/Git checks, synchronization, download generation, staging restrictions and atomic publication remain in place. Use a fast target only when the user requests it; release-git-check does not accept --skip-tests. Only VERSION, README.md, and cmd/caddy-authenticator/main.go are staged. Unexpected staged, other tracked, or untracked changes stop publication. The commit subject is ops: released v<VERSION> and the exact tag is annotated. One atomic push publishes HEAD:refs/heads/main and that tag to origin; unrelated local tags are excluded. There is no fallback to separate pushes.

Release Notes

When drafting or reviewing release notes, review both caddy-security commits and the go-authcrunch commits introduced by the dependency change. Derive the upstream endpoints from go.mod at the previous and target caddy-security revisions; the sibling checkout's HEAD or VERSION may describe a later release. Include relevant upstream commit links, distinguish Caddy integration from inherited runtime changes, and retain deployment and compatibility limits. Follow the release-note drafting workflow for endpoint selection, source review, citations, and draft validation.

Preparation and Publication

For a status check, start with read-only evidence: git status --short --untracked-files=all, git branch --show-current, git diff, git diff --cached, VERSION, and existing tags. make release-git-check adds the local preflight without modifying files. Release preparation can inspect and validate without executing a bump or publishing target.

For an actual release, carry forward the user's existing authorization and:

  1. Confirm the intended version, main checkout, clean index/worktree including untracked files, intended remote, remote branch state, and absence of the intended tag locally and remotely. Do not rely on stale remote-tracking refs or let unrelated staged changes enter the release commit.
  2. Verify dependencies resolve to the intended published versions. Resolve any local go-authcrunch replacement through the dependency refresh workflow before qualifying the release. Run make dep to resolve pinned tools and dependencies. Review any source changes before proceeding; validation itself must not rewrite them.
  3. Run the requested make release or make minor-release once. The script bumps, synchronizes projections, runs the complete gate, commits and tags the validated contents, and publishes the two explicit refs atomically. When a fast release is requested, use make fast-release or make fast-minor-release; only the local gate is skipped.
  4. Confirm the release commit, annotated tag, VERSION and intended publication refer to the same revision. Never force an existing release ref.

Only bump, tag, push, or dispatch a publishing workflow within the user's requested scope. A request to explain or port release guidance is not a request to execute a release. Do not ask again for actions already authorized.

If any step fails, inspect the worktree, index, release commit/tag, and remote refs before continuing. A transport failure can leave the outcome uncertain. Preserve that evidence and report the last completed step. Do not rerun the entire release, bump again, reset changes, delete tags, or retract a version as automatic recovery.

CI and Automation Validation

For release CI, artifact identity, dependency changelogs, toolchains, and packaging validation, read CI and packaging. It distinguishes the current workflow from release gates that would need implementation. For complete Caddy target builds, source/artifact vulnerability evidence, stripped-symbol limitations and unresolved official OP outcomes, use final integration qualification.

For automation changes, exercise success and failure paths in disposable repositories with local bare remotes. Include dirty/untracked state, wrong branch, an existing tag, unrelated local tags, failed validation, and rejected pushes as relevant to the change. Never test release automation by publishing this repository. For skill-only edits, validate skill metadata, links, and claims against source; no release, version bump, or Go build is needed.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

authentication-portal-api

無料概要あり

認証ポータルのログインやトークン更新、プロフィール、管理APIを利用するHTTPクライアントの仕様確認とトラブル対応を支援します。

  • ポータル向けJSONログインを実装したいとき
  • ブラウザーのトークン更新を調べたいとき
  • ネイティブ認証APIを扱いたいとき
greenpau/caddy-security2,2702026年10月28日 更新

break-fix-troubleshooting

無料概要あり

Caddyの認証・認可まわりで起きた設定や実行時の障害を、設定ファイル、ログ、バージョン、HTTPの証拠から切り分け、最小修正や調査報告にまとめます。

  • ログイン障害の原因を調べたいとき
  • OIDCやSAMLの失敗を切り分けたいとき
  • 最小限の設定修正を探したいとき
greenpau/caddy-security2,2702026年10月28日 更新

coding-directives

無料概要あり

caddy-securityのGoコードやCaddyモジュール、Caddyfileパーサー、HTTP連携の実装・レビューで、境界やライフサイクル、エラー処理の規約を確認するスキルです。

  • Caddyfileパーサーの変更をレビューしたいとき
  • CaddyモジュールやHTTP処理を実装したいとき
  • アプリの起動・終了処理を確認したいとき
greenpau/caddy-security2,2702026年10月28日 更新

configuration

無料概要あり

caddy-securityのCaddyfile全体を作成・点検し、認証方式に合う設定ガイドを選びながらsecurityアプリとHTTPルートを配線するスキルです。

  • Caddyfile全体を作成したいとき
  • 認証ポータルをルートに接続したいとき
  • 保護対象パスに認可ポリシーを設定したいとき
greenpau/caddy-security2,2702026年10月28日 更新

Caddyの認証ポータルとルートへの認証処理を設定し、利用するログイン元やリダイレクト先の信頼条件、更新機能などを組み立てるスキルです。

  • 認証ポータルを新しく構成したいとき
  • ログインに使うストアやプロバイダーを選びたいとき
  • 保護ルートをポータル認証につなぎたいとき
greenpau/caddy-security2,2702026年10月28日 更新

認証ポータルのCookie名や接頭辞、属性、ドメインを設定し、認可ポリシーが探すトークンCookieとの対応を整えます。

  • ポータルのCookie名を一括で変更したいとき
  • Cookie属性やドメインを調整したいとき
  • 更新トークン用Cookie名を上書きしたいとき
greenpau/caddy-security2,2702026年10月28日 更新

greenpau のスキルをすべて見る

このスキルの問題を報告する