upstream-patches

par 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.

Plus de skills de pulumi

package-usage
pulumi
Suivre quelles stacks dans une organisation Pulumi utilisent un package spécifique et à quelles versions. Utilisé pour des audits inter-stacks, identifier les versions obsolètes ou non maintenues…
official
pulumi-automation-api
pulumi
Orchestration programmatique des opérations d'infrastructure Pulumi sur plusieurs stacks et applications. Prend en charge les architectures de source locale (projets Pulumi existants) et de source inline (programmes embarqués), permettant des schémas de déploiement flexibles allant de scénarios simples à complexes multi-stacks. Gère l'orchestration multi-stack avec séquencement des dépendances, déploiements parallèles indépendants et passage de sorties entre stacks pour un provisionnement coordonné de l'infrastructure. Fournit une orchestration...
official
pulumi-best-practices
pulumi
Pratiques exemplaires complètes pour écrire du code d'infrastructure Pulumi fiable et maintenable. Évitez de créer des ressources dans les callbacks apply() ; passez les objets Output directement en entrées pour préserver le suivi des dépendances et la visibilité en aperçu. Utilisez les classes ComponentResource pour regrouper les ressources connexes en unités logiques réutilisables avec une hiérarchie parent-enfant appropriée via parent: this. Chiffrez les secrets dès le départ avec le flag --secret ou config.requireSecret() pour éviter les fuites d'identifiants dans les fichiers d'état...
official
pulumi-component
pulumi
Composants d'infrastructure réutilisables avec support multilingue, valeurs par défaut judicieuses et modèles de composition. Nécessite quatre éléments essentiels : étendre ComponentResource, accepter les paramètres standards, définir parent: this sur tous les enfants, et appeler registerOutputs() à la fin du constructeur. Les interfaces Args doivent utiliser les wrappers Input<T>, éviter les types union et les fonctions, et garder les structures plates pour prendre en charge la génération de SDK multilingue. Exposer uniquement les sorties essentielles en tant que propriétés publiques ; masquer...
official
pulumi-debug-failed-operation
pulumi
Déboguer une mise à jour ou un aperçu Pulumi qui a échoué : lire l’échec déjà enregistré par Pulumi, trouver ce qui l’a causé et le corriger. Charger cette compétence lorsque l’utilisateur demande de…
official
pulumi-esc
pulumi
Gestion centralisée des secrets, de la configuration et des identifiants dynamiques pour l'infrastructure et les applications Pulumi. Prend en charge la composition d'environnements via des importations et des couches, avec des clés réservées pour environmentVariables , pulumiConfig et files . Génère des identifiants à court terme via OIDC pour AWS, Azure et GCP ; s'intègre avec AWS Secrets Manager, Azure Key Vault, HashiCorp Vault et 1Password. Les commandes CLI principales incluent pulumi env init , pulumi env edit , pulumi env open (révèle...
official
pulumi-neo-handoff
pulumi
Transférer le fil de discussion actuel vers une nouvelle tâche Pulumi Neo en tant que transfert unidirectionnel. Utilisez lorsque l'utilisateur demande explicitement de transférer, envoyer, rediriger ou poursuivre la conversation en cours…
official
pulumi-overview
pulumi
Utilisez cette compétence pour toute tâche qui crée, modifie, inspecte ou détruit une infrastructure cloud ou une configuration SaaS, des opérations CLI ponctuelles aux…
official