Sfdx-git-delta: Destructive changes - "metadata is standard and cannot be deleted"

[MaciekLeks]

Issue verification check :

Everyting works ok (deploy changes and deploy destructive changes) until we removed standard fields from the git repo.

What is the problem

When some standard or managed package fields/objects dissapear from the repo then the plugin tryies to remove it on the org.

What is parameter and their value you used

git diff --name-status COMMIT-OLD COMMIT-NEW > res.txt

it gives:

D   force-app/common/objects/ContactPointAddress/fields/ActiveFromDate.field-meta.xml
D   force-app/common/objects/ContactPointAddress/fields/ActiveToDate.field-meta.xml

What is the expected result

Standard and managed package metadata must stay and not be pruned.

What is the actual result

After applying this:
sfdx force:mdapi:deploy -d destructiveChanges -u ALIAS -o -g

destructiveChanges.xml part:

        <members>ContactPointAddress.ActiveFromDate</members>
        <members>ContactPointAddress.ActiveToDate</members>

and the deploy command result:

Error  destructiveChanges/objects/ContactPointAddress.object  ContactPointAddress.ActiveFromDate                      The CustomField called 'ContactPointAddress.ActiveFromDate' is standard and cannot be deleted
Error  destructiveChanges/objects/ContactPointAddress.object  ContactPointAddress.ActiveToDate                        The CustomField called 'ContactPointAddress.ActiveToDate' is standard and cannot be deleted

Steps to reproduce

1. Create a scratch org (1)
2. Change the standard object fields
3. Pull the data
4. Use the plugin to deploy changes into a new scratch (2)
5. Remove the standard fields from the repo
6. Use the plugin to deploy changes incl. destructive changes (2), e.g. (even with igonreerrors)
   sfdx force:mdapi:deploy -d destructiveChanges -u ALIAS -o -g -w 10

Execution context

gitlab runner

[scolladon]

Hi @MaciekLeks and thanks for raising this !

You're right, the plugin just don't know if the content of the destructiveChanges.xml are actually "deletable" (not part of the immutable standard metadata). Not sure we will maintain a destructiveChanges.xml exclude list as it can change depending the API version without notice and dedicated documentation.

The plugin can't know if the element is deletable or not, so the best way to deal with that with the current state of the plugin is to use the ignore feature I guess.
You could write your own set of "standard" element you don't want to be part of the destructiveChanges.xml in this kind of situation and use --ignore parameter.

I hope it will help.

[MaciekLeks]

@scolladon thank you for your answer. I did not suggest the way you prospose but I've already followed this path. So it means, there is no better way right now than laveraging --ignore option. BTW, we are trying to use your code in very, very large project ;)

[jjulicher]

Hi @MaciekLeks

I've used the ignore feature to create a destructive changes that excludes all standard fields using:

*AccountNumber.field-meta.xml
*Id.field-meta.xml
*\Name.field-meta.xml

and then you could add:

*Address.field-meta.xml
*Date.field-meta.xml

which would exclude all Date & Address fields.

In our CI/CD pipeline I have 2 ignore files, one for creating the destructive changes and one for the standard package.xml so I call it twice and output to 2 different directories. @scolladon perhaps we could specify 2 ignore files - one for destructive changes and one for non-destructive?

I hope that helps you.

[scolladon]

Hi @MaciekLeks

I like the idea, we could add another parameter to deal with destructive changes ignore and use the previous ignore parameter treat only addition and modification.

Nonetheless it is a breaking change because ignore will not be used the same way it was used before and so it could break some working settings.

@mehdisfdc any thoughts about that ? alternatives ?

[jjulicher]

Hi Sebastian

You could make it non breaking by using the -i specified one for both
unless the '-di' is specified.

Justin

On Fri, 26 Mar 2021, 6:14 pm Sebastien, @.*> wrote:

Hi @MaciekLeks https://github.com/MaciekLeks

I like the idea, we could add another parameter to deal with destructive
changes ignore and use the previous ignore parameter treat only addition
and modification.

Nonetheless it is a breaking change because ignore will not be used the
same way it was used before and so it could break some working settings.

@mehdisfdc https://github.com/mehdisfdc any thoughts about that ?
alternatives ?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/scolladon/sfdx-git-delta/issues/98#issuecomment-808026889,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA5A54ZIQMD7JZYLZEIEXYDTFQ675ANCNFSM4XX6S4CQ
.

[scolladon]

Hi @jjulicher !

That's a very good idea ! fair point !
If -i parameter is passed the plugin work the same way
And if -di parameter is passed it means the plugin should override the -i only for destructive changes

I can do the pull request, I will need double check for the readme because it needs to be improved and maybe add an example could be a good idea

[jjulicher]

Awesome thanks Sebastian.

Can't wait to use this... Eliminates a few lines of code from my CI
pipeline :)

On Sun, 28 Mar 2021, 1:05 am Sebastien, @.*> wrote:

Hi @jjulicher https://github.com/jjulicher !

That's a very good idea ! fair point !
If -i parameter is passed the plugin work the same way
And if -di parameter is passed it means the plugin should override the -i
only for destructive changes

I can do the pull request, I will need double check for the readme because
it needs to be improved and maybe add an example could be a good idea

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/scolladon/sfdx-git-delta/issues/98#issuecomment-808746556,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA5A545YTYASU2XGE6WPQXLTFXX45ANCNFSM4XX6S4CQ
.

[MaciekLeks]

Thank you. Only one remark. I would'nt use capital letters. I sugest using the small one everywhere. You could use:
--ignore-destructve with "-j", just because is the next one after _i_, or "-e" just because is the next letter afrer "d" in "destructive" word. Capital "D" maybe misleaded with "-d" reserved for something different in the tool. But you know. It's just my opinion.

P.S. I've seen many strange strings related to Windows users ;)

[scolladon]

Hi guys,

I tried to follow the apache cli recommendation for naming the new parameter.
This is why -D for the short versions came up
I took the --ignore-backups as exemple:

-B, --ignore-backups do not list implied entries ending with ~

@MaciekLeks what do you mean by "I see many strange strings related to Windows users ;)" ? 😄

[MaciekLeks]

@MaciekLeks what do you mean by "I see many strange strings related to Windows users ;)" ? smile

I see a lot of problems with windows stations and git (e.g. CRLF), sfdx and node projects. Capital letter in that world could be the same as lowercase. Why? The simplest answer is: "Why not" ;)

[scolladon]

Ah yes !

To deal with that (CRLF and stuff) I use .gitattributes files. It help me sleep 😄