[SGD 5.34.0] [Profiles Are Not Copied in Output Dir]

[arafesthain]

Issue verification check:

• [x] is the current repository fully deployable at the commit SHA provided with the 'from' parameter of the command?

What is the problem?

Profiles are well detected as changed by sgd but then they are not copy/pasted into the deploy directory.

What is the parameter and the value you used with it?

sfdx sgd:source:delta -d -t HEAD -f 2024_GR02.1_stopclock -r /home/vsts/work/1/salesforce_repo -i /home/vsts/work/1/salesforce_repo/.forceignore -o output

What is the expected result?

Profiles are in the package.xml & copied in the output dir.

What is the actual result?

Profiles are in the package.xml but not copied (other files are well there)

Steps to reproduce

I will be able to share you a PAT if needed

Execution context

Node: v18.19.1 Npm version : 10.2.4 sf version: @salesforce/cli/2.30.8 linux-x64 node-v18.19.1 system: Ubuntu 22.04.4 LTS

Successfully installed sfdx-git-delta v5.34.0 sfdx-git-delta 5.34.0

yarn v1.22.21

More information (optional)

M   force-app/main/default/profiles/ePayments - Merchant Boarding Department.profile-meta.xml
M   force-app/main/default/profiles/ePayments - Merchant Boarding.profile-meta.xml
M   force-app/main/default/profiles/ePayments - Service agent.profile-meta.xml

[scolladon]

Hi @arafesthain ! (long time no see)

Thanks for raising this issue and thanks for contributing in making this project better!

I tried multiple things here in order to reproduce in my laptop (macOs). Here is what I tried: I set up a branch and added a profile with content in it. Then I made 3 commits.

1. a white change (some new line)
2. a scopeable change (change on some attribut that can be scoped)
3. a non scopeable change (change on attribut that cannot be scoped and must be in the profile content)

Then I tried to see the result of those 3 commits in isolation in 2 different versions, with 2 different path to reach the repository to see the impact, and I tried to have a very simple name (test.profile-meta.xml) versus a more complex name (ePayments - Merchant Boarding Department.profile-meta.xml)		v5.34.0 (latest)	v5.38.0 (latest-rc)
-r "."	✅	✅
l -r "folder"	✅	✅
simple name	✅	✅
l complex name	✅	✅

On my side everything looks fine.

I need your help to reproduce it. Maybe you can guide me on what I did wrong with this attempt. Or maybe you could give me access to an isolated scenario where I can reproduce Thanks in advance

[arafesthain]

Hello @scolladon (yep long time no see, you should put more bugs :p)

Just a question before we go for the repro, the diff are only related to Task field access (existing field). Any chance it is because I do not deploy anything related to this field/object ? (e.g: field.xml/object.xml) ?

[scolladon]

@arafesthain I don't think it could be the issue, because we do not cross check the content of the profile with the content of the package. Nice idea though, we talked about that feature for a long time and finally decided to not do it because sometimes we want to ship permission change to already existing metadata.

[scolladon]

I have been able to reproduce the issue. I also see what is the root cause of this issue. Thanks for your help to isolate this very specific behavior @arafesthain

I'll propose a fix asap. Stay tuned

[scolladon]

I think the issue in the code is because the profile with the issue does not have the xml header (<?xml version="1.0" encoding="UTF-8"?>) SGD expect the file to be structured with this header. When it is not present it make the plugin assume the file is empty.

I think this could easily be fix by adding the header in the file.

My question here is: Is it possible for a metadata definition to not contains the xml header and still be deployable (I thought it was not possible) ? If yes then the plugin should take this aspect in account and I'll create a feature request soon. This way you'll have two choices : add the header or wait for this feature.

[arafesthain]

Hello @scolladon, thanks for the quick repro/answer.

Yes I confirm salesforce accept the file as it is :

in the meantime I will add the header at least :D

[github-actions[bot]]

Shipped in release v5.38.1. You can install the new version using the version number or the latest-rc channel

$ sfdx plugins:install sfdx-git-delta@latest-rc
$ sfdx plugins:install sfdx-git-delta@v5.38.1

Happy incremental deployment!

[arafesthain]

@scolladon latest-rc is down for me on another point. Will open a bug