Add support for diffcheck parameter in validateAgainstOrg command

[jhawk-4]

A recent update (#759) disabled the diff check in the validateAgainstOrg command. For those organizations that have yet to migrate to scratch orgs (for all the various reasons that exist), it would be helpful to still use the validateAgainstOrg command and have a --diffcheck parameter similar to build and quickBuild. The command can still default this to false, but for organizations that depend on sandboxes for validation, it helps to skip untouched packages to speed up the validation process.

[azlam-abdulsalam]

Linking to #680

[azlam-abdulsalam]

@jhawk-4 Was this option helpful? We had more issues especially when used with a pull/merge request validation, as we get a temporary merge head, which after a successful validation gets updated to the org, but subsequently will not be available resulting in a failure, as we wont be able to compute diff. How are you using it?

I am thinking of alternate approach such as checking whether the commit is reachable, if not deploy the package @aly76

[jhawk-4]

In our case it is helpful just for the speed of validation. We are trying to break our packages down and are increasing the number as we do, but a full validation run of all of our packages can take up to three or more hours. With several developers opening MRs throughout the day, it can create a log jam. There have been times that we end up with an unreachable commit. We usually end up removing the commit ref for that package in the custom setting when it happens. I think having the parameter is useful for flexibility, but agree that automatically deploying the package if the SHA is unreachable would also be a nice addition.

[azlam-abdulsalam]

Doesnt each PR will result in unreachable commits? effectively nullifying the speed boost?

[jhawk-4]

I believe we have not been affected as much by this because of our CI environment setup. We have a persistent VM that operates as our GitLab runner. It is not a container based image that is tossed at the end of each validation run. The workspace is being updated by a fetch and the best I can tell the remote branches are not being pruned. I thought by defaulting the parameters based on the type of validation (scratch orgs the diffcheck is true by default, sandboxes the diffcheck is false by default), then users could adapt the commands to best fit their CI environment. This may not be a useful feature for everyone, so I understand if it doesn't make the priority cut. Also, validation with sandboxes is not our ideal end state either, but we are still working to get beyond that.