-
-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable pre/post destructiveChanges manifests #583
Comments
Or maybe there is another way you see people doing this kind of automation. I imagine that they use PR comments, and I don't think this is good strategy because the order things are added or removed gets decoupled from the history of changes |
There could also exist a keyword to mark deployment job boundaries. This way we can create some sort of deployment in multiple steps using commits: something like 23echsd [sgd-delete-before] commit message 1
84jdhe2 commit message 2
528jded [sgd-delta-boundary] [sgd-delete-after] commit messages 3
63ecdsd [sgd-delete-before] commit message 1
94jwhe2 commit message 2
a28jded [sgd-delta-boundary] [sgd-delete-after] commit messages 3 When multiple delta_boundary_1
preDestructiveChanges.xml
postDestructiveChanges.xml
destructiveChanges.xml
package.xml
delta_boundary_2
preDestructiveChanges.xml
postDestructiveChanges.xml
destructiveChanges.xml
package.xml The json output would have information that can easily help us to determine how many deployments sgd created |
Hi @AllanOricil ! Thanks for raising this enhancement request and thanks for contributing in making this project better! Could you create another Enhancement Request for the "deployment job boundaries" concept? I'm very interested in both concepts. For the destructive document part, why do you think we should distinguish |
Yes, I thought that destructiveChanges.xml would run in the same deployment job. But according to the docs, it runs before.
Yes, there is no need for using other keywords besides
I don't. It wouldn't be necessary. |
What I understand from the needThe need is to have a way to deal with What I understand from the solution proposedAny deletion should be added in the Edge cases discussionI can see the value in CI when evaluating a PR. Alternative approachI don't have one so far... 😅 Let's think about it further, maybe @AllanOricil you'll get a good idea on how to detect what metadata to put in |
What if This flag could be called
{
"has_pre_destructive_changes": true|false,
"has_post_destructive_changes": true|false,
"has_destructive_changes": true|false,
"has_package_changes": true|false
} |
It is the same as if we were using Salesforce's UI to configure which metadata items have to be deleted afterwards https://success.flosum.com/s/article/Destructive-Changes The UI in this case would be repository's PR description/comment. The input would be parsed to a format that |
Yep I agree @AllanOricil, It is the same as we were using a graphical UI instead of a CLI here. I think point 4 here is debatable (just saying 🙂) I like the I'll try to think on that in the coming days, and let you know if I have an idea. |
To join this little debate as I am also facing this question. I would suggest to have a "deployOptions" folder which contains a folder with branch name (often containing issue/feature number) so that the developer can decide if deletion has to happen in pre or post. Git delta will then just merge all new files (xml) in this folder which will provide correct behavior for pre / post deletion. Later on Git maintainer can archive/delete these files when he decide they are not necessary anymore. |
I think this idea should be done outside of the plugin @Bartheleway. |
Is your proposal related to a problem?
I can't determine if the changes generated by the plugin should be deleted before, after or in the same deployment job. I think that the solution for this problem is to include "reserved keywords" in git messages that sgd could use. Why version this information? Because I could replay the branch history to determine the order metadata changes happened, including deletions.
Describe a solution you propose
Given this set of commits
and considering
HEAD
is pointing to528jded
sfdx sgd:source:delta --from 23echsd
could output 4 manifests
This feature should not need a feature flag to work, in my opinion.
Then this proposal #558 could be extended to include new parameters in the output
Describe alternatives you've considered
Currently there is no alternative. I would have to read commits again and run sgd multiple times between every commit if I create my own solution.
Additional context
N/A
The text was updated successfully, but these errors were encountered: