Describe the bug
If I have introduced a destructive change into my Work Item in a commit, I cannot revert this destructive change in a successive commit on the same Work Item : DevOps considers there is a destructive change, and whatever operation I do after to try to revert the situation (add the file again, revert commit in GithubDesktop) will not make it change its mind.
To Reproduce
Steps to reproduce the behavior:
Create a work item and commit a few files, including a profile
Try to promote. Let's assume that an error blocks the promotion
Go to the Pull Request in Github, find the profile in the modified files, and click "delete file" : I did this, thinking it might be one way of removing the file from the PR. Let's assume we do this to try to solve the "promote issue"
Try to promote again : now the deployment is saying that it is trying to delete the profile in the target org (destructive change). Oops, that was a mistake, let's revert.
In VS Code, retrieve the file from the sandbox and commit in on the WI branch : I'm adding the file, trying to revert the previous change
In DevOps Center, try to promote : the error persists, still trying to remove the profile from the target org
Go to GitHub desktop and find the magic-sounding "revert commit" feature : revert the last 2 commits, push to the WI branch
In the GitHub pull request, see that extra lines have been added, but the destructive change still seems to be there
In DevOps Center, with no hope of success, try to promote again. Same error.
Cry, send the Work Item to "NEVER"-land, and start again from scratch by creating a new work item?
Expected behavior
If I delete a file, which causes DevOps Center to create a destructive change, there is no option to revert that, other than throwing the WI away. I would like :
either DevOps Center to intelligently understand that if I'm adding a file that has previously been deleted (in the same WI), then it should warn me, ask to confirm that I'm adding it again, and NO LONGER keep causing a destructive change
or, even better, give me a list of all the "contents" of my Work Item (ie cumulative list of all the committed items), and let me add or remove items from it : this would recalculate a new commit, and forget destructive changes which have been reverted.
Screenshots
Additional context
I consider this to be a bug.
I understand the underlying technical logic (reasoning commit by commit) which might make you say that this is not a bug. But I can tell you that admins or consultants, especially coming from the change-set world, need this feature.
And so do I (20+ years of Salesforce) : please give me an option to change my mind after I made an incorrect destructive change, considering I have not even yet promoted it !
Describe the bug If I have introduced a destructive change into my Work Item in a commit, I cannot revert this destructive change in a successive commit on the same Work Item : DevOps considers there is a destructive change, and whatever operation I do after to try to revert the situation (add the file again, revert commit in GithubDesktop) will not make it change its mind.
To Reproduce Steps to reproduce the behavior:
Expected behavior If I delete a file, which causes DevOps Center to create a destructive change, there is no option to revert that, other than throwing the WI away. I would like :
Screenshots
Additional context I consider this to be a bug. I understand the underlying technical logic (reasoning commit by commit) which might make you say that this is not a bug. But I can tell you that admins or consultants, especially coming from the change-set world, need this feature. And so do I (20+ years of Salesforce) : please give me an option to change my mind after I made an incorrect destructive change, considering I have not even yet promoted it !