Permanantly pause pipelines

Follow

Comments

6 comments

  • Avatar
    Ian Bridson

    Hi Lee


     


    Have you tried using the <operate> permission set to Admin on the Pipeline so that no-one can trigger it apart from Go admin, but it can still be viewed? You could setup a 'Read only' pipeline group that has this permission set, and then move the pipleines into this group when you have finished with them


    I'm curious as to the reasons behind having a new pipeline for each release, rather than repoint the same pipeline to the new branch. Can I ask what are your circumstances that made you decide on this approach?


    Ian

  • Avatar
    Manoj

    To answer the last question on why have separate pipelines,  atleast from what we do on our project, we want to renme the pipeline to indicate what branch it is - like Product-Release1, Product-Trunk and so on. Since Go doesn't have the concept of renaming a pipeline, you will have to create new pipelines.

  • Avatar
    Ian Bridson

    OK, i see that you will need 2 pipelines to cover current Release branch and work on the Trunk, but are you saying that you would go as far as naming the pipeline after the Release version, e.g. Pipeline_Release1.0, Pipeline_Release1.1? Do you reuse a pipeline to deploy a Live patch from that branch, or does that get a new pipeline too?

  • Avatar
    LeeBenhart

    To answer your question, each of our products have a main trunk and multiple release branches.  So an example is we have productA_main, productA_2.0, productA_3.0, etc which are all indevelopment at the same time.  This means three pipleines in the pipeline group productA.  We build and release from the release branches, which are versioned and labeled at the time of build and then pressed to CD for final release. We then integrate these changes into our main trunk so other branches can pick them up as needed.  Obviously, after we have pressed, we do not want the build to ever execute again.


    I am creating pipelines based on our branching scheme, which seems to be the correct way to proceed.  We are new to GO, so this may change as we gain some experience and find other ways to do things.  The only time we would potentially reuse a pipeline which has reached the final release state would be to build a patch.  So we would need these to never build again except when triggered manually. Even config changes should not trigger a build in this state.

  • Avatar
    Ian Bridson

     Hi Lee


    Thanks for clarifying the situation for me. I think there is an alternative approach to creating new pipelines for each release, which may or may not suit your needs.


    If you called ProductA_2.0 'ProductA_Branch1', and ProductA_3.0 'ProductA_Branch2' so that it did not reflect the actual release version, and set ProductA_Branch1 to point to the repository Branch for Release 2.0 initially, and ProductA_Branch2 to Relase branch 3.0 to start with as you do now. Also set the Pipeline labels to 2.0 & 3.0 respectively. Then Release 2.0 and 3.0 will be the same as you described, but the difference would be that they have a version displayed matching the Release version rather than a name that matches. Then when you have released 2.0 repoint the repository of ProductA_Branch1 to Release 4.0 branch and change the Pipeline Label to be 4.0. Do the same for 3.0 to 5.0 and so on. This way you only have two pipelines displayed in Go at any time and an audit trail of released verisons within these pipelines, which includes the repository location that the build was taken from. so I don't think you lose anything and would save you the hassle of having to hide or pause pipelines once they have been released.


     


    Ian

  • Avatar
    LeeBenhart

    Nice idea, and I have considered such an option, but I am not sure it is not going to work in our environment.  We sometimes have to resurrect these to apply patches or localization changes.  I am not ruling it out, but seems unlikely.  Iw ould still like a way to mark a pipeline as inactive so it cannot pick up changes in the future.

Please sign in to leave a comment.