Add a polling frequency flag for the sfdx force:mdapi:deploy command

[ChaseBowen]

Is your feature request related to a problem? Please describe.
We have hit API limits when running a long-running sfdx force:mdapi:deploy -w -1 command. It seems like the value is set at 500 milliseconds as of current, https://github.com/salesforcecli/plugin-source/blob/main/src/commands/force/mdapi/deploy.ts#L177. It would be nice to have a flag to change this value to avoid using more api calls unnecessarily.

What are you trying to do
Avoid API limits by reducing polling frequency (allowing us to specify polling frequency)

Describe the solution you'd like
I would like a flag to be available to specify the polling frequency of the poll under the hood of the mdapi:deploy command instead of having to break out the deploy and poll ourselves. It would be nice if the polling frequency was included as a flag in seconds? milliseconds?

Describe alternatives you've considered
Breaking out the commands into a sfdx force:mdapi:deploy and a sfdx force:mdapi:deploy:report and polling ourselves with sleep commands

Additional context
Add any other context or screenshots about the feature request here.

[git2gus[bot]]

This issue has been linked to a new work item: W-12550015

[github-actions[bot]]

Thank you for filing this feature request. We appreciate your feedback and will review the feature at our next grooming or sprint planning session. We prioritize feature requests with more upvotes and comments.

[mshanemc]

Oh, that's a good idea. The source:deploy commands calculate the freq based on the size of the deployment, but mdapi might not have that (ex: deploying zip files).

Out of curiosity, why do you use mdapi:deploy ?

And would an env be as good or better (that way it would cover both the deploy/report and other tooling (vscode, sf, etc)

[Kevmo92]

Hey @mshanemc!
We use mdapi:deploy for deploying to our packaging org. There are a few reasons we cannot use a source:deploy to our packaging org but that might be due to bad habits.

We need to specify a POST_INSTALL_CLASS in the package.xml file so that each package version has the post install class set.
We also inspect the package.xml, that's been generated by sfdx force:source:convert, before deploying to the packaging org to remove any Custom Objects or Workflows that are namespaced ("\w+(__)\w+(__c)$").
Finally we have to remove any Approval Processes that are in the package.xml.

Is there a better way for generating a package.xml? Maybe we could use the source:deploy and specify the package.xml manifest 🤔

[daveespo]

@Kevmo92 -- do you change the actual class that implements the InstallHandler from version-to-version of your package? You should be able to follow https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_install_handler.htm and just add conditionals to specify what happens based on the prior version and the new version -- that means you can just set it once in the packager org UI and forget it

We use source:deploy with the -m package.xml flag to specify the package.xml to use -- we use mostly wildcards in the package.xml so that it doesn't require a ton of maintenance over time.

Plus if you convert your project to source format (from metadata format) you get the benefits of the deconstructed metadata files for things like SObjects and the ability to reorganized your other metadata into a logical folder structure.

[Brian-Triplett]

@mshanemc other than polling optimizations, are there other benefits to source deploy versus convert and mdapi deploy? Is it faster per chance?

[mshanemc]

it's much faster than a source:convert followed by a mdapi:deploy and you have options

• doing some string replacements?
• --tracksource to avoid overwriting someone else's changes and so that your org is ready for push/pull operations
• pre and/or post destructiveChanges

[Kevmo92]

@daveespo We typically don't change the actual class name/contents for the post install that much. Usually it's set and never changes. I'll take a look at https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_install_handler.htm to see if we can set that option in our packaging orgs. That would get rid of one hack 🤷

Our code is in source format in our version control system. We convert it to mdapi format to deploy to old developer orgs (not scratch orgs) where we package (classic 1gp packaging).

[daveespo]

@Kevmo92 -- yeah, that's what we do too and have never looked back from using source:deploy .. it works just fine for 1GP and classic DE orgs

[cheyenneralston-ncino]

@mshanemc Curious what, if any, flags you're using with source:deploy that you're seeing significant time savings from source:convert and mdapi:deploy. I tested both using one of our packages and didn't see a difference >30s.

[mshanemc]

@cheyenneralston-ncino That's fair. There's nothing to be done about the time it takes the mdapi to deploy your code--that's unmovable and is the largest chunk by far, and by ignoring that part I'm ignoring the bulk of the time.

Having to run 2 separate commands and touch every file in the project 2 extra times is where the performance improvements happen.

[mshanemc]

project deploy start has the --async flag which I think opens up the "you can manage polling how you want to" (like the post suggests, via sleep, etc). Combined with project deploy report and project deploy resume it's pretty manageable.

The default polling on the new commands is based on the size of what you're deploying and the defaults seem reasonable. Using source format instead of mdapi gives you those benefits.