Most of the times with our changes we trigger ~5-10 stacks and with rather fast feedback. But somewhat regularly we execute upgrades/migrations that trigger hundreds of stacks, for those we don’t expect fast feedback we are happy with those taking a while as we only have 5 workers.
The issue arises when we have both simultaneously, and if the ones triggered early are part of the 100s migration/upgrade batch then the rest will take longer to get feedback.
An approach is to prioritize the small batches. But it is not really efficient for us to prioritize every small batch that comes after a big batch.
Instead we would like to mark the big batches as `deprioritized` so that the of the stacks to be picked up would be:
- prioritized
- regular/default
- deprioritized
Please authenticate to join the conversation.
➡️ Planned
💡 Feature Requests
8 months ago
Get notified by email when there are changes.
➡️ Planned
💡 Feature Requests
8 months ago
Get notified by email when there are changes.