Download the Gearset constructed package from CI job history when the CI job failed

Our typical use case surrounding related permissions for selected components (application visibilities, class accesses, field permissions, layout assignments, object permissions, page accesses, record type visibilities, tab visibilities) is to need to ensure that if a component is selected, its related permission is always selected also, with respect to a target set of profiles. We suggest you provide an affordance at the UI that selects related permissions en masse rather than requiring individual mouse clicks for each permission selection as at present.

Continuous Integration job to trigger when a Pull Request is Completed in Azure DevOps

When a developper deploy a new feature on a sandbox it will be perfect if the deployment can be auto deploy on a branch git (and copy the deployement note, etc).

Today I use a CI job backup on the sandbox but we lost the deployment comment + the updates granulartity.

We could use also the "Clone Button" on the result deployment page but it's lost time to relaunch the comparison and the different step etc while we want exactly replicate the deployment.

I was informed in my slack integration today that my CI job failed with an error message of UNKNOWN_EXCEPTION: admin operation already in progress See https://app.gearset.com/failed...

I would like to see Gearset automatically identify this type of error as something different than a metadata error and then retry that CI job 3 times over the next 90 minutes (for example). It would be fine for it to stop after those 3 successive failures.

It would be great if there is an automated approval process to deploy the code to higher environments. If there is a button "Submit for approval", and an email sent out to approver. that we can setup. once approved, a CI job need to run and deploy the changes to next environment.

It would be useful to see the meta data filter used on the deployment successful report

I would like a way for Gearset to create an immutable deployment package that can then be deployed to different orgs. This immutable package should contain a copy of the selected objects, list of unit tests to be executed and not allow variation in the deployment except selecting the target org. This would also save time by not requiring a new comparison to run for each target org.

The metadata API has a boolean option to "purge on delete", i.e. permanently erase deleted items rather than just moving them to the recycle bin. This option is not exposed in Gearset currently, but rather hardcoded to "false". For CI scenarios in particular, it would be extremely helpful to be able to specify that this option should be set to "true" for deployments.

CI job that run all test takes ages. Can we use scrach orgs and test suites to run test in parelell in multiple orgs?
https://developer.salesforce.com/blogs/2018/06/running-tests-5x-faster-using-sfdx-and-heroku-ci.html

We just came across an issue in which we were deploying an HTML email template that had been moved from one folder to another in the source environment.

When deploying, only the delete happened on the first deploy. I needed to do a second deploy to handle the addition.

While probably not a common case, it's certainly important as the initial deployment reports that the addition was successful.

Our CI jobs take way too long (1000+ tests) despite heroic efforts to use ApexMocks. As our org contains a bunch of unmanaged packages with known class name prefixes, and these constitute at least 10% of the total tests; we could get back 10% of our life if we could exclude these from the "run only your tests"

For example, we would want to exclude running any tests in classes that start with "fflib" and "sfab"

A variation of this would be to run a specific testSuite and it would be our responsibility to keep the testsuite up to date

Use case:

1. Deploy from source to target
2. Some testing (or possibly PR review) in target requires fixes to be redeployed from source to target

Currently, you either do a new Comparison or clone the Deployment and re-enter the source and target. In either situation this is tedious.

Why not add a "Redo" button on the Deployment History that uses the same source/target? Place it next to the Clone button?

Or, in the Clone button, default the source and target to the same as the selected Deployment? (which would also be useful)

When I do a deployment that is not a CI deployment, it can send an email. But the email goes out regardless if the deployment is successful. I would like to be able to send the email ONLY if the deployment is successful.

Download the zip package at an earlier stage before the analysis has taken place.
In big Orgs with multiple teams working the analysis page takes sometimes to load so it would be a great addition if we can download the zip package file and modify it.

We use Gearset as our primary utility for managing various client orgs include Production and Sandboxes for Testing and Release Management. It would be great if there was also a way to access, review and potentially enable/disable any Critical Updates in any org from Gearset.

However, I do understand that Critical Updates may not currently be accessible from the metadata API.

Just a thought,
Mike