As the owner of the CI job pipeline, I would like notifications when there are ongoing failures to the CI jobs that I select so that I do not have to continually monitor the jobs as a part of my day-to-day.

Acceptance criteria:

1. The current-state suite of notifications on CI jobs will still be available.
2. When a CI job has failed and the failure has not been cleared within X number of hours, the notification will be triggered.
3. Each CI job should have blocker notifications enabled separately.
4. Users will be able to select from SMS, email or both.
5. Users will be able to input a variable to indicate the number of hours that will pass prior the notification being triggered.
6. When the CI job blocker is cleared via a successful run, no notification will be triggered.
7. Organizations will be able to define the days of the week during which notifications should trigger.

We have 2 admins that we want to be able to create all of the CI and Pipeline Jobs, even if they don't have their own credentials in a particular Salesforce org. They have Deployment delegation, and can run compare and deploys, but not set up integration jobs.

This is then requiring us to either, provision extra licenses in each sandbox for our DevOps administrator, or have the developers create the CI jobs, which they are not comfortable with.

And, as we start the Pipeline Pilot, we would like to leverage all of the existing CI jobs, but, that is not possible, unless the same person that created them, creates all of the Pipelines.

For CI jobs, it is not uncommon that you want to include all elements of a given custom metadata type except specific elements

Today, you need to have two entries - an include all (".*") expression and an exclude expression. For users who are not regex savvy, this is too complicated.

We should have "All", "Named", and "All except Named" at the top level so simple check boxes can be used.

This is particularly useful for CI jobs (whose purpose is to sync VCS w/ org) - you want to sync most everything except a few items - like Sites and their Profiles that SFDC prevents from deletion.

Or to skip a bunch of irrelevant-to-you standard Objects that SFDC keeps adding every release

Gearset offers various automated jobs that run overnight e.g. Org Monitoring Snapshots, CI Jobs, Unit Test Runs.

it would be great to be able to set an ordering on how those run for any particular org. For example, a natural order for the night jobs may be:

1. Monitoring Snapshot
2. CI run
3. Unit testing

This means we have a backup before making any potential CI changes and the unit tests show the results after CI. It would also allow us to make sure that the jobs don't clash.

Ideally, we'd be able to do this without just specifying exact times to start each job because the length of time per job may change over time. I'd like to be able to just set the order, and maybe a start time for the whole sequence.

In the past we had troubles deploying reports via CI, they were not showing/deploying, the workaround was to enable the filter to include all reports. This works to solve that, but now I am looking at including more into the repo and start using delete actions in the CI jobs as well. The downside is that because we have to have all reports in the filter, the CI job will delete reports created by users in non-private folders. A freedom we want to give certain users in Production.

What would be an epic enhancement (and solve this challenge) is if you could decide to do delete actions per metadata type. Then I'd configure delete actions for everything except Reports and List Views for example.

When running CI jobs, we can create a problem analysis template to control what potential problems can block a deployment.

For deployments from SF orgs to Git, many of the problems being analysed are just irrelevant (e.g. users don't exist in the target, because the target is not Salesforce).

Although some options can be switched off via templates, the list is not comprehensive. So, it would be great to have an option to switch off everything, or a built-in template of "no analysis".

When production is the source of truth, we just want all the metadata to get copied into Git, no questions asked. Then we can enable problem analysis on the job for going back from Git to an org.