Issue with the package.xml for einstein bot deployment

[sairohith1009]

Issue verification check:

• is the current repository fully deployable at the commit SHA provided with the 'from' parameter of the command? : yes

What is the problem?

We are trying to deploy einstein bot for the first time via GitHub Repo using this SGD plugin.
when doing the validation we are facing an issue with the component.
error : bots/CA_ChatBot.bot (CA_ChatBot.v2) -- Error: Not in package.xml

package.xml which is getting generated during the run time :

---

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

What is the expected result?

What is the actual result?

Steps to reproduce

---

Execution context

---

Operating System: …

yarn version: …

node version: …

git version: …

sfdx version: …

sgd plugin version: …

More information (optional)

---

[scolladon]

Hi @sairohith1009 !

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

I wonder if it is because the package.xml miss the bot version...

Can you tell me more about this issue ?
What is the output of this command? git diff --name-status --no-renames <from> <to>
What is the expected result ?
How can I reproduce it locally the simplest way ?
What is the context? uname -v ; yarn -v ; node -v ; git --version ; sfdx --version ; sfdx plugins

[sairohith1009]

Can you tell me more about this issue ? :

• we have created a einstein bot for business requirement
• as this is the first bot that we created , we have created a folder called bots in the repo.
• we have placed this bot metadata component in the bots folder.
• then we triggered a build
• we can see the delta folder is getting created with bots folder in it and also the package.xml with the list of changed components.
• while using this delta folder for validation , it is failing with the error : bots/CA_ChatBot.bot (CA_ChatBot.v2) -- Error: Not in package.xml

What is the output of this command? git diff --name-status --no-renames :

What is the expected result ? : we should get the package.xml getting created with the bot folder and bot component in it and no validation failures.

How can I reproduce it locally the simplest way ?

• create a einstein bot in salesforce, retrieve the code of it
• place the folder in folder structure
• start the validation
• execute : echo y | sfdx plugins:install sfdx-git-delta@v5.11.3
• execute this command to create delta folder : mkdir -p Delta_pkg/
• execute this command to generate the delta folder : sfdx sgd:source:delta -t HEAD -f d49eed75f675fdfa723afa72a7865783d37098b3 --output "Delta_pkg/" --generate-delta -a "52.0"
• trigger the validation using this delta folder.

What is the context?
uname -v : 2019-04-30 21:52 UTC
yarn -v : yarn is installed
node -v : v20.5.1
git --version : git version 2.22.0.windows.1
sfdx --version : sfdx-cli/7.209.6 win32-x64 node- v20.5.1
sfdx plugins : sfdx-git-delta@v5.11.3

[scolladon]

Ok, thanks for all the information.

I need one more information:

• Is there a .botVersion file somewhere ?
• Does the repository is fully deployable ? Or do you have the same issue when deploying everything all together ?

[sairohith1009]

Hi @scolladon
Is there a .botVersion file somewhere ? : No, but we have .bot file
Does the repository is fully deployable ? : No, we are following delta deployment only.
do you have the same issue when deploying everything all together ? : we are facing this issue while deploying the Bot

[scolladon]

@sairohith1009,

I asked if there is a .botVersion file in the repo because, base on the error message in the issue, it seems the metadata API requires it:

bots/CA_ChatBot.bot (CA_ChatBot.v2) -- Error: Not in package.xml

We fixed a similar issue (#219) by adding the related version file every time the bot file is changed (and vice versa).
If this file is not present then it is not copied by the plugin.
As the error mention CA_ChatBot.v2 that make me think this botVersion file is not versioned.
And so the plugin cannot copy it.
So maybe your issue is the version file is not present in the deployment. The plugin only knows what is in the repo, not what should be deployed, it is not its responsibility to make sure it is deployable.

And this is why I asked if the repo is fully deployable. If it is not the case and if the error is the same then the issue is not from the scoping done by the plugin, but from the versioning.
If you could try a validate of the repo and see if you have the same issue then we will know it comes from versioning.

One last thing, I highly recommend you to use the @latest tag version for the plugin.
We have implemented a more robust way to ship our package since v5.4.0.
Information available here
version 5.11.3 is behind the current @latest (v5.25.2) version

[mcarvin8]

To preface, I personally haven't used this plugin yet to create a delta package for a bot deployment. But I do have plans to implement this plugin into my work repo in the future which has Bots so it will affect me at some point.

But, something I learned through some trial and error with manually deploying Bots through the CLI was that most of my issues deploying Bots were resolved by just using the 'Bot' metadata type and omitting the 'BotVersion' metadata type entirely from the package.XML.

Especially when you start adding intent sets to the Bot, which will show in the overall Bot meta file and the version specific file.

Main obstacle I saw was that you need to manually disable the active bot version in the org, if one is active, before deploying this way. The CLI doesn't automatically disable active bot versions in the org before deploying. Change Sets appear to do this based on tests with the CLI and Change Sets.

In terms of this Plugin, I would recommend just using the 'Bot' metadata type and detect changes specific to the Bot folder. If any file under the Bot folder changed (whether it's 1 version file or the overall bot meta file), I would say the plug-in should just look at the relative folder name and use the 'Bot' type to ensure everything gets deployed.

Any retrievals from a sandbox org into a Git branch would need to use the 'Bot' type to ensure all changes are captured. Obviously it adds the manual pre-deployment step with deactivating any active bot versions, but I have not found any better way to deploy Bots using the CLI.

[scolladon]

Hi @mcarvin8,

Thanks for this detailed explanation of how it works. Very clear.

Today the plugin behave the following way with bots:

• If a .bot file is added / modified then only this file is copied
• If a .botVersion file is added / modified then the related .bot file is included as well

If you want the .botVersion file to be included as well when changing the bot file then the new .botVersion file should be tracked in git for the same revision.
If you don't want the .botVersion file to be included then don't track it on git (or use a .sgdignore file with the -i parameter).

I think this behavior of the plugin support your suggestion.

From what you said it seems the deployment will still need a manual task pre deployment.
I think it is possible to automatize it, the Bot object does not seems to be exposed via Tooling API so it means it needs to be done via Metadata API, but I don't think it is the responsibility of this plugin.

[mcarvin8]

Thanks @scolladon. Yea I agree the behavior of the plugin in regards to bots is good as-is. I think I'll look into the .sgdignore file on my end so that's good to know that's an option for my use case.

I agree that the plugin shouldn't be responsible for disabling the active bot version via the Metadata API before deployment. That's something I'll probably submit as a feature request on the Salesforce CLI repo.

[mcarvin8]

Just to update this, I did just figure out a way to get around the Pre-Deployment step of de-activating the active bot version before deploying through the CLI.

You can just update the .forceignore file with the path to the active bot version like this and this is one way to deploy the Bot using the Bot metadata type in the package.xml while having an active version in the org.

# Ignore active bot version
**/bots/Test_Bot/v19.botVersion-meta.xml