The content of this article is moved to https://support.cloudbees.com/hc/en-us/articles/360032823292 .
ElectricCommander Course Video - Continuous Integration
Have more questions? Submit a request
Promoted articles
- Electric Cloud Maintenance End-of-Life Schedules
- ElectricFlow® v8.2 FR is now available from Electric Cloud
- ElectricFlow® 6.0.5 is now available from Electric Cloud
- ElectricFlow® v6.4 FR is now available
- KBEC-00421 - How to get server status information from multiple machines within your environment
- Release Command Center Drill Down
If you have an enterprise setup that includes shared build pools, creating separate EC Sentry schedules just for the purpose of specifying a project-specific default resource seems like overkill. With such a setup, making sure that the server-wide 'default' resource is changed from 'local' to one of the servers in the shared build pools is sufficient.
A better reason for separating groups of projects into different EC Sentry schedules is the long-time problem that happens when a CI schedule fails during an EC Sentry run. When one CI schedule fails, all the remaining schedules do not run. Imagine having a large part of your Enterprise-wide user base demanding to know why their CI schedules aren't running. Separating the projects into different EC Sentry schedules minimizes the fallout/impact of a failed CI schedule (albeit does not solve it).