Hey there everyone, using the suitecloud cli, can I specify the

deploy.xml

file I want to use?

There's no flag for it in the cli

suitecloud project:deploy

I guess you could have different deploy.xml files and rename them so they don't get picked up and rename the one you want to deploy.xml. Not ideal but there's no flag.

Correct, there is no flag to specify the deploy file. We're dynamically generating ours on the fly based on

git diff

output. Could do something similar in your build chain just selecting from different preset files, renaming them to

deploy.xml

in the

src

directory (or equivalent)

Thanks lads! (Seems like this might be an easy feature-add to the CLI with powerful side-effects)

I'm curious about your use case

I have several. Here's one: I've have separated out automated testing scripts using a folder structure. I can then pick/chose how to deploy. Further, when it comes to packaging the solution for a SuiteApp, I can exclude the unit test.

couldn't you set that up in the deploy.xml to just not include the unit test files

Case 2: You cannot deploy a SuiteApp that contains an intergration record/Secret into the SAME account that the IR/Secret were created. So, I could exclude that in a deploy.xml as well

is it a pain to re-create the secret as part of the install? just throwing out some alternatives

Knowingly modifying the deploy.xml and remembering when\when ...

Oh cool so you've got actual NetSuite entry point scripts that are running automated tests? I'm spiking an effort like this right now

That's correct. I'm kinda loving it too. Seems more 'real' that mock testing.

We generate our deploy.xml file based on the files which have changed and their dependencies. Git diff is what we rely on for this. Comparing the release branch changes to main branch and using those files to build the deploy.xml. Then we also add the script files as objects if only the object file changes (as you can’t add scripts to manifest dependencies) We’ve also added to our pipeline checks for tags on a PR so we can modify the deploy.xml or which pipeline to execute. Very useful when working with 2 SB servers, a production server, and 3 SC instances. We also do unit testing, and only useful code is deployed as part of the pipeline by working with a build directory for what we are releasing. We do not include _tests in deployments.

We do similar as well, though not as sophisticated with the PR tagging. We dynamically generate the Objects in

deploy.xml

based on a

git diff

that changes its comparison points depending on whether we're in a feature branch or the

main

branch. We currently don't bother dynamically generating the Files list.

The advantage we’ve found of the build directory is that the package of changes to deploy stays consistent as it passes through 3 different stages of the release pipeline. It also means that tests can stay in the repo and be ran, but the package deployed is only the files we will be working with in SDF. It is also when we flatten the object tree to root directory where netsuite keeps them. We also use secret variables in our pipeline library to control which keys, etc, are used for deployment.

Yes similar approach to secrets/account IDs/etc here

Does the term "*spiking*" represent "suppression" or "elevation"? (asking for a friend)

Elevation 🙂 A "Spike" is like a research task or a small proof-of-concept build. It's not meant to be Production-ready, just to prove/disprove a question/idea.

Much appreciated. (My friend has already expressed his gratitude, as well.)

Your friend has good questions. Hope to see them around here soon.