Timer Delay Before First Trigger

[nickeeromo]

Is your feature request related to a problem? Please describe.

We have a setup where a pipeline generates a different pipeline with set_pipline (pipeline is not paused) to run unit tests for our projects applications. This is done with Webhook triggering from Bitbucket.

In the newly-generated pipeline, the git resource used for the tests may have several commits under it. However, we have an issue where perhaps all the commits aren't loaded before the test job triggers, thus, we may have 1 build failure (using an old commit) followed by 1 build success (using the newest commit).

Describe the solution you'd like

The best solution in my eyes would be to have a timer resource that triggers after an initial delay. For example:

- name: delay-timer
  type: time
  delay: 2m
  interval: 1d

So, once our pipeline is created, it would collect its git resources during the delay, then trigger at the end of the delay time specified, not firing again until the next interval specified.

Describe alternatives you've considered

I've tried a few things:

• Setting check_every on the time resource to 5m, still triggers immediately from set_pipeline
• Using version_depth: 1 on the git resource definition
• Using params: { depth: 1 } on the get step for the git resource

I've considered:

• If I don't use check_every, it seems the expected behavior would be to not trigger until the first valid time. For example, interval of 60m wouldn't trigger for the first time for 60m. If I wanted a delay using this option, I would select 2 minutes, but then of course the tests would trigger every 2 minutes (and the tests take longer than that to run, so not sure how that would affect things)
• I might be able to pass a variable to set_pipeline that would be 2 minutes in the future - then I could use that variable in the pipeline config to set the start/end time of a timer. However, this is probably not possible, or would be a complicated execution
• Instead of using set_pipeline, run a script that could set the new pipeline up programmatically, passing config variables so I could set up a timer with a start/stop time for 2 minutes in the future

That last option is what I'm leaning towards as a workaround for now, but a timer on delay would be so much cleaner.

Additional context

This is what the git resource looks like on a pull request to release:

Note that the first test that triggered was from a handful of commits ago, and that the one that passed was the most recent. And in order of the passing one to run, the failed one has to complete first as well. One may fail and the other may succeed, or both may succeed, but in either case it can take up to 2x as long for all our tests to run twice to be sure if the latest commit is safe to merge.