upstream-patches

作成者: pulumi

Create, amend, remove, and rebase patches for Terraform provider submodules using `./scripts/upstream.sh`. Use when `upgrade-provider` or manual patch work…

npx skills add https://github.com/pulumi/agent-skills --skill upstream-patches

Upstream Patches

upstream/ is a git submodule pointing to the upstream Terraform provider. patches/ contains patch files applied on top of it. Use ./scripts/upstream.sh to manage patch state.

Default Behavior

  • If fixing a regression introduced by an existing patch, amend the owning patch commit.
  • Do not create a new patch unless the user explicitly asks.

Commands Reference

CommandDescription
./scripts/upstream.sh initInitialize upstream and apply patches to working directory
./scripts/upstream.sh init -fDestructively discard checkout/rebase state and re-initialize upstream
./scripts/upstream.sh checkoutCreate branch with patches as commits for editing
./scripts/upstream.sh rebase -iInteractively edit patch commits
./scripts/upstream.sh rebase -o <commit>Rebase patches onto a new upstream commit
./scripts/upstream.sh check_inWrite commits back to patches and exit checkout mode

Guardrails

  • Never commit directly to upstream/ without checkout/check_in.
  • Direct edits under upstream/ outside checkout are ephemeral during upgrade-provider; the tool resets submodule state.
  • Do not hand-edit patches/*.patch unless intentionally doing raw patch surgery.
  • Prefer non-interactive rewrite flow over interactive rebase for agents.

Find Owning Patch First

Before editing patch content, identify the owning patch/commit.

./scripts/upstream.sh checkout

# Find candidate patch files by touched file path or unique hunk text
rg -n "path/to/file|unique_symbol" patches/*.patch

# Optional: inspect candidate patch header/hunks
sed -n '1,120p' patches/00NN-Example.patch

# Map patch file to commit in upstream checkout branch
patch=patches/00NN-Example.patch
subject=$(sed -n 's/^Subject: \[PATCH\] //p' "$patch" | head -n1)
cd upstream
git log --oneline pulumi/patch-checkout --grep "$subject"

# If needed, disambiguate by touched path
git log --oneline pulumi/patch-checkout -- path/to/file
cd ..

If rg is unavailable, use grep -En for the patch search. Set target_sha to the owning commit and edit that commit, not HEAD.

Amend Existing Patch (Preferred, Non-Interactive)

./scripts/upstream.sh checkout
cd upstream

target_sha=<owning-commit-sha>
base_sha=$(git rev-parse "${target_sha}^")
tmp_branch="rewrite-${target_sha:0:8}"

# Rebuild history from parent of target commit
git checkout -b "$tmp_branch" "$base_sha"
git cherry-pick "$target_sha"

# Apply fix and amend target commit
# ...edit files...
git add <files>
git commit --amend --no-edit

# Replay remaining commits
git cherry-pick "${target_sha}..pulumi/patch-checkout"

# If cherry-pick conflicts occur:
#   resolve files
#   git add <resolved files>
#   git cherry-pick --continue

# Move checkout branch to rewritten history
git branch -f pulumi/patch-checkout HEAD
git checkout pulumi/patch-checkout
git branch -D "$tmp_branch"
cd ..

Interactive fallback:

./scripts/upstream.sh checkout
./scripts/upstream.sh rebase -i
# mark target commit as edit, amend, then continue

Remove Entire Patch

Use when a patch should be deleted completely.

rm patches/00NN-Description.patch
./scripts/upstream.sh checkout
./scripts/upstream.sh check_in

Remove Part of a Patch

Use when only selected hunks/files should be removed from an existing patch.

  1. Find owning patch/commit (target_sha) and use the amend workflow above.
  2. Revert only unwanted changes from the target commit, then amend.

Example during amend step:

cd upstream
# Restore specific docs-only files from parent of amended commit
git checkout HEAD^ -- path/to/docs-only-file path/to/another-doc-file
git add path/to/docs-only-file path/to/another-doc-file
git commit --amend --no-edit
cd ..

Create New Patch (Only If Requested)

./scripts/upstream.sh checkout
cd upstream
# ...make changes...
git add <files>
git commit -m "Describe new patch"
cd ..
./scripts/upstream.sh check_in

Rebasing Patches to a New Upstream Version

./scripts/upstream.sh checkout

# Rebase onto the new upstream commit
./scripts/upstream.sh rebase -o <new_commit_sha>
# Resolve any conflicts that arise

# Write updated patch files
./scripts/upstream.sh check_in

Verification Checklist

Before check_in:

  • Confirm expected patch count change (0 by default; -1 for full patch removal).
  • Confirm whether target patch should remain present (default yes) or be removed (explicit deletion case).
  • Confirm you are editing the owning commit, not adding a new commit by accident.

After check_in:

  • Verify patch count matches expectation.
  • Verify target patch number/purpose is still present when expected.
  • Verify no unexpected new 00NN-*.patch was introduced.

Interrupted Checkout or Rebase

Preserve work by default. Inspect git -C upstream status, complete the active git am/rebase, verify that every patch was applied, and run ./scripts/upstream.sh check_in before rerunning automation. An interrupted checkout invokes git am separately for each patch, so later patch files may not have been reached.

Use ./scripts/upstream.sh init -f only when intentionally discarding all interrupted work. It can remove conflict resolution, patch commits, operation metadata, and untracked files; it is not routine recovery for a stuck checkout.

pulumiのその他のスキル

package-usage
pulumi
Pulumi組織全体のスタックにおいて、特定のパッケージがどのバージョンで使用されているかを追跡します。クロススタック監査や、古くなった、またはメンテナンスされていないものを特定するために使用します…
official
pulumi-automation-api
pulumi
Pulumiインフラストラクチャ操作を複数のスタックやアプリケーションにわたってプログラム的にオーケストレーションします。ローカルソース(既存のPulumiプロジェクト)とインラインソース(埋め込みプログラム)の両方のアーキテクチャをサポートし、シンプルなものから複雑なマルチスタックシナリオまで柔軟なデプロイパターンを実現します。依存関係の順序付け、並行した独立デプロイ、スタック間の出力受け渡しによる調整されたインフラプロビジョニングを備えたマルチスタックオーケストレーションを処理します。プログラム的な...
official
pulumi-best-practices
pulumi
信頼性が高く保守しやすいPulumiインフラストラクチャコードを記述するための包括的なベストプラクティス。apply()コールバック内でリソースを作成せず、依存関係の追跡とプレビューの可視性を維持するためにOutputオブジェクトを直接入力として渡します。ComponentResourceクラスを使用して関連リソースを再利用可能な論理ユニットにグループ化し、parent: thisを介して適切な親子階層を設定します。--secretフラグまたはconfig.requireSecret()を使用して最初からシークレットを暗号化し、状態ファイルへの認証情報漏洩を防ぎます...
official
pulumi-component
pulumi
再利用可能なインフラストラクチャコンポーネントで、多言語サポート、適切なデフォルト設定、および構成パターンを備えています。4つのコア要素が必要です:ComponentResourceを拡張し、標準パラメータを受け入れ、すべての子にparent: thisを設定し、コンストラクタの最後にregisterOutputs()を呼び出します。ArgsインターフェースはInput<T>ラッパーを使用し、ユニオン型や関数を避け、構造をフラットに保つことで多言語SDK生成をサポートします。必須の出力のみをパブリックプロパティとして公開し、非表示にします...
official
pulumi-debug-failed-operation
pulumi
失敗したPulumiの更新またはプレビューをデバッグします:Pulumiが既に記録した失敗を読み取り、原因を特定して修正します。ユーザーが依頼したときにこのスキルを読み込んでください。
official
pulumi-esc
pulumi
Pulumiインフラストラクチャとアプリケーション向けの、集中管理されたシークレット、設定、動的認証情報管理。インポートとレイヤリングによる環境構成をサポートし、environmentVariables、pulumiConfig、files用の予約キーを備えています。OIDCを介してAWS、Azure、GCP向けの短期認証情報を生成し、AWS Secrets Manager、Azure Key Vault、HashiCorp Vault、1Passwordと統合します。コアCLIコマンドには、pulumi env init、pulumi env edit、pulumi env open(表示...)が含まれます。
official
pulumi-neo-handoff
pulumi
現在のスレッドを新しいPulumi Neoタスクに一方向で引き継ぎます。ユーザーが明示的に引き継ぎ、送信、転送、または現在の続行を依頼した場合に使用します…
official
pulumi-overview
pulumi
このスキルは、クラウドインフラストラクチャやSaaS構成を作成、変更、検査、または破棄するあらゆるタスクに使用します。単発のCLI操作から完全な…
official