Related to CI jobs can you set up multiple jobs to trigger based on which user did the commit to source control? The goal would be having the deployment / last modified dates in SF reflect which user did the commit in source control and triggered the CI job.

I don't think that's possible as I don't see any kind of filter or way to manage which CI job should fire when source control is updated so the audit history in SF will only reflect one specific user doing the deployments and people would need to review the details in source control to find out who did the commit today from what I am seeing. Having the ability to trigger different CI jobs or changing the targets based on the user who did the commit in source control would be really helpful to improve audit tracking in Salesforce on who did the deployment via CI job vs only relying on auditing in source control (even gearset can't tell us who triggered it at this point either). Thanks!

SFDX officially supports tracking of source within the same package in more than one folder. The "standard" folder may be used, but you are also able to create a folder hierarchy that's more akin to a "modularization"

It can for example look like this:

force-app (any names goes here)
-> main
--> default
----> aura / classes / pages
-> module1
--> aura/classes/pages
-> module2
--> aura/classes/pages

Currently, only the metadata inside the force-app/main/default folder is seen. It would amazing if git integration could take other folders into account too. Both for Deployments from and to Git (for a deployment to Git, you would need to select the destination folder beforehand)

Currently, if you have a CI job set up to validate based on events (push, pull request) on a specific branch the following occurs:

You open a pull request against the specific branch noted in the job - CI validation runs
You push a commit to the source branch of the same open PR - CI validation runs
You push a commit to the target branch of the same open PR - no validation runs

In the conversation with Dan on 8/13/2020, I was told this is by design on Gearset's end (to ignore that situation) to avoid long queued validations. While I agree with that decision, it'd be great to at least have the option to choose this behavior (whether to run or not) as a setting while creating the CI job.

Similar to Unit Test jobs for connected Salesforce orgs, it would be great to have independent Dependency Cleaner jobs for our source repos to help identify problems separate from any particular commit.

In our flow, not every commit goes through Gearset, so it's possible that our repo could become "undeployable" as a result of these non-Gearset commits. If this occurs, it then comes confusing on the next Gearset commit since the Dependency Cleaner will add all the deletions it deems required which don't relate at all to the PR being reviewed.

A the end of the day, we'd like our PRs to be limited only to the changes being made for that feature or bugfix, while also leveraging the Dependency Cleaner to be keep our repo healthy.

Currently the deployment report that is attached to the Jira ticket includes all "No Difference" components which I don't believe provides any real value. In my instance, this includes endless amount of pages, from what I can tell the changed values I'm actually looking for don't actually exist. I would suggest either excluding from report all together or providing a summarized statement that is just a grouped item for all items that were included in deployment but had no change. Also the report should bring the actual changed items to the top of the report like it is on the web report I saw after the deployment completed successfully.

Currently, you can create a PR after a successful deployment in Gearset. You're able to provide a description and even select it as a draft.

However, the only potentially necessary field that's missing is "reviewers". This means any CI/CD setup you have that requires an approval requires the user to go into Github just to add the reviewer.

Since Gearset would have all the team members (and those with linked github accounts), it seems it might be an opportunity to select based on that list and pass the linked username on to github in the PR creation to keep end users fully in Gearset throughout their work.