Execute Pipeline Stage Less Frequently




  • Avatar
    Vogen, Kirk (STP)

     One possible way to implement #2 is to have two pipelines. The stages to run for all change sets will be in the first pipeline. The stages to run less often will be in the second pipeline. The second pipeline is dependent on the first. In the second pipeline, its first stage will be set to be manual. A timer could be used on the second stage to start the pipeline on the desired frequency. The timer should have the effect of starting the manual stage.

    The idea comes from this post.

    I'll have to try that and see whether it works. The downside is that there won't be one pipeline to show how the various stages went. You'll have to navigate between the status of both pipelines to get the overall picture.

  • Avatar
    Vogen, Kirk (STP)

    It turns out that I probably don't need to execute a pipeline stage less frequently. It looks like Go will take care of it for me. Consider a case where you have a commit stage followed by a longer running acceptance test stage. When the current acceptance test stage completes, Go will start the acceptance test stage from the most recent pipeline pipeline. And, it won't attempt to run the acceptance test stage of any running pipelines between them. In effect, you get a stage running as frequently as the servers can handle.

    See attached PDF for more details on this scenario.

Please sign in to leave a comment.