Skip to end of metadata
Go to start of metadata

Summary 

This plugin provides a Build Pipeline View of upstream and downstream connected jobs that typically form a build pipeline.  In addition, it offers the ability to define manual triggers for jobs that require intervention prior to execution, e.g. an approval process outside of Jenkins.

Plugin Information

View Build Pipeline on the plugin site for more information.

Release Notes

1.5.8

  • (minus) Address boundary case of JENKINS-23532 where relative paths would not retrigger

1.5.7.1

  • (-) JENKINS-45137 Fix stack trace for pipelines created / edited in v 1.5.6

1.5.7

  • (-) JENKINS-23532 Manual trigger execution causes TriggerException
  • (-) JENKINS-44324 NullPointerException upgrading from very old versions of plugin
  • (-) Fix issue with dashboard view not loading
  • (+)Added support for extensible BuildCard

1.5.6

1.5.5

1.5.4

1.5.3.1

  • (minus) Issue #33935 Fix re-running a build - broken in Jenkins > 1.653, LTS > 1.651.1
  • (minus) Issue #34722 Performance fix - limit the number of downstream projects iterated over

1.5.2

1.5.1

1.4.9

  • (minus) (issue #30801) Re-triggering a failed build copies the Actions from previous builds
  • (minus) (issue #28068) Build Pipeline Dashboard View destroys layout of jenkins
  • (minus) (issue #29477) View bad for Build Pipeline Plugin

1.4.8

  • (minus)  (issue #28180) Build Pipeline background layout does not extend full width of pipeline

1.4.7

  • (minus) (JENKINS-25666) Fixed left-side indentation for new jenkins versions

1.4.6

1.4.5

1.4.4

1.3.3
1.3.1
1.3.0 - Also see the roadmap for details.
1.2.4 - Also see the roadmap for details.
1.2.2
1.2.1
1.2
1.1.2
1.1.1
1.0.0

Overview

Continuous Integration has become a widely adopted practice in modern software development. Jenkins & Hudson are great tools for supporting Continuous Integration.

Taking it to the next level: Continuous integration can become the centerpiece of your deployment pipeline, orchestrating the promotion of a version of software through quality gates and into production. By extending the concepts of CI you can create a chain of jobs each one subjecting your build to quality assurance steps. These QA steps may be a combination of manual and automated steps. Once a build has passed all these, it can be automatically deployed into production.

In order to better support this process, we have developed the Build Pipeline Plugin. This gives the ability to form a chain of jobs based on their upstream\downstream dependencies. Downstream jobs may, as per the default behaviours, be triggered automatically ,or by a suitable authorised user manually triggering it.

You can also see a history of pipelines in a view, the current status and where each version got to in the chain based on its revision number in VCS.

Screenshots

The Pipeline View

Configuration

View Configuration

  1. Install the plugin using the Hudson\Jenkins Plugin Manager and restart.
  2. Create a view of the new type Build Pipeline View.
    You will then be redirected directly to the configuration page.
  3. The table below outlines what each interesting parameter controls:

    Name

    The name of the Build Pipeline View

    Description

    This message will be displayed on the view page. Useful for describing what this view is about, or linking to relevant resources. Can contain HTML tags.

    Build Pipeline View Title

    Gives a title to the page that displays the view

    Select Initial Job

    This is the first job in the build pipeline. It will traverse through the downstream jobs to build up the entire build pipeline.
    Select from a drop-down list of jobs.

    No of Displayed Builds

    The number of historical builds to be displayed on a page.

    Restrict triggers to most recent successful builds

    Select this option to restrict the display of a Trigger button to only the most recent successful build pipelines.
    Yes: Only the most recent successful builds displayed on the view will have a manual trigger button for the next build in the pipeline.
    No: All successful builds displayed on the view will have a manual trigger button for the next build in the pipeline.

    Always allow manual trigger on pipeline steps

    Select this option if you want to manually execute or re-execute any step of the pipeline at any time.

    Show pipeline parameters

    Select this option if you want to display the parameters used to run the first job in the pipeline.

Job Configuration

  1. Navigate to the Job configuration page.
  2. Scroll down to the Post-build Actions section.
    1. For an Automated downstream build step;
      To add a build step that will trigger automatically upon the successful completion of the previous one:
      1. Select the Build other projects check-box
      2. Enter the name(s) of the downstream projects in the Projects to build field. (n.b. Multiple projects can be specified by using comma, like "abc, def".)
    2. For a Manually Triggered downstream build step:
      To add a build step that will wait for a manual trigger:
      1. Select the Build Pipeline Plugin -> Manually Execute Downstream Project check-box
      2. Enter the name(s) of the downstream projects in the Downstream Project Names field. (n.b. Multiple projects can be specified by using comma, like "abc, def".)
  3. Click Save

Automatic & Manual downstream build steps

The Build Pipeline Plugin handles the creation of multiple automatic and/or manually triggered downstream build steps on the same project.

Upgrading from Release 1.0.0

When upgrading from 1.0.0 to 1.1.x some of the previous view and job configuration fields have been removed. You may notice some errors of the following errors appearing in the Hudson/Jenkins log.

WARNING: Skipping a non-existent field downstreamProjectName
com.thoughtworks.xstream.converters.reflection.NonExistentFieldException: No such field
au.com.centrumsystems.hudson.plugin.buildpipeline.trigger.BuildPipelineTrigger.downstreamProjectName

This is because the configuration files refer to old fields that may no longer exist.
In order to correct these issues go to the Job configuration page, confirm that all of the details are correct and click on the Save button.

More on Pipelines

The canonical reference for pipelines is the book Continuous Delivery.

Chapter 5 of the book, which describes how deployment pipelines work, is available for free here.

74 Comments

  1. Hey, your plugin doesnt respect --prefix when putting hudson icons into defined view i dont know where report bug (there is no such component in jenkins jira issue trakker) :)

    1. Please post your issues here - http://code.google.com/p/build-pipeline-plugin/issues/list.  We're tying to stay out of the Jenkins versus Hudson debate, so are hosting on google code.

  2. I really don't understand what the "Filter build queue" and "Filter build executors" configuration options do, as when I select them they don't appear to do anything.  Could some please provide a better explanation than the help text?  Thanks.

    1. Hi Daniel,  these are default options for a view, not part of the build pipeline plugin (so is the help test).  You will see the same options if you just add a standard list view.

      Cheers,  Geoff

  3. What is in release 1.2.3?  I can't find a list or a blog entry on it and yet it appears that work on 1.2.4 is already underway or complete.

    Thanks,

    Dan

    1. The release notes on this page are missing for 1.2.4 and 1.3.  Might be helpful to update that section of the page.  Thanks.

  4. There's any plans to include support for Join Plugin?

  5. I wonder if it is passible to set the build ID (initial job) so that it only shows pipeline view for the specific build ID, rather than the most recent 1,3,5 builds?

  6. Hi, is it possible to lock a build pipeline and release the lock when the build chain ends (successfully or not) ? 

    I have the the following simple use case (simplified of course):

    1. Job A :  is triggered by SCM changes and builds our application
    2. Job B : takes the result of A and performs  a setup of the application
    3. Job C : execute tests

    I would like the A,B,C jobs to be part of a build pipeline and if any of these jobs is running prevents the A job from being added to the build queue (if someone commits something).

    I tried to do something like that with the "locks and latches" plugin and a thread pool of 1 with individual jobs (not part of a build pipeline). The problem is that the lock is released when a Job is done, therefore a A job can be started between the execution of a B and C. I don't want to create a single job and create build steps for each job because if a job fails (like the setup job) i might want to manually retry it.

    It would be nice to be able to lock the whole build pipeline. (in my example actually only B and C should be locked since A supports concurrent execution...)

  7. seems this plugin does not work for if I select Trigger parameterized build on other projects rather than build other projects

  8. It seems this plugin wants to communicate with ajax.googleapis.com, but we are behind a firewall and our servers and slaves do not have access to the internet.

    Because of this, it takes a while for the page to render.  I don't see anything wrong with the page, so I don't know why the plugin needs to communicate externally.

    Is there a way to disable this?

  9. Love this plugin, seems I got spoiled with rapid release cycles early on, was looking forward to join support and further enhancements. Seems to have died down significantly since 1.2.3.

    Any ideas of when we expect the next release ?

    1. Sorry!  Been a hectic few months.

      We'll get a release out this year.  Watch this space

      1. No worries Geoff, understand it is built on peoples free time :-) glad to hear a release is coming will def keep an eye out . . . 

        - Matthew

  10. I like your plugin very much, thank you very much for it!

    But I still have one wish:

    We have two build jobs: "my_project_build" and "my_project_unit_tests". Since the latter is executed only at 6, 14 and 22 o'clock, there is no direct dependency between the jobs. Both jobs use fingerprinting, thus within Jenkins these jobs have a relationship. (You can check this out via Jenkins main menu => Project Relationship.)

    What I am missing for the build pipeline plugin is a "finger printing detection". That means if two projects have a relationship (the same fingerprinting) and do not have a direct dependency, it was very nice, if it was also displayed in the build pipeline plugin. At the moment I see two ways, when the plugin displays a build pipeline: the automatic one (if there is a direct job dependency it works fine) and the manual one (if you push the build button via the build pipeline view, but not in other views). My wish is, that the build pipeline plugin also regards "loosely coupled" jobs/builds. (Please correct me, if I am missing some point or my words are confusing.)

    (If you need contribution for such a feature, maybe I can support you. Disclaimer: I do not have any experience with Jenkins plugin development yet. Though I am very interested in.)

    Christian

  11. I have a pipelines with a build jobs and junit tests which generate a report through the junit plugin. How can I make the report from the junit job available to its upstream build job ? can I do it with this plugin or do I need something else for this ? thanks.

    Miguel 

    1. Hi Miguel.  I don't know if you can make junit reports available to upstream jobs, as the upstream job already ran and I don't see how it would respond to something changing in the downstream job.  If your case is actually wanting to make junit reports available to the downstream jobs, you can use the clone workspace plugin, where files from one workspace are made available to some downstream jobs.

  12. Jenkins indicates the folllowing for 1.3: "Warning: This plugin is built for Jenkins 1.457 or newer. It may or may not work in your Jenkins."

    What in 1.457 is required?  We're using 1.447.

    Thanks,

    Dan

    1. Some of the javascript is failing in 1.447 and not in 1.457.

      1. Thanks for the response.  I'm going to have to look closely at the Jenkins changelog then to see about upgrading then.  I was hoping to not have to do that.

  13. We've been using your plugin for a while to create a CD pipeline. We currently build and deploy our appto the repo  in the first step and then pass the revision number (using parametrized trigger) on each step to pull the binary back from the repo and deploy to the appropriate environment. This works great until we need to run manual steps. Any idea how we can pass the SVN rev number to the next step when the manual trigger is clicked?

    1. If you set a parameter in an upstream build, it should be available to all the downstream ones.

      A bit clunky, but you could use the groovy plugin for this (system groovy build step)

      import hudson.model.AbstractBuild
      import hudson.model.ParametersAction
      import hudson.model.StringParameterValue
      
      def currentBuild = Thread.currentThread().executable;
      def newParamAction = new ParametersAction(new StringParameterValue("MY_PIPELINE_IDENTIFIER","77"));
      currentBuild.addAction(newParamAction);
      
      1. Sadly parameters in upstream builds are not available if you're also using the parameterized trigger plugin. I got around this by using your groovy snippet, but that means such builds can no longer be run outside of the pipeline (providing the user knew the exact build number he wanted to deploy). We'll have to provide an alternative mechanism for that.

    2. Thanks for the quick reply!

      Also wondering how support for the join plugin is coming along?

      Our pipeline forks in a number of places making the pipeline view very difficult to follow.

  14. Great plugin, but I have a question.

    When I define a piped with project names are projectA-build and projectA-Unit_tests and display names are Build and Unit tests, in the graph of pipeline I see the project names (projectA-build and projectA-Unit_tests), but it would be great if we could choose the name to show, to simplify the view. This would be done at job configuration, at downstream project names, with an optional display name. So it would be more customizable, and projects could be reusable, with different displaying names from different jobs pipelines.

    1. Hello Ramon - if you'd like to formally request such a feature you should submit an issue at http://code.google.com/p/build-pipeline-plugin/ .

  15. Great plugin... keep up the great work.

    I just updated to Jenkins v1.491 and this build pipeline plugin seems to have broken. Regardless of the how I configure it no build pipelines show up. Do you already know about this issue?

    1. Could you submit an issue report at http://code.google.com/p/build-pipeline-plugin/ about it?  What would be most helpful would be a stacktrace from the Jenkins log/console.  Thanks.

      1. Defiantly I will do that now over at your Google Code site.

        1. Thanks.  Unfortunately, development on the plugin has screeched to a halt of late, so if this is truly an issue with the plugin it might not get fixed for a while.  Hopefully, as a workaround, you can downgrade Jenkins, although I'm quite aware a recent security advisory has suggested people upgrade to 1.491.

          1. Thanks for letting me know Daniel. Out of interest what's the reason that development has "screeched to a halt of late"?

              1. We haven't had time to  made any changes ourselves for a couple of months now.   Last commit was 4 days ago though.

                As always, we welcome any contributions though if anyone does have some time.

  16. The "Open Issues" JQL filter in the Plugin Information section references a non-existent component 'build-pipeline-plugin'. It should instead use the 'build-pipeline' component.

  17. I have a question wrt. Always allow manual trigger on pipeline steps ...

    If this is *not* checked, then only manual build steps can be triggered, right?

    What I would want to do would be to be able to re-trigger failed (automatic) build steps of a certain pipeline run. Is this possible? Planned?

  18. It would be really nice if someone updated this wiki page with information about what is in each new release so we don't have to look at the source to try and determine that.  1.3.4 and 1.3.5 are not detailed here.

    Thanks.

  19. With Plugin 1.3.5, I don't see the retry build option anymore in the pipeline view. And the 'Run' button on top of the view do not start the pipeline job.

    Will this be modified or added?

    Thanks,

    1. Mir - the logic for when the retry options display and are available is dependent on various conditions, so in order for someone to troubleshoot your issue, or respond to your potential bug report, you'll need to indicate what your Build Pipeline Plugin config options are, and what job isn't retry-able.  A screenshot would help too.  I would suggest you submit a JIRA ticket if in fact you are sure you have found a problem, and aren't perhaps experiencing another problem, such as not being signed in with build permissions.

      1. Yep, got you. I defnitely got the point, why the retry options is not available. I saw if a build fails, the retry option is available. And I do not see for a successful build and it is acceptable. I will look forward for a issue about the 'Run' option on the build pipeline page.

  20. It would be very useful if there was an option to label a pipeline with something other than a sequential build number. Something similar to the build-name-setter plugin that allows a build to be labeled from a build parameter would be great.

    Thanks for a very useful plugin! I have come to appreciate how useful it is in following the progress and generated artifacts of complex builds (I have some bioinformatic pipelines consisting of at least 5-6 chained jobs)

  21. I am very interested in starting to use the plugin "build pipeline " in my work .

    However , I would like to help with the following question : " After a few steps of my deployment process , it is necessary to store the name of the person responsible for approving the deployment in a production environment . Wish I could store the name to manually start a specific job , but to set the parameter that will be received , the pipeline plugin ignores this parameter .

    How can I do to with the manual startup of a job is also possible to parameterize a given parameter . "

    Thank you for your attention.

    1. Hi, Bruno,

      There were a few bugs related to parameters that have been introduced since June. Please check the list of issues, Resolved bugs too (because Tom Akehurst just made some commits today), and see if your problem is listed. I'm not sure if his fixes made it into 1.4.1.

      https://issues.jenkins-ci.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+JENKINS+AND+component+%3D+build-pipeline+AND+summary+~+parameter+ORDER+BY+created+DESC

      -Zach

      1. Zachary thank you for the reply.
        In the end, I gave up using the pipeline-plugin parameters.
        Could I get another question?
        Would somehow cancel the build? I thought of something similar to step though manual button for cancellation.
        Zachary thank you for the reply.

        In the end, I gave up using the pipeline-plugin parameters.

        Could I get another question?

        Would somehow cancel the build? I thought of something similar to step though manual button for cancellation.

  22. Hi, I can't find the source code of this plugin with the version 1.3.3, either on github or on svn.

    Could u please tell me where I can download it?

    Thanks!

      1. Thanks for your reply! But on the website you suggested, only 1.3.4 and later versions are available. I can't find source code for 1.3.3.  Any advice? 

          1. Hi, Geoff, I downloaded 1.3.3 source code from googlecode, but when I tried to compile it using 'mvn hpi:run',

            an exception occurred. It's like:

            [ERROR] Failure executing javac, but could not parse the error:
            错误: javax.annotation.processing.FilerException: Attempt to reopen a file for path D:\plugins-src\build-pipeline-plugin-1.3.3\target\classes\au\com\centrumsystems\hudson\plugin\buildpipeline\BuildPipelineView.stapler
                    at com.sun.tools.javac.processing.JavacFiler.checkFileReopening(JavacFiler.java:535)
                    at com.sun.tools.javac.processing.JavacFiler.createResource(JavacFiler.java:431)
                    at org.kohsuke.stapler.jsr269.AbstractProcessorImpl.createResource(AbstractProcessorImpl.java:81)
                    at org.kohsuke.stapler.jsr269.AbstractProcessorImpl.writePropertyFile(AbstractProcessorImpl.java:67)
                    at org.kohsuke.stapler.jsr269.ConstructorProcessor.write(ConstructorProcessor.java:80)
                    at org.kohsuke.stapler.jsr269.ConstructorProcessor.access$000(ConstructorProcessor.java:28)
                    at org.kohsuke.stapler.jsr269.ConstructorProcessor$1.visitExecutable(ConstructorProcessor.java:36)
                    at org.kohsuke.stapler.jsr269.ConstructorProcessor$1.visitExecutable(ConstructorProcessor.java:32)
                    at com.sun.tools.javac.code.Symbol$MethodSymbol.accept(Symbol.java:1621)
                    at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:146)
                    at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:133)
                    at javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:178)
                    at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:1137)
                    at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:146)
                    at org.kohsuke.stapler.jsr269.ConstructorProcessor.process(ConstructorProcessor.java:52)
                    at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:794)
                    at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:705)
                    at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91)
                    at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1035)
                    at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1176)
                    at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1173)
                    at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:859)
                    at com.sun.tools.javac.main.Main.compile(Main.java:523)
                    at com.sun.tools.javac.main.Main.compile(Main.java:381)
                    at com.sun.tools.javac.main.Main.compile(Main.java:370)
                    at com.sun.tools.javac.main.Main.compile(Main.java:361)
                    at com.sun.tools.javac.Main.compile(Main.java:74)
                    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
                    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                    at java.lang.reflect.Method.invoke(Method.java:483)
                    at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess0(JavacCompiler.java:554)
                    at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java:530)
                    at org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:165)
                    at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:627)
                    at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
                    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
                    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
                    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
                    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
                    at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365)
            [ERROR] Failure executing javac, but could not parse the error:

            错误: javax.annotation.processing.FilerException: Attempt to reopen a file for path D:\plugins-src\build-pipeline-plugin-1.3.3\target\classes\au\com\centrumsystems\hudson\plugin\buildpipeline\BuildPipelineView.stapler

                    at com.sun.tools.javac.processing.JavacFiler.checkFileReopening(JavacFiler.java:535)

                    at com.sun.tools.javac.processing.JavacFiler.createResource(JavacFiler.java:431)

                    at org.kohsuke.stapler.jsr269.AbstractProcessorImpl.createResource(AbstractProcessorImpl.java:81)

                    at org.kohsuke.stapler.jsr269.AbstractProcessorImpl.writePropertyFile(AbstractProcessorImpl.java:67)

                    at org.kohsuke.stapler.jsr269.ConstructorProcessor.write(ConstructorProcessor.java:80)

                    at org.kohsuke.stapler.jsr269.ConstructorProcessor.access$000(ConstructorProcessor.java:28)

                    at org.kohsuke.stapler.jsr269.ConstructorProcessor$1.visitExecutable(ConstructorProcessor.java:36)

                    at org.kohsuke.stapler.jsr269.ConstructorProcessor$1.visitExecutable(ConstructorProcessor.java:32)

                    at com.sun.tools.javac.code.Symbol$MethodSymbol.accept(Symbol.java:1621)

                    at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:146)

                    at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:133)

                    at javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:178)

                    at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:1137)

                    at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:146)

                    at org.kohsuke.stapler.jsr269.ConstructorProcessor.process(ConstructorProcessor.java:52)

                    at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:794)

                    at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:705)

                    at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91)

                    at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1035)

                    at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1176)

                    at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1173)

                    at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:859)

                    at com.sun.tools.javac.main.Main.compile(Main.java:523)

                    at com.sun.tools.javac.main.Main.compile(Main.java:381)

                    at com.sun.tools.javac.main.Main.compile(Main.java:370)

                    at com.sun.tools.javac.main.Main.compile(Main.java:361)

                    at com.sun.tools.javac.Main.compile(Main.java:74)

                    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

                    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

                    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

                    at java.lang.reflect.Method.invoke(Method.java:483)

                    at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess0(JavacCompiler.java:554)

                    at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java:530)

                    at org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:165)

                    at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:627)

                    at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)

                    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)

                    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)

                    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)

                    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

                    at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365)

            Do u know how to solve this problem?

  23. Hi all,

    Is it possible to create build pipeline views with groovy scripts? I would like to generate a new build pipeline view (in a nested view) when one of my jobs in Jenkins executes. I have to set the following parameters in the new view: Name, Initial Job, No. of displayed builds. I've found the following example for creating list views: hudson.model.Hudson.instance.addView(new hudson.model.ListView("ViewX"))

    Thanks and regards,

    Szabolcs

  24. What is the expected behavior when re-running a job/project?

    (Maybe I'm missing something but I've read all the docs I can find.  There's not much out there showing the best practices of how to put the usual plugins together.  The Jenkins book comes the closest but it has flaws and falls short.)

    When I click the rerun button in a pipeline, it works fine and displays the new build number for a period but then, after it finishes, the new build number disappears from the pipeline and the original build number appears.  Thus, it is not apparent when looking at the pipeline view that a job was rerun.

    If I rerun a build and it fails, however, it behaves more like I expect, leaving the failed build visible in the pipeline view.  It also appears to behave as expected when rerunning just the latest job that was built.

    I was hoping to use the rerun buttons as a rollback feature but they aren't very useful if they don't update the pipeline and/or the pipeline project headers with useful info (not to mention updating the Delivery Pipeline plugin views).

    For example, in the following screenshot, build #13 was rerun and it produced build #15 which finished successfully.  But this is not visible anywhere on this view.  The only evidence I have right now (in this view) that bat2-deploy-to-prod was rolled back is that I happen to pass a parm to each job of the first job's build number to make artifact management easier.  Thus, you can see that PIPELINE_BUILD_NUMBER is 11 and not 12 as it was before build #15.

    I am tempted to add another job at the end to rollback prod in case of emergency, but this does not solve rollbacks elsewhere and anywhere.

    (Interestingly, I have another test project where I put the entire deployment pipeline into Promoted Builds Plugin steps inside a single project and do not use any chaining or pipelines.  It handles rollbacks and such well and fairly clearly for simple projects.  I'm just not convinced that would be the best practice for all dev work.  Pipelines are more modular and flexible.)

  25. Hello! I just updated the Build Pipeline plugin to v1.4.4 and when I try to view the live console output feed I get a Java error which says the server's DNS is unable to resolve. I don't think this was a problem in the version I had installed before, but I wanted to check in here before I downgrade.

  26. I am using the buildflow plugin to kick off jobs. I have a parent build flow job which kicks off a series of free-style-jobs. However, the build pipeline plugin does not seem to support build flow plugin. I have selected by initial job as the 'build-flow' job. My build build-flow job kicks off 3 parallel job but the pipeline view shows nothing.

  27. Hi! I'd like to trigger a downstream from 2 upstreams, just as it's been done in the example above for "Deploy to pre-prod".

    Can anyone tell me how to configure Jenkins to do so?

  28. Hello! Ever since the last update the 'console' link to pop-up the console log for any step in the pipeline does not work. Clicking the 'console' link does nothing, currently.

  29. I also get an issue trying to view the console as a Lightbox. Inspecting the page shows the following errors in your js/jquery code

    Uncaught TypeError: Cannot read property 'msie' of undefined
    jquery.tooltip.min.js:14 Uncaught TypeError: Cannot read property 'msie' of undefined
    build-pipeline.js:101 Uncaught TypeError: jQuery.fancybox is not a function
    Uncaught TypeError: Cannot read property 'msie' of undefined

    jquery.tooltip.min.js:14 Uncaught TypeError: Cannot read property 'msie' of undefined

    build-pipeline.js:101 Uncaught TypeError: jQuery.fancybox is not a function

  30. Any plans to update this plugin ?? Looks like its functionality is totally broken.

  31. Upgrading the jquery plugin from 1.7.2-1 to 1.11.2-0 broke the "Run" and console window buttons. Downgrading restored that functionality.

  32. Somehow I am not seeing the pipeline view in full screen. Its leaving 20% of the left part empty and starting after that and also I am seeing size of the each tile is very less and its becoming small with every additional job we add. I am using Jenkins 1.630 and build-pipleline plugin version 1.4.8. I am attaching the screenshot of my pipeline view. Please advise.

  33. I am struggling to use this plugin recently as the Build Pipeline Plugin -> Manually execute downstream job option does not show up in my configuration page after installing the plugin.  Is there something I am missing?

    My plan is to have a name Build Process that will run through some steps and pause before deploying to allow me to check.

  34. I am struggling to use this plugin recently as the Build Pipeline Plugin -> Manually execute downstream job option does not show up in my configuration page after installing the plugin.  Is there something I am missing?

    My plan is to have a name Build Process that will run through some steps and pause before deploying to allow me to check.

  35. Is there a remote API that can be called to execute a manual trigger in a pipeline?

  36. Hi,

    We have a build pipeline which runs jobs on Windows 7 machines/nodes (based on their name/label).
    Certain jobs are linked to a node.

    Here a sample flow:
    BUILD 
    ---> RESET_VMS (machine_w7_1,machine_w7_2,machine_w7_3,machine_w7_4)
    ------> INSTAL_ON_MACHINES (machine_w7_1,machine_w7_2,machine_w7_3,machine_w7_4)
    ---------> RUN SMOKTEST (label:windows7)
    ------------> RUN TESTS1 (label:windows7)
    ------------> RUN TESTS2 (label:windows7)
    ------------> RUN TESTS3 (label:windows7)
    ---------------> SEND_REPORT 

    Now we want to have the same flow for Windows 8; so all jobs are the same, the flow is the same; only the nodes/labels/parameters are different.
    BUILD 
    ---> RESET_VMS (machine_w8_1,machine_w8_2,machine_w8_3,machine_w8_4)
    ------> INSTAL_ON_MACHINES (machine_w8_1,machine_w8_2,machine_w8_3,machine_w8_4)
    ---------> RUN SMOKTEST (label:windows8)
    ------------> RUN TESTS1 (label:windows8)
    ------------> RUN TESTS2 (label:windows8)
    ------------> RUN TESTS3 (label:windows8)
    ---------------> SEND_REPORT

     So as you see, the only difference is the machines to run on and the labels to use; we want different flows because we want to be able to run the flow on Windows 7 & 8 machines seperately.
    But if I create a new view: BUILD_W8 and add the existing RESET_VMS as initial job; then the parameters/labels are used from the W7 machines/labels.
    So how can I create two flows with the same structure and jobs; but different parameters/nodes/labels?

     Thanks!

  37. Can the list of parameters be ordered?  It is not in the same order as what is shown in the job, and is not alphabetical,so I don't know how the list of parameters are ordered.

  38. Nice Plugin. If I need to display a custom message saying that "your Job if successful in DEV and is ready for promoting to QA" while promoting from Job A to Job B, what are the possible ways with your plugin? It is better to display the message in Pipeline view before or after trigger the Job B. If that is not possible, please include this in the future update. Thanks,

  39. My plan is to create a manager approval job and a production job.

    the production has to schedule at some particular time say 16:00 

    the manager approval job it should trigger an email and it should also pick the parameter (CRQ Number) and this parameter should also read by the  second job and production job should should automatically schedule at 16:00.

    The manager approval will be build with this (Parameter) CRQ number.

    Please help

    Thanks

  40. I have installed the 1.5.7 but I couldn't find a way to add multiple initial jobs under pipeline flow. I remember I can do that in an older version but I couldn't figure out how to do that in the latest version. Is there anything changed?

    1. That was never the case. You're thinking of a different plugin or a different use-case, this has always only allowed a single initial job

      1. Oh, thanks for your reply. I might use some other pipeline view plugins. I have a case that there are three GitHub repos, UI, Backend and Release. The UI and Backend are upstream and Release is the downstream. So both UI and Backend are initial jobs. How can I make this pipeline show in the pipeline view? 

        1. This plugin, 'build pipeline plugin', is just a visualization of upstream and downstream relationships of jobs. The behavior you are describing is "fan-in" behavior, which is not supported in these relationships between jobs. I believe the 'pipeline plugin' aka workflow-aggregator, the groovy-based pipeline DSL approach, does support fan-in, although I can't say whether it would work for your use-case.

  41. Would be great to have the option "Trigger even if the build is unstable" for manually executed jobs.

  42. The parameterized build plugin and conditional build  is being used . For eg: Job A would trigger Job B  if param value is "ui" , It would trigger Job C if value is "service" .

    While visualizing this using build pipeline plugin, job B and C are getting displayed twice. Is this a bug or a intended feature. 

  43. We are experiencing the same problem just described by Arjun.

    Detailed problem description: we have job A triggering builds on projects/jobs B1 and B2, B1 tiggering build on project/job C1. In the pipeline view B1 and B2 are displayed twice, and for each B1 also C1 is displayed twice.

    This does happen only if we trigger during build phaseIt does not happen if we trigger as post-build action. 

    This happens since version 1.5.8 of the build-pipeline-plugin and did not happen with build-pipeline-plugin 1.5.6. If other versions of plugins or Jenkins are related, then the follwoing information might help: we did not have the problem with the latest version of Jenkins and plugins in July 2017 and the problem first occured in October 2017. I hope this does help finding the bug.

  44. Is there some way to release a manual pipeline step remotely?

    We have the requirement to release normally in dependency from another system and sometimes manually.

  45. Why am I getting this problem with my view?

    I have 2 other views created for created which are exactly similar which small changes in the jobs(UAT and PROD ) and they look perfectly fine. Furthermore, I can see all my jobs when I click on 'History' here.

    Is there any limitations to the number of build pipeline views?

    Could anyone please help me resolve this issue?