Destructive changes fail when metadata cannot be found in target org

[RichardBeadle]

Describe the bug We are unable to promote Work Items where DevOps Center is attempting to delete metadata which doesn't exist in the target org. Additionally, we have a Work Item where DevOps Center is attempting to delete metadata types which cannot be deleted via the API (Record Type).

Our developers/admins worked on a number of Work Items in development sandboxes. After submitting the Work Items for review & approval, rework was required and some metadata was deleted/renamed. This rework is then committed to the work item, and the deleted metadata is tagged as 'REMOVED' by DevOps Center. The metadata never existed in the target org.

DevOps Center tracks these removed components as destructive changes, and deployments are now failing as the metadata cannot be found in the target org. It doesn't appear to be possible to ignore warnings for destructive changes.

I have been able to add some files to the .force-ignore file, but some files such as Custom Fields cannot be ignored as they are combined into Object files by the metadata API. Furthermore, record types are tracked for deletion, but cannot be deleted by the metadata API, so it is not possible to move these Work Items through the pipeline.

To Reproduce Steps to reproduce the behavior:

1. Create a Work Item.
2. Create a metadata file in the target org (e.g. custom field).
3. Commit the change to the Work Item.
4. Create a review (pull request).
5. Delete the field in the source org (or rename the API).
6. Commit the (remove) change to the Work Item.
7. Attempt to promote the Work Item to the next stage in the pipeline.

Expected behavior Either:

• DevOps Center should detect the metadata doesn't (and never existed), in the target branch/org and does not include in a destructive changes file. This should be possible by double checking a git diff rather than solely relying on the REMOVE tags from the CLI / DevOps Center.
• Allow --ignore-warnings for destructive changes. If the metadata is not found in the target org, this is a non issue for destructive changes. This could be a feature flag controllable in each DevOps Project settings if necessary.

Screenshots

[franzvarga]

We're running into this right now with our first foray into the DevOps Center. Outside of the .forceignore file exclusions, were there any other workarounds you found?

[RichardBeadle]

Sadly we still run up against this from time to time. The best we have come up with is to have our developers re-create the Work Item if they hit the issue deploying from Dev - although this is less than ideal as the commit / review history is lost.

On the small number of occasions we've hit this issue in higher environments when QA are fixing a bug, we're forced to create the metadata in the target org just in order to delete it, or failing that use the .forceignore.

[franzvarga]

That makes sense, thanks for the advice Richard. For this go around we ended up creating a series of smaller work items like you mentioned. Good to hear that its a work-aroundable challenge.

[laszlo-foldi-attentioncrm]

I've just came across this issue.

We have a 3 org pipeline at the moment, and I've been working on a task for around 2 weeks.

At the beginning I've created a few classes, and started expanding the code. At the end of our development, I've refactored the code, and removed a few classes.

This cased DevOps Center to fail on deployment to UAT, that is the next ORG in our pipeline, due to this class was placed into the destructive changes. It never existed in higher ORGs... How is this an issue?

Any workarounds? Should I just force the merge and hope for the best Salesforce is able to release the changes? Or what should be done?