You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Shipyard destroy with a directory or git path does not destroy resources.
Use case: development on more than one project, each with their own blueprint or in their current form docker-compose. While iterating one one blueprint, I do not want to destroy the other stack.
To Reproduce
Steps to reproduce the behavior:
shipyard run github.com/shipyard-run/blueprints//vault-k8s
Nothing is printed to the console and no action is taken.
Run another blueprint. Most of the ones in the blueprint repo bind on 0.0.0.0:43 so you'll get errors like "Bind for 0.0.0.0:443 failed: port is already allocated". shipyard run any of these and you'll see that in the next command (even if the allocation fails) you'll see it's attempted to be destroyed.
Hey, @ricochet this is a good catch, while you can do something like shipyard run ./folder and shipyard destroy ./folder this does not work the same way for blueprints that are downloaded. The behavior as you correctly state should be the same and can lead to confusing situations.
This is a pretty simple change, I will make sure I add it the next time I do an update, for now, the only workaround is to do the destroy on the folder containing the downloaded blueprint. In your example, this should be something like $HOME/.shipyard/blueprints/github.com/shipyard-run/vault-k8s.
Describe the bug
Shipyard destroy with a directory or git path does not destroy resources.
Use case: development on more than one project, each with their own blueprint or in their current form docker-compose. While iterating one one blueprint, I do not want to destroy the other stack.
To Reproduce
Steps to reproduce the behavior:
shipyard run github.com/shipyard-run/blueprints//vault-k8s
shipyard destroy github.com/shipyard-run/blueprints//vault-k8s
shipyard destroy
- all stacks are destroyed.Expected behavior
Ability to destroy resources as described by a blueprint. The docs imply this is expected to work: https://shipyard.run/docs/commands/destroy
I expected similar behavior to
docker-compose stop -f <file>
Desktop (please complete the following information):
macos m1
The text was updated successfully, but these errors were encountered: