Add support for check/verification deployment for force:source:deploy

[keirbowden]

Is your feature request related to a problem? Please describe.
I'd like to be able to carry out a verification (checkonly) deployment using the force:source:deploy subcommand.

Describe the solution you'd like
After carrying out a bunch of work against a scratch org, I'd like to be able verify the changes against a sandbox without actually deploying them. Ideally I'd also like to be able to execute unit tests so that I can be fairly sure that my new code doesn't break anything.

Describe alternatives you've considered
I convert to metadata API format and deploy that, as it allows me to carry out a verification and execute unit tests.

Additional context
N/A

[lcampos]

@keirbowden were you thinking about enhancing the current deploy commands to be able to define these parameters when needed or having a new deploy & check only command be what you are looking for ?

[keirbowden]

@lcampos I was thinking of it being added to the current deploy commands, bringing them more in line with the mdapi deploy command.

[dcarroll]

Hey @keirbowden , we are in the process of reworking deploy and retrieve. Actually, wouldn't mind getting your feedback on the plans.

Essentially, we are going to default to maintaining the source file folder layout for all commands. We will be adding a flag to override the default in the off chance that you would want to work with the older project file format.

1. We are going to add the additional selectivity options to mdapi:deploy/retrieve that are available on source:deploy/retrieve. Since this make the source:deploy/retrieve redundant we will be deprecating those.

2. mdapi:convert will be renamed to project:import and have the additional selectivity options added and mdapi:convert will be deprecated.

3. source:convert will be renamed to source:export and have the additional selectivity options added source:convert will be deprecated.

4. A source:delete command with selectivity options will be implemented.

[abd3]

Great to hear about that @dcarroll. In particular, adding those selectivity options is important since it will allow teams to do things like pull down a package.xml relating to an unmanaged package and then convert just that subset of files out of metadata API format and into source format (or vice versa).

One thing to consider would be a 'move/destructive' conversion as a flag so that if a team does a partial import/export it will actually remove the original metadata after creating the converted metadata. That will provide an easy way for teams to, say, extract a single field out of the Account object into source format, without having to manually remove a chunk of XML out of the mdapi format.

[keirbowden]

@dcarroll that sounds good - fewer, flexible commands gets my vote over a command per scenario. As long as I have a mechanism to switch to the project file format then that's fine - I have scripts that manage the low-level commands to build the artefacts and carry out the deployment, so my developers don't need to worry if things change at the CLI level.

[sunnymatharuuk]

@dcarroll I'd be interested to hear where you guys are with the CLI rework.

Going back to Keir's original ask, we too require a --checkonly or similar argument for force:source:deploy to sandboxes.

At the moment, we are having to force:source:convert to mdapi format, and then do a force:mdapi:deploy ... --checkonly

[jorupp]

It looks like --checkonly is a available on source:deploy now, but I can't find a way to set that flag via the VSCode extension - is that planned as well, or am I just not finding the way to do that?

[svc-idee-bot]

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