You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow for faster builds by pre-provisioning a pool of scratch orgs with all dependencies from the master branch preinstalled. Some thoughts on how this would work:
Add a new dependencies flow to CumulusCI that does everything from dev_org up to the deploy task. This flow would effectively install all the project's dependencies. For NPSP, it would preinstall all the underlying managed packages.
New worker task to spin up orgs and run the dependencies task against them. When that provisioning completes, the ScratchOrgInstance gets added to a pool for the org.
When a build runs, it will try to create an org from the pool. If the pool org available, the build will run against the org. In most cases, the build's dependencies will be the same as master. In this case, the update_dependencies task will run much faster since the correct versions are already preinstalled. If an org is not available from the pool, the build would provision its own scratch org as it currently does.
We would need some way of recording the log from the dependencies flow execution and scratch org creation. This probably shouldn't be a Build as it's more a background convenience thing.
Background scheduled jobs would be used to delete pool orgs older than 5 days and to
We'd need to figure out how many orgs to pre-provision like this. It could be either a manual setting or potentially a calculated job based on the build load of a given project. It's probably something we'd want to be able to select for individual repositories. For example, it's very important for NPSP since it depends on 5 managed packages, but it's not as critical for CampaignTools that doesn't depend on other managed packages.
Allow for faster builds by pre-provisioning a pool of scratch orgs with all dependencies from the master branch preinstalled. Some thoughts on how this would work:
Add a new
dependencies
flow to CumulusCI that does everything fromdev_org
up to thedeploy
task. This flow would effectively install all the project's dependencies. For NPSP, it would preinstall all the underlying managed packages.New worker task to spin up orgs and run the
dependencies
task against them. When that provisioning completes, the ScratchOrgInstance gets added to a pool for the org.When a build runs, it will try to create an org from the pool. If the pool org available, the build will run against the org. In most cases, the build's dependencies will be the same as master. In this case, the
update_dependencies
task will run much faster since the correct versions are already preinstalled. If an org is not available from the pool, the build would provision its own scratch org as it currently does.We would need some way of recording the log from the
dependencies
flow execution and scratch org creation. This probably shouldn't be a Build as it's more a background convenience thing.Background scheduled jobs would be used to delete pool orgs older than 5 days and to
We'd need to figure out how many orgs to pre-provision like this. It could be either a manual setting or potentially a calculated job based on the build load of a given project. It's probably something we'd want to be able to select for individual repositories. For example, it's very important for NPSP since it depends on 5 managed packages, but it's not as critical for CampaignTools that doesn't depend on other managed packages.
This is based on an idea from @cdcarter
The text was updated successfully, but these errors were encountered: