Fix multi-stack buildpack deletion in Initialize() by tnikolova82 · Pull Request #126 · cloudfoundry/switchblade

tnikolova82 · 2026-04-09T09:29:10Z

Summary

Fix Initialize() to handle CF environments with multiple stacks (e.g. cflinuxfs4 + cflinuxfs5) sharing the same buildpack name
Iterate over /v3/buildpacks resources and issue per-resource delete-buildpack calls with -s <stack> when stack is non-empty

Problem

When CF has both cflinuxfs4 and cflinuxfs5 deployed, buildpacks like ruby_buildpack are registered once per stack. The current code calls cf delete-buildpack -f <name> without -s, causing:

Multiple buildpacks named ruby_buildpack found. Specify a stack name by using a '-s' flag.
FAILED

This breaks all buildpack integration tests on CF environments with multiple stacks.

Fix

Instead of a single delete-buildpack call, loop over all resources from the /v3/buildpacks?names=<name> response. For each resource:

If stack != "": delete-buildpack -f <name> -s <stack>
If stack == "": delete-buildpack -f <name> (for any-stack/stackless buildpacks)

History

Version	Behavior	Problem
v0.9.0	Hardcoded `-s <stack>` on every delete	Fails for stackless/any-stack buildpacks
v0.9.1-v0.9.4	Removed `-s` flag entirely	Fails when multiple stacks share the same buildpack name
This fix	Conditional `-s` per resource	Handles all cases correctly

Tests

Updated "cannot be deleted" failure test (stub now returns a resource so the delete loop is exercised)
Added "when buildpack exists for multiple stacks" test (expects two -s delete calls)
Added "when buildpack exists with a single stack" test (expects one -s delete call)
All 58 tests in internal/cloudfoundry pass

When CF has the same buildpack registered for multiple stacks (e.g. cflinuxfs4 and cflinuxfs5), the single 'cf delete-buildpack -f <name>' call fails with 'Multiple buildpacks named X found. Specify a stack name by using a -s flag.' Fix by iterating over all resources from the /v3/buildpacks API response and issuing separate delete-buildpack calls per resource, using the -s flag when the resource has a non-empty stack. This handles three cases: - Stackless/any-stack buildpacks (no -s flag) - Single-stack buildpacks (-s <stack>) - Multi-stack buildpacks (one -s <stack> call per stack)

ivanovac

lgtm

Replace vendored switchblade patch with upstream fix from cloudfoundry/switchblade#126, released as v0.9.5.

v0.9.5 fixes multi-stack cf delete-buildpack failures when both cflinuxfs4 and cflinuxfs5 stacks are deployed (cloudfoundry/switchblade#126).

tnikolova82 · 2026-04-09T09:29:10Z

Summary

Fix Initialize() to handle CF environments with multiple stacks (e.g. cflinuxfs4 + cflinuxfs5) sharing the same buildpack name
Iterate over /v3/buildpacks resources and issue per-resource delete-buildpack calls with -s <stack> when stack is non-empty

Problem

When CF has both cflinuxfs4 and cflinuxfs5 deployed, buildpacks like ruby_buildpack are registered once per stack. The current code calls cf delete-buildpack -f <name> without -s, causing:

Multiple buildpacks named ruby_buildpack found. Specify a stack name by using a '-s' flag.
FAILED

This breaks all buildpack integration tests on CF environments with multiple stacks.

Fix

Instead of a single delete-buildpack call, loop over all resources from the /v3/buildpacks?names=<name> response. For each resource:

If stack != "": delete-buildpack -f <name> -s <stack>
If stack == "": delete-buildpack -f <name> (for any-stack/stackless buildpacks)

History

Version	Behavior	Problem
v0.9.0	Hardcoded `-s <stack>` on every delete	Fails for stackless/any-stack buildpacks
v0.9.1-v0.9.4	Removed `-s` flag entirely	Fails when multiple stacks share the same buildpack name
This fix	Conditional `-s` per resource	Handles all cases correctly

Tests

Updated "cannot be deleted" failure test (stub now returns a resource so the delete loop is exercised)
Added "when buildpack exists for multiple stacks" test (expects two -s delete calls)
Added "when buildpack exists with a single stack" test (expects one -s delete call)
All 58 tests in internal/cloudfoundry pass

When CF has the same buildpack registered for multiple stacks (e.g. cflinuxfs4 and cflinuxfs5), the single 'cf delete-buildpack -f <name>' call fails with 'Multiple buildpacks named X found. Specify a stack name by using a -s flag.' Fix by iterating over all resources from the /v3/buildpacks API response and issuing separate delete-buildpack calls per resource, using the -s flag when the resource has a non-empty stack. This handles three cases: - Stackless/any-stack buildpacks (no -s flag) - Single-stack buildpacks (-s <stack>) - Multi-stack buildpacks (one -s <stack> call per stack)

ivanovac

lgtm

Replace vendored switchblade patch with upstream fix from cloudfoundry/switchblade#126, released as v0.9.5.

v0.9.5 fixes multi-stack cf delete-buildpack failures when both cflinuxfs4 and cflinuxfs5 stacks are deployed (cloudfoundry/switchblade#126).

tnikolova82 · 2026-04-09T09:29:10Z

Summary

Fix Initialize() to handle CF environments with multiple stacks (e.g. cflinuxfs4 + cflinuxfs5) sharing the same buildpack name
Iterate over /v3/buildpacks resources and issue per-resource delete-buildpack calls with -s <stack> when stack is non-empty

Problem

When CF has both cflinuxfs4 and cflinuxfs5 deployed, buildpacks like ruby_buildpack are registered once per stack. The current code calls cf delete-buildpack -f <name> without -s, causing:

Multiple buildpacks named ruby_buildpack found. Specify a stack name by using a '-s' flag.
FAILED

This breaks all buildpack integration tests on CF environments with multiple stacks.

Fix

Instead of a single delete-buildpack call, loop over all resources from the /v3/buildpacks?names=<name> response. For each resource:

If stack != "": delete-buildpack -f <name> -s <stack>
If stack == "": delete-buildpack -f <name> (for any-stack/stackless buildpacks)

History

Version	Behavior	Problem
v0.9.0	Hardcoded `-s <stack>` on every delete	Fails for stackless/any-stack buildpacks
v0.9.1-v0.9.4	Removed `-s` flag entirely	Fails when multiple stacks share the same buildpack name
This fix	Conditional `-s` per resource	Handles all cases correctly

Tests

Updated "cannot be deleted" failure test (stub now returns a resource so the delete loop is exercised)
Added "when buildpack exists for multiple stacks" test (expects two -s delete calls)
Added "when buildpack exists with a single stack" test (expects one -s delete call)
All 58 tests in internal/cloudfoundry pass

When CF has the same buildpack registered for multiple stacks (e.g. cflinuxfs4 and cflinuxfs5), the single 'cf delete-buildpack -f <name>' call fails with 'Multiple buildpacks named X found. Specify a stack name by using a -s flag.' Fix by iterating over all resources from the /v3/buildpacks API response and issuing separate delete-buildpack calls per resource, using the -s flag when the resource has a non-empty stack. This handles three cases: - Stackless/any-stack buildpacks (no -s flag) - Single-stack buildpacks (-s <stack>) - Multi-stack buildpacks (one -s <stack> call per stack)

ivanovac

lgtm

Replace vendored switchblade patch with upstream fix from cloudfoundry/switchblade#126, released as v0.9.5.

v0.9.5 fixes multi-stack cf delete-buildpack failures when both cflinuxfs4 and cflinuxfs5 stacks are deployed (cloudfoundry/switchblade#126).

tnikolova82 · 2026-04-09T09:29:10Z

Summary

Fix Initialize() to handle CF environments with multiple stacks (e.g. cflinuxfs4 + cflinuxfs5) sharing the same buildpack name
Iterate over /v3/buildpacks resources and issue per-resource delete-buildpack calls with -s <stack> when stack is non-empty

Problem

When CF has both cflinuxfs4 and cflinuxfs5 deployed, buildpacks like ruby_buildpack are registered once per stack. The current code calls cf delete-buildpack -f <name> without -s, causing:

Multiple buildpacks named ruby_buildpack found. Specify a stack name by using a '-s' flag.
FAILED

This breaks all buildpack integration tests on CF environments with multiple stacks.

Fix

Instead of a single delete-buildpack call, loop over all resources from the /v3/buildpacks?names=<name> response. For each resource:

If stack != "": delete-buildpack -f <name> -s <stack>
If stack == "": delete-buildpack -f <name> (for any-stack/stackless buildpacks)

History

Version	Behavior	Problem
v0.9.0	Hardcoded `-s <stack>` on every delete	Fails for stackless/any-stack buildpacks
v0.9.1-v0.9.4	Removed `-s` flag entirely	Fails when multiple stacks share the same buildpack name
This fix	Conditional `-s` per resource	Handles all cases correctly

Tests

Updated "cannot be deleted" failure test (stub now returns a resource so the delete loop is exercised)
Added "when buildpack exists for multiple stacks" test (expects two -s delete calls)
Added "when buildpack exists with a single stack" test (expects one -s delete call)
All 58 tests in internal/cloudfoundry pass

When CF has the same buildpack registered for multiple stacks (e.g. cflinuxfs4 and cflinuxfs5), the single 'cf delete-buildpack -f <name>' call fails with 'Multiple buildpacks named X found. Specify a stack name by using a -s flag.' Fix by iterating over all resources from the /v3/buildpacks API response and issuing separate delete-buildpack calls per resource, using the -s flag when the resource has a non-empty stack. This handles three cases: - Stackless/any-stack buildpacks (no -s flag) - Single-stack buildpacks (-s <stack>) - Multi-stack buildpacks (one -s <stack> call per stack)

ivanovac

lgtm

Replace vendored switchblade patch with upstream fix from cloudfoundry/switchblade#126, released as v0.9.5.

v0.9.5 fixes multi-stack cf delete-buildpack failures when both cflinuxfs4 and cflinuxfs5 stacks are deployed (cloudfoundry/switchblade#126).

tnikolova82 · 2026-04-09T09:29:10Z

Summary

Fix Initialize() to handle CF environments with multiple stacks (e.g. cflinuxfs4 + cflinuxfs5) sharing the same buildpack name
Iterate over /v3/buildpacks resources and issue per-resource delete-buildpack calls with -s <stack> when stack is non-empty

Problem

When CF has both cflinuxfs4 and cflinuxfs5 deployed, buildpacks like ruby_buildpack are registered once per stack. The current code calls cf delete-buildpack -f <name> without -s, causing:

Multiple buildpacks named ruby_buildpack found. Specify a stack name by using a '-s' flag.
FAILED

This breaks all buildpack integration tests on CF environments with multiple stacks.

Fix

Instead of a single delete-buildpack call, loop over all resources from the /v3/buildpacks?names=<name> response. For each resource:

If stack != "": delete-buildpack -f <name> -s <stack>
If stack == "": delete-buildpack -f <name> (for any-stack/stackless buildpacks)

History

Version	Behavior	Problem
v0.9.0	Hardcoded `-s <stack>` on every delete	Fails for stackless/any-stack buildpacks
v0.9.1-v0.9.4	Removed `-s` flag entirely	Fails when multiple stacks share the same buildpack name
This fix	Conditional `-s` per resource	Handles all cases correctly

Tests

Updated "cannot be deleted" failure test (stub now returns a resource so the delete loop is exercised)
Added "when buildpack exists for multiple stacks" test (expects two -s delete calls)
Added "when buildpack exists with a single stack" test (expects one -s delete call)
All 58 tests in internal/cloudfoundry pass

When CF has the same buildpack registered for multiple stacks (e.g. cflinuxfs4 and cflinuxfs5), the single 'cf delete-buildpack -f <name>' call fails with 'Multiple buildpacks named X found. Specify a stack name by using a -s flag.' Fix by iterating over all resources from the /v3/buildpacks API response and issuing separate delete-buildpack calls per resource, using the -s flag when the resource has a non-empty stack. This handles three cases: - Stackless/any-stack buildpacks (no -s flag) - Single-stack buildpacks (-s <stack>) - Multi-stack buildpacks (one -s <stack> call per stack)

ivanovac

lgtm

Replace vendored switchblade patch with upstream fix from cloudfoundry/switchblade#126, released as v0.9.5.

v0.9.5 fixes multi-stack cf delete-buildpack failures when both cflinuxfs4 and cflinuxfs5 stacks are deployed (cloudfoundry/switchblade#126).

tnikolova82 · 2026-04-09T09:29:10Z

Summary

Fix Initialize() to handle CF environments with multiple stacks (e.g. cflinuxfs4 + cflinuxfs5) sharing the same buildpack name
Iterate over /v3/buildpacks resources and issue per-resource delete-buildpack calls with -s <stack> when stack is non-empty

Problem

When CF has both cflinuxfs4 and cflinuxfs5 deployed, buildpacks like ruby_buildpack are registered once per stack. The current code calls cf delete-buildpack -f <name> without -s, causing:

Multiple buildpacks named ruby_buildpack found. Specify a stack name by using a '-s' flag.
FAILED

This breaks all buildpack integration tests on CF environments with multiple stacks.

Fix

Instead of a single delete-buildpack call, loop over all resources from the /v3/buildpacks?names=<name> response. For each resource:

If stack != "": delete-buildpack -f <name> -s <stack>
If stack == "": delete-buildpack -f <name> (for any-stack/stackless buildpacks)

History

Version	Behavior	Problem
v0.9.0	Hardcoded `-s <stack>` on every delete	Fails for stackless/any-stack buildpacks
v0.9.1-v0.9.4	Removed `-s` flag entirely	Fails when multiple stacks share the same buildpack name
This fix	Conditional `-s` per resource	Handles all cases correctly

Tests

Updated "cannot be deleted" failure test (stub now returns a resource so the delete loop is exercised)
Added "when buildpack exists for multiple stacks" test (expects two -s delete calls)
Added "when buildpack exists with a single stack" test (expects one -s delete call)
All 58 tests in internal/cloudfoundry pass

When CF has the same buildpack registered for multiple stacks (e.g. cflinuxfs4 and cflinuxfs5), the single 'cf delete-buildpack -f <name>' call fails with 'Multiple buildpacks named X found. Specify a stack name by using a -s flag.' Fix by iterating over all resources from the /v3/buildpacks API response and issuing separate delete-buildpack calls per resource, using the -s flag when the resource has a non-empty stack. This handles three cases: - Stackless/any-stack buildpacks (no -s flag) - Single-stack buildpacks (-s <stack>) - Multi-stack buildpacks (one -s <stack> call per stack)

ivanovac

lgtm

Replace vendored switchblade patch with upstream fix from cloudfoundry/switchblade#126, released as v0.9.5.

v0.9.5 fixes multi-stack cf delete-buildpack failures when both cflinuxfs4 and cflinuxfs5 stacks are deployed (cloudfoundry/switchblade#126).

tnikolova82 · 2026-04-09T09:29:10Z

Summary

Fix Initialize() to handle CF environments with multiple stacks (e.g. cflinuxfs4 + cflinuxfs5) sharing the same buildpack name
Iterate over /v3/buildpacks resources and issue per-resource delete-buildpack calls with -s <stack> when stack is non-empty

Problem

When CF has both cflinuxfs4 and cflinuxfs5 deployed, buildpacks like ruby_buildpack are registered once per stack. The current code calls cf delete-buildpack -f <name> without -s, causing:

Multiple buildpacks named ruby_buildpack found. Specify a stack name by using a '-s' flag.
FAILED

This breaks all buildpack integration tests on CF environments with multiple stacks.

Fix

Instead of a single delete-buildpack call, loop over all resources from the /v3/buildpacks?names=<name> response. For each resource:

If stack != "": delete-buildpack -f <name> -s <stack>
If stack == "": delete-buildpack -f <name> (for any-stack/stackless buildpacks)

History

Version	Behavior	Problem
v0.9.0	Hardcoded `-s <stack>` on every delete	Fails for stackless/any-stack buildpacks
v0.9.1-v0.9.4	Removed `-s` flag entirely	Fails when multiple stacks share the same buildpack name
This fix	Conditional `-s` per resource	Handles all cases correctly

Tests

Updated "cannot be deleted" failure test (stub now returns a resource so the delete loop is exercised)
Added "when buildpack exists for multiple stacks" test (expects two -s delete calls)
Added "when buildpack exists with a single stack" test (expects one -s delete call)
All 58 tests in internal/cloudfoundry pass

When CF has the same buildpack registered for multiple stacks (e.g. cflinuxfs4 and cflinuxfs5), the single 'cf delete-buildpack -f <name>' call fails with 'Multiple buildpacks named X found. Specify a stack name by using a -s flag.' Fix by iterating over all resources from the /v3/buildpacks API response and issuing separate delete-buildpack calls per resource, using the -s flag when the resource has a non-empty stack. This handles three cases: - Stackless/any-stack buildpacks (no -s flag) - Single-stack buildpacks (-s <stack>) - Multi-stack buildpacks (one -s <stack> call per stack)

ivanovac

lgtm

Replace vendored switchblade patch with upstream fix from cloudfoundry/switchblade#126, released as v0.9.5.

v0.9.5 fixes multi-stack cf delete-buildpack failures when both cflinuxfs4 and cflinuxfs5 stacks are deployed (cloudfoundry/switchblade#126).

tnikolova82 · 2026-04-09T09:29:10Z

Summary

Fix Initialize() to handle CF environments with multiple stacks (e.g. cflinuxfs4 + cflinuxfs5) sharing the same buildpack name
Iterate over /v3/buildpacks resources and issue per-resource delete-buildpack calls with -s <stack> when stack is non-empty

Problem

When CF has both cflinuxfs4 and cflinuxfs5 deployed, buildpacks like ruby_buildpack are registered once per stack. The current code calls cf delete-buildpack -f <name> without -s, causing:

Multiple buildpacks named ruby_buildpack found. Specify a stack name by using a '-s' flag.
FAILED

This breaks all buildpack integration tests on CF environments with multiple stacks.

Fix

Instead of a single delete-buildpack call, loop over all resources from the /v3/buildpacks?names=<name> response. For each resource:

If stack != "": delete-buildpack -f <name> -s <stack>
If stack == "": delete-buildpack -f <name> (for any-stack/stackless buildpacks)

History

Version	Behavior	Problem
v0.9.0	Hardcoded `-s <stack>` on every delete	Fails for stackless/any-stack buildpacks
v0.9.1-v0.9.4	Removed `-s` flag entirely	Fails when multiple stacks share the same buildpack name
This fix	Conditional `-s` per resource	Handles all cases correctly

Tests

Updated "cannot be deleted" failure test (stub now returns a resource so the delete loop is exercised)
Added "when buildpack exists for multiple stacks" test (expects two -s delete calls)
Added "when buildpack exists with a single stack" test (expects one -s delete call)
All 58 tests in internal/cloudfoundry pass

When CF has the same buildpack registered for multiple stacks (e.g. cflinuxfs4 and cflinuxfs5), the single 'cf delete-buildpack -f <name>' call fails with 'Multiple buildpacks named X found. Specify a stack name by using a -s flag.' Fix by iterating over all resources from the /v3/buildpacks API response and issuing separate delete-buildpack calls per resource, using the -s flag when the resource has a non-empty stack. This handles three cases: - Stackless/any-stack buildpacks (no -s flag) - Single-stack buildpacks (-s <stack>) - Multi-stack buildpacks (one -s <stack> call per stack)

ivanovac

lgtm

Replace vendored switchblade patch with upstream fix from cloudfoundry/switchblade#126, released as v0.9.5.

v0.9.5 fixes multi-stack cf delete-buildpack failures when both cflinuxfs4 and cflinuxfs5 stacks are deployed (cloudfoundry/switchblade#126).

tnikolova82 requested review from beyhan and stephanme April 9, 2026 09:31

ivanovac approved these changes Apr 9, 2026
View reviewed changes

tnikolova82 merged commit a707233 into mainApr 9, 2026
2 checks passed

tnikolova82 deleted the fix-multistack-delete-buildpack branch April 9, 2026 09:35

tnikolova82 added a commit to cloudfoundry/ruby-buildpack that referenced this pull request Apr 9, 2026
Upgrade switchblade to v0.9.5 (upstream multi-stack fix)
1576f01
Replace vendored switchblade patch with upstream fix from cloudfoundry/switchblade#126, released as v0.9.5.

This was referenced Apr 9, 2026
Fix switchblade Initialize() multi-stack buildpack deletion cloudfoundry/ruby-buildpack#1136
Closed
Upgrade switchblade to v0.9.5 (multi-stack delete fix) cloudfoundry/ruby-buildpack#1137
Merged

tnikolova82 added a commit to cloudfoundry/r-buildpack that referenced this pull request Apr 14, 2026
Upgrade switchblade to v0.9.5
343dd00
v0.9.5 fixes multi-stack cf delete-buildpack failures when both cflinuxfs4 and cflinuxfs5 stacks are deployed (cloudfoundry/switchblade#126).