WorkflowMultiBranchProject getLastBuild

[Sverre Moe]

Have Jenkins projects as Multibranch pipeline:

org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject

  extends jenkins.branch.MultiBranchProject

    extends com.cloudbees.hudson.plugins.folder.computed.ComputedFolder

      extends com.cloudbees.hudson.plugins.folder.AbstractFolder

        extends hudson.model.AbstractItem

I need to get the latest build job in my Groovy build script. Jenkins Javadoc is available online, but other APIs are not. It makes it difficult to know which methods I have access to.

WorkflowMultiBranch does not extend AbstractProject which has easy access methods such getLastBuild() or getLastCompletedBuild(). Not having access to the Javadoc for Cloudbees or Branch-API I am unsure if such a method exists for either MultiBranchProject, ComputedFolder or AbstractFolder.

Go searching through the source code for access methods is tedious and time consuming.

MultiBranchProject: https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/MultiBranchProject.java

ComputedFolder: https://github.com/jenkinsci/cloudbees-folder-plugin/blob/master/src/main/java/com/cloudbees/hudson/plugins/folder/computed/ComputedFolder.java

AbstractFolder: https://github.com/jenkinsci/cloudbees-folder-plugin/blob/master/src/main/java/com/cloudbees/hudson/plugins/folder/AbstractFolder.java

Anyway that is what I was forced to do with no access to such Javadocs.

Could not find any such easy access methods as those in hudson.model.Job or hudson.model.AbstractProject.

Can get all jobs from AbstractItem

public abstract Collection<? extends Job> getAllJobs()

And pick the first in the list (if the first is the latest build).

[Sverre Moe]

With some experimenting I think I have gotten what I need.

def jenkinsInstance = jenkins.model.Jenkins.getInstance()

def jenkinsProject = "multiBranchPipelineProjectA/master"

def project = jenkinsInstance.getItemByFullName(jenkinsProject)

def job = project.getAllJobs().first()

def lastBuild = job.getLastBuild()

def completed = !lastBuild.isBuilding()

Method getAllJobs() returns only one Job. Why is that?

I guess that if I called getAllJobs on the Multibranch pipeline project I would get for all branches (for instance 4 branches = 4 jobs).

[Jesse Glick]

On Wed, Aug 3, 2016 at 5:14 AM, Sverre Moe <sverr...@gmail.com> wrote:
> I need to get the latest build job in my Groovy build script.

Did you look at the documentation under Global Variables for `currentBuild`?

[Sverre Moe]

Pipeline Syntax -> Global Variables Reference
Variable currentBuild irefers to the currently running build. What I needed was the last build of a upstream dependency.

org.jenkinsci.plugins.workflow.job.WorkflowJob job = anotherUpstreamProject.getAllJobs().first()
org.jenkinsci.plugins.workflow.job.WorkflowRun build = job.getLastBuild()
hudson.model.Result result = build.getResult()
List<BuildBadgeAction> badges = build.getBadgeActions()

[Jesse Glick]

On Fri, Aug 5, 2016 at 4:02 AM, Sverre Moe <sverr...@gmail.com> wrote:
> Variable currentBuild irefers to the currently running build. What I needed
> was the last build of a upstream dependency.

Like JENKINS-31576 you mean?

[Sverre Moe]

It is related somewhat. That issue is about getting the upstream build that triggered this running build.

I just need the last build from an upstream dependency. The upstream build cause might be an upstream dependency, or it may be an SCM cause. Such that the upstream project might not be the upstream cause. Also an upstream cause might be a downstream dependency.

When a project is building, it triggers a build of all its downstream dependencies to verify they work with the new changes. If any of the downstream dependencies fail, then also the upstream project should fail. I add a BadgeAction with the list of failed downstream projects to the build for later inspection.

Later, when one of those downstream dependencies are built from SCM changes. Lets say when they fixed the issues that previously failed their build against the upstream project. Now they need to trigger a build of the all upstream projects (if they previously failed because of this project). After building a project I needed to get the previous build from an upstream project to determine if it failed because of this one.

[Jesse Glick]

On Mon, Aug 8, 2016 at 4:31 AM, Sverre Moe <sverr...@gmail.com> wrote:
> I just need the last build from an upstream dependency. The upstream build
> cause might be an upstream dependency, or it may be an SCM cause. Such that
> the upstream project might not be the upstream cause. Also an upstream cause
> might be a downstream dependency.

Did not really follow that, but…

> Later, when one of those downstream dependencies are built from SCM changes.
> Lets say when they fixed the issues that previously failed their build
> against the upstream project. Now they need to trigger a build of the all
> upstream projects (if they previously failed because of this project). After
> building a project I needed to get the previous build from an upstream
> project to determine if it failed because of this one.

Seems like it would be easier to roll this into one project with
multiple `checkout`s, which could use `currentBuild.changesets` to
decide whether or not to rebuild certain components.

[Sverre Moe]

On Mon, Aug 8, 2016 at 4:31 AM, Sverre Moe <sverr...@gmail.com> wrote:
> I just need the last build from an upstream dependency. The upstream build
> cause might be an upstream dependency, or it may be an SCM cause. Such that
> the upstream project might not be the upstream cause. Also an upstream cause
> might be a downstream dependency.

Did not really follow that, but…

The project that is currently building might have previously been triggered by an upstream project, a component it has as a build dependency with.

So the Upstream Cause which triggered a new build might either be an SCM change or another jenkins project.

       A

     /    \

    B   C

  /    \    \

 D   E    F

* SCM change triggers a build of A.

* The Verification stage triggers a build of B, C, D, E

* The build of B fails and consequently so does A.

...

* SCM change triggers a build of B.

* The Verification stage triggers a build of D and E.

* The build succeeds and so does all its downstream dependencies.

* Now it needs to rebuild A. It checks if the previous build of A failed because of this project.

So the upstream build cause might either be an upstream dependency or a downstream dependency.

> Later, when one of those downstream dependencies are built from SCM changes.
> Lets say when they fixed the issues that previously failed their build
> against the upstream project. Now they need to trigger a build of the all
> upstream projects (if they previously failed because of this project). After
> building a project I needed to get the previous build from an upstream
> project to determine if it failed because of this one.

Seems like it would be easier to roll this into one project with
multiple `checkout`s, which could use `currentBuild.changesets` to
decide whether or not to rebuild certain components.

Not sure what you ment with that. We have aprox 70 git repositories of libraries, utilities, programs with various dependencies among them. Some have many dependencies, some have few and some have none.

When someone push changes to remote, the git server has a hook that calls Jenkins URL with notifyCommit to trigger a build of that project.