Question: We are using Github as our source control and Drone.io CI/CD pipelines to handle builds and releases to multiple sandbox environments and our production environment. We would like to use destructivechangespre.xml and destructivechangespost.xml to reduce manual work related to each release.

I know that when you deploy a release that contains destructive changes a second time to an environment you will get errors related to not being able to delete the metadata components that are in your destructivechanges file(s) due to them not existing (since they were already deleted during the first deployment, of course). I've also heard that you can get around this issue by appending the --ignorewarnings tag to your deployment command.

My questions are:

1. Is it the --ignorewarnings tag that is appropriate to use for this case or --ignoreerrors?
2. Whichever tag will allow us to circumvent this warning/error, **does it work when deploying to a Production environment?**

Answer: 
The [Special Behavior of Components](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/packaging_component_behavior.htm) in Packages documentation states that:

> 
> Changes to standard picklists can’t be packaged and deployed to subscriber orgs and picklist values deleted by the developer are still available in the subscriber’s org.
> 
> 
> 

So - in theory - I should not be able to generate that package version at all.

I added a new custom field to the app with the values I required and removed the Type field references from my local files, and then I generated a new package version with a higher minor version number (1.2.2 -> 1.3.0). Then I was able to generate a new package version using this new version as the ancestor as it should be.
This is a known issue in Salesforce. The root cause is that the StandardValueSets are not supported by 2GP but have somehow been added to the package due to a bug in packaging. You can check the following Known Issue article to check if a fix is available.

<https://trailblazer.salesforce.com/issues_view?id=a1p4V000002BgfoQAC>