I completed a work item with a fairly granular series of commits where the customer changed their mind on naming part way through.
So, my commits look like this:
- Created some fields named "Next Of Kin X"
- Created a trigger on those fields
- The customer decided they wanted it to be called "Emergency Contact X", so created new fields with that name
- Moved the trigger to the Emergency Contact fields
- Deleted the "Next Of Kin" fields
I reviewed the PR in GitHub and that looked correct to me. It only included the net result i.e. some new fields called "Emergency Contact X" and a trigger on those fields.
But, when I try to promote this WI, DOC fails with the message
"The deployment of the work items into the next stage failed.
destructiveChanges.xml of Type ApexClass failed to deploy due to No ApexClass named: ContactNextOfKinTimestamp found destructiveChanges.xml of Type ApexClass failed to deploy due to No ApexClass named: ContactNextOfKinTimestampTest found"
This makes me think that DOC doesn't deploy the PR in GitHub, it deploys the sf_devops__Vcs_Event__c records related to the WI. Is that right?
To fix this, I used git to squash the commits into a single commit and then force-pushed that GitHub. I crossed my fingers and deployed with DOC, but got the same error message.
So, my supposition is that DOC deploys the sf_devops__Vcs_Event__c records but those are out-of-sync. I can see the squash commit as a sf_devops__Vcs_Event__c, but also all the old granular commits. Maybe I can manually delete the old ones and try again with just the one for the squashed commit containing all my changes.
It would be good to improve my mental model of what's going on here, so I'd appreciate any insights that you could offer!
Thanks for the information.
In this case Vcs_Event__c record does not affect. When using the UI we do not need to wait for events to be downloaded.
We do have logic in place similar to what you did of treating an ADD-DELETE as a no-op, but for some reason in this case it was not done.
If you go to WI activity history you can see all the activity (including commits) that were done on that work item. Maybe there is a clue there as to why it was not considered as no-op.
We will review this flow though, thanks again for the information.