upstream-patches
Create, amend, remove, and rebase patches for Terraform provider submodules using `./scripts/upstream.sh`. Use when `upgrade-provider` or manual patch work needs owning-patch lookup, patch conflict fixes, patch/hunk removal, or upstream rebase.
Resumen
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
| Command | Description |
|---|---|
./scripts/upstream.sh init | Initialize upstream and apply patches to working directory |
./scripts/upstream.sh init -f | Destructively discard checkout/rebase state and re-initialize upstream |
./scripts/upstream.sh checkout | Create branch with patches as commits for editing |
./scripts/upstream.sh rebase -i | Interactively edit patch commits |
./scripts/upstream.sh rebase -o <commit> | Rebase patches onto a new upstream commit |
./scripts/upstream.sh check_in | Write commits back to patches and exit checkout mode |
Guardrails
- Never commit directly to
upstream/withoutcheckout/check_in. - Direct edits under
upstream/outside checkout are ephemeral duringupgrade-provider; the tool resets submodule state. - Do not hand-edit
patches/*.patchunless 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 continueRemove Entire Patch
Use when a patch should be deleted completely.
rm patches/00NN-Description.patch
./scripts/upstream.sh checkout
./scripts/upstream.sh check_inRemove Part of a Patch
Use when only selected hunks/files should be removed from an existing patch.
- Find owning patch/commit (
target_sha) and use the amend workflow above. - 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_inRebasing 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_inVerification Checklist
Before check_in:
- Confirm expected patch count change (
0by default;-1for 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-*.patchwas 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.
Archivos 3 archivos
Instálala a mano
Deska ejecuta esto por ti, para cada agente que elijas. Para ejecutarlo tú en una terminal:
npx skills add pulumi/agent-skills --skill upstream-patchesMás de pulumi
- pulumi-best-practicespulumiLoad when the user is writing, reviewing, or debugging Pulumi TypeScript/Python programs; asks about Output<T> or apply() usage; wants to create ComponentResource classes; needs to refactor resources without destroying them (aliases); is setting up secrets or config; or is configuring a pulumi preview/up CI workflow. Also load for questions about resource dependency order, parent/child resource relationships, or pulumi.interpolate.2,300 instalaciones en skills.sh0
- cloudformation-to-pulumipulumiConvert, migrate, or import AWS CloudFormation stacks or templates into Pulumi programs. Load this skill whenever a user wants to move from CloudFormation to Pulumi, convert a CFN template, import existing CloudFormation-managed resources into Pulumi, or asks about CloudFormation-to-Pulumi migration in any form. Also load when the user mentions cdk-importer in a migration context.1 instalaciones en skills.sh0
- pulumi-arm-to-pulumipulumiConvert or migrate Azure ARM (Azure Resource Manager) templates, Bicep templates, or code to Pulumi, including importing existing Azure resources. This skill MUST be loaded whenever a user requests migration, conversion, or import of ARM templates, Bicep templates, ARM code, Bicep code, or Azure resources to Pulumi.1 instalaciones en skills.sh0
- pulumi-cdk-to-pulumipulumiLoad this skill when a user wants to migrate, convert, port, translate, or move an AWS CDK application (including CDK stacks, constructs, or CloudFormation-synthesized templates) to Pulumi. Phrases such as "convert CDK to Pulumi", "migrate CDK app", "port CDK stacks", "replace CDK with Pulumi", "stop using CDK". Do NOT load for general CDK questions, CDK-only help, or CDK vs Pulumi comparisons where no migration is requested.1 instalaciones en skills.sh0
- pulumi-migrate-from-discovered-stackpulumiMigrate a CloudFormation or ARM stack into a Pulumi stack, sourced from a stack that Pulumi Cloud's Discovery feature has already found and exposed via the discovered-stacks API. Load this skill when the user has a discovered stack in Pulumi Cloud and wants to bring its resources under Pulumi management. Do NOT load for greenfield Pulumi authoring, raw template conversion with no discovered-stack counterpart (i.e. no matching entry from the discovered-stacks API), or Terraform migration.1 instalaciones en skills.sh0