Better support for timed releases

Description

If teams at very large scale, it's impossible to deploy continuously on every push to master since new pushes come in at a faster rate than they can be deployed. For those teams, some kind of timed release is necessary. We can already support this at a basic level with scheduled pipelines. e.g. Set up a deploy every hours, every 8 hours, every day, etc. But perhaps there's more we can do. Release trains have come up, but it's possible to have more pushes than can be processed in a day. Auto-canceling redundant pipelines have come up, although our current answer doesn't work well if you've got capacity to run jobs simultaneously. Perhaps we need to be able to specify that only one pipeline should be run for a given project ref. Other vendors have this limitation/feature. We probably don't need to limit it for all projects and all refs, but running CI/CD on only one version of master at a time kind of makes sense. In the case of failures when there are a bunch of batched changes, perhaps we could automatically bisect to find the offending merge/commit, but otherwise we get to skip a lot of unnecessary compute. Ideally, we wouldn't have test failures on master because tests are already checked on each branch, but merge conflicts do happen and testing every check independently might be too cost prohibitive.

Also, maybe we need to differentiate what part of the pipeline we're talking about. Even if you do want to run tests on each push, your deployment rollout may take a long time and thus not able to run as frequently. Or vice versa.

Proposal

Links / references

Documentation blurb

Overview

What is it? Why should someone use this feature? What is the underlying (business) problem? How do you use this feature?

Use cases

Who is this for? Provide one or more use cases.

Feature checklist

Make sure these are completed before closing the issue, with a link to the relevant commit.

Edited by Mark Pundsack