Every week we have a larger sized scheduled deployment for logic updates that runs after business hours. There's usually the same 2-6 people (often increasing) that want to receive an email and/or text message when the deployment succeeds. Whoever schedules the deployment has to add each one manually every time, and it would be nice to have a way to send notifications to a predefined list or group of email addresses and/or phone numbers.

It usually has to be the person that schedules the deployment, because if someone goes back to add their own email or phone to an already scheduled deployment, they have to reschedule it which can leave room for potential user error or confusion.

Currently when a PR Validation fails (Deploy CI Job with Validate Target setting turned on), the user can click the Gearset "Details" link to go into Gearset to see the exact error.

Many of our devs use VS Code and Github for their daily work and only rely on Gearset for the CI job. Having them jump into Gearset just to see the error is time consuming and not very intuitive for them. Sure we can find the same errors within the target org of the CI, but at that point the list of validations is large and it's hard to find.

If we could have the CI job trigger a comment on the PR of the Success or Failure (with errors or at least first 10 errors) then our developers could have a smoother time staying within Github.

Gearset currently uses OAuth to connect to GitHub, and the way that works is that the OAuth connections have permissions to all repositories that my user has access to, which from a security perspective is a problem, because if the github key were ever compromised, it would provide very broad access to customers GitHub organizations.

Security teams would feel much better with the ability to limit the scope of access to just one repo instead of all the repos that my GitHub user has access to, which can be accomplished by creating a Github App which can be installed for an individual repo.

Quote from GitHub docs: "GitHub Apps are the officially recommended way to integrate with GitHub because they offer many advantages over a pure OAuth-based integration"

https://docs.github.com/en/developers/apps/getting-started-with-apps/migrating-oauth-apps-to-github-apps

https://docs.github.com/en/developers/apps/getting-started-with-apps/differences-between-github-apps-and-oauth-apps

Hi All,

We are looking for a SCA feature so that instead of showing all the errors and warning in the whole file while doing compare or deploy, It Should only show the SCA errors and warning for the last commit or for commits during an specific time interval.

For Example I have an existing Apex class which is having 1000 lines of code and say 100 errors are there as per GS SCA analysis. Now let’s assume I am working on that file for my current sprint and I am adding another 100 lines of code in that class. Now after doing the compare and deploy the SCA should give me the errors and warning for the latest 100 lines of code and not for the complete file.

Regards
Shahnawaz

When deploying from SF to a branch that has the force-app and unlocked packages, if you deploy an item that would include the object file it deploys to the unlocked package directory instead of the default app listed in the project.json. The end result is everything related to the object is moved from the force-app to the unlocked package directory.

Steps to recreate:
Enable source tracked sandboxes
Create a new dev sandbox
Create a new branch and link it to the new sandbox
Create a new field on Contact
Edit a search layout on Contact
Use gearset to deploy the new field and search layout from sandbox -> branch
Note the Contact object file (this is where the search layout metadata is) and the new field are deployed to the force-app directory
In VS Code using SFDX, reset the tracking
Create another new field on Contact
In VS Code using SFDX, create a new unlocked package
In VS Code, set the new unlocked package to default in project.json
In VS Code using SFDX, do a pull (this should put the newest field in the unlocked package directory)
In VS Code, set the force-app to default in project.json
Commit and push the changes in VS Code to the remote branch
In SF, edit the Contact search layout again
Using Gearset, deploy the Contact search layout to the branch

Outcome:
The 1st new field and the Contact object file are moved to the unlocked package directory even though the force-app is the default app

Expected result:
The Contact object file in the force-app directory is updated