Allow other Enterprise Users who do not own the CI Job to run it
Enterprise Users can only "Run Now" Jobs that they own. If the Source and Destination Org are shared, allow other enterprise users to run the job.
Audi Maddali commented
This feature will be useful if there are multiple release team members working from different Geographic locations.
Also, I can have one CI job for CI environment based on commit, can have another CI job to TEST environment (has to be manually triggered when I want to push changes to TEST).
You might consider to implement the sharing at a CI job level since we might not want to share the GIT credentials, we wouldn't like people committing changes to repo on behalf of another user. That's what will happen if the sharing of the GIT credentials is required to be able to run a CI job.
In our case, we want users to be able to retrieve metadata and commit their changes to the repository but not to deploy these changes from the repo to another org because, often, people make mistakes selecting a different filter or API version. We avoid that if they have the possibility to run a specific job to have their changes deployed from the repo to the org desired, ensuring that the correct settings are used.
It should be possible to share CI jobs regardless the credentials behind instead of having to grant access independently to each team member both source and target credentials. It would be nice to have the possibility to share the job with all team members easily or select some of them no matter the licence either, what would you make a difference between Pro or Enterprise?
Currently, this idea was announced as a release change already done but the current implementation doesn't represent what this idea should be since, at the moment, you can just share a CI job that are ORG to ORG, not GIT -> ORG (since you can't share GIT credentials at the moment).
Why would you not be able to run a CI job? Lets take this scenario. Co-worker creates a CI Job that sends changes from git to a central Salesforce sandbox. This run automatically when changes are merged from the Pull Request. But say, that build fails to deploy for one reason or another, and that person is on Vacation for the week? We can no longer kick off those CI Jobs that we are dependent on. I don't see how this is not something that is standard functionality.
At least have an option where you can grant permission to users to give the ability to run specific jobs they do not own.
We are using manually push CI jobs that we keep in disabled mode. By disabling them, it allows us to keep a deployment with a set filter and deploy when we best see fit.