Simplify Project Deploy & Project Retrieve commands

[petter-eikeland]

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
project deploy start & project retrieve start should be simplified to project deploy & project retrieve

[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.

[git2gus[bot]]

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

[AllanOricil]

@petter-eikeland where did you find these commands? I cant see them. Im using 1.70.0

[mshanemc]

they're renames of the current sf deploy|retrieve metadata

[petter-eikeland]

@AllanOricil They are coming in 7.195.0, i.e. sfdx RC this week

[petter-eikeland]

Yeah, I would argue that it is more intuitive to write simply sfdx project deploy & sfdx project retrieve. Especially with the "legacy" sfdx force source deploy & sfdx force source retrieve in mind, it would follow the same semantics. In addition, it would follow nicely with the "extended" cancel & preview commands. Finally, it would remove a redundant argument/parameter that would save everyone a little bit of time

[jefersonchaves]

Is it envisioned to keep the pushPackageDirectoriesSequentially for project deploy start? That was a big help for some projects and seemed a breaking change.

[jefersonchaves]

Hey @mshanemc - That is fair enough. So, to make sure on the same page: are we saying that previously the push needed pushPackageDirectoriesSequentially and now we can push larger projects (over 10k files)? Should we only script to push in a specific order?

My use case was to push a large project that is placed among multiple folders.

Look, I'm happy if this is cleaning up a workaround that is no longer needed. I'm all for it if that is the case.

[mshanemc]

yeah, we're working on the comprehensive docs to discuss the nuances of the deploy, but the quick version is

you might have to start a project like this because of limits:
sf project deploy start -d folder1
sf project deploy start -d folder2
sf project deploy start -d folder3

but once you've done that, now imagine you change a file in folder1 and a file in folder2
push would do 2 very small deployments (assuming pushPackageDirectoriesSequentially)
sf project deploy would deploy all of it

The other thing this allows is the deploy order might not be based on pkgDirs. It could be any -d or -x or whatever (which takes multiple paths). push used pkgDirs for backward compatibility with the original CLI implementation. Since we were changing stuff,

[jefersonchaves]

Hey @mshanemc,

Thanks for the explanation. So, if I get you right we don't need this because deploy command also update the source-tracking. Is that right?

If so, I'm totally with you because it means that source is being tracked at all times independent of the command (pull, push, deploy or retrieve - my understanding is that now CLI is"merging" those commands).

[mshanemc]

yeah, there'll be 1 command for push/deploy/mdapiDeploy and 1 for pull/retrieve/mdapiRetrieve.

within the project deploy family, there's also the "accessory" commands (report, resume, preview) and then the validate/quick combo are separate.

tracking happens if 1) the org supports it AND 2) you haven't said you don't want it when the org was created.

[mshanemc]

Whole separate discussion around pushPackageDirectoriesSequentially here #2402

@jefersonchaves if you have some thoughts from working around this gap