I agree I need to use logic to stop or allow a stage, but I don’t know how to target the git branch or what options I have for developing that logic so I can stop the chain if the branch being built isn’t the master branch.
On March 29, 2017 at 6:06:14 AM, Richard Ginga ([email protected]) wrote: I do something similar in that I have conditional stages. Simply put logic "around" the stages you do or do not want to run. In order to keep the full list of stages in the job's dashboard, I actually put the logic "within" the stage that says "Skipping stage blablabla". I don't use Git so I don't know what information you need/have to make this decision. On Tue, Mar 28, 2017 at 6:32 PM, Michael Holley <[email protected]> wrote: > I've been searching all day today and have yet to find something that > looks like it applies. I'm sorry if this answer has been hashed before and > I just asked the all mighty Google the wrong questions. > > Here is the workflow I'm trying to bring over from my freestyle projects > as Pipelines (the new Pipeline project is set up as a Multi-branch project > with a Jenkinsfile). > > 1. A dev branches off of master and starts work on a feature. Whenever he > pushes new code to GitHub I want Jenkins to set up the workspace, build the > code, run tests, and then stop. > 2. Once he get's his code to build clean he creates a PR. > 3. Jenkins sees the PR and builds that, but once again, should stop after > tests pass. > 4. The success status, after tests, is pushed back to GitHub which then > enables the PR to be merged with the master branch. > 5. Now that the master branch has been updated, Jenkins once again sets up > the workspace, builds the code, runs test, but now deploys to staging, > waits for approval, then pushes to prod. > > Another way to ask the question, how do I put logic into a Pipeline to > only run certain stages depending on what branch/PR is being built? > > As of right now, I have a single Jenkins file with the checkout, build, > test, and deploy stages in it, and every time a branch is updated, a PR > created, and with a merge to master, the code is able to be deployed. I > don't want the code to be able to be deployed until after it's merged to > master. Any thoughts on how to make this happen? Thanks. > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/jenkinsci-users/2615c315-9686-4f70-975c-364f065000f2%40googlegroups. > com > <https://groups.google.com/d/msgid/jenkinsci-users/2615c315-9686-4f70-975c-364f065000f2%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Dick Ginga Build Engineer [email protected] -- You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/7-tK3JTtFCU/unsubscribe. To unsubscribe from this group and all its topics, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAL3PpaVGPZykSV%2BQv_UChw4NiXx3-rMf1Rfe%2BSn5X-XUcEizSw%40mail.gmail.com <https://groups.google.com/d/msgid/jenkinsci-users/CAL3PpaVGPZykSV%2BQv_UChw4NiXx3-rMf1Rfe%2BSn5X-XUcEizSw%40mail.gmail.com?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAL0jAia9mPhnPUgeXf0n5CUALc%3DqThq7Y572fvekgGM5xhQAGg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
