[JIRA] (JENKINS-51133) Branch names in Multibranch jobs causing build failures

2 views
Skip to first unread message

robin.smith@forgerock.com (JIRA)

unread,
May 4, 2018, 6:16:02 AM5/4/18
to jenkinsc...@googlegroups.com
Robin Smith updated an issue
 
Jenkins / Bug JENKINS-51133
Branch names in Multibranch jobs causing build failures
Change By: Robin Smith
Summary: Branch names in Multibranch jobs causing build failures
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

robin.smith@forgerock.com (JIRA)

unread,
May 4, 2018, 6:18:02 AM5/4/18
to jenkinsc...@googlegroups.com
Robin Smith updated an issue
Occasionally, forking a new branch in a git repo can cause immediate, unrelated and irreversible build failures.

Our setup is a multibranch pipeline building each branch of the project for every commit. The repo is stored in Bitbucket.

We recently created a 'release/6.0.0' branch from our master branch, and the build on that branch immediately failed with the following error:

{code}
[ERROR] COMPILATION ERROR :
18:16:23 [INFO] -------------------------------------------------------------
18:16:23 [ERROR] /root/workspace/enAM-Pipeline_release_6.0.0-YRZAEYTMSVCBGF6L6YJT7VNUKLPLU3KCUEIOE5P5NURDINYXJM4Q/openam-core/src/main/java/org/forgerock/openam/entitlement/SetupInternalNotificationSubscriptions.java:[55,73] cannot find symbol
18:16:23   symbol:   class Consumer
18:16:23   location: class org.forgerock.openam.entitlement.SetupInternalNotificationSubscriptions
18:16:23 [INFO] 1 error
{code}

The same commit built fine on master, the only change in git is the creation of this new branch, which gets a new job/branch in the multibranch pipeline to reflect that. Our builds run on fresh Docker containers (Yet Another Docker Plugin); the builds in question ran on the same physical host, at separate times.

The problem is not ephemeral for the new branch - all future builds of that branch will be broken, with the same issue.

Deleting the branch, removing it from the multibranch job, then creating the branch does not fix the issue

The only approach that seems to work is to create another branch directly from the 'broken' one, with another name. For example, we created 'release/6.0.0b' (directly from 'release/6.0.0') and the build for that was fine.

The only correlation I can see is with the branch name. We occasionally see this with PRs too
. Sometimes - sometimes the builds for a PR seem irreversibly broken. Simply opening a new PR with the same code changes fixes the problem

robin.smith@forgerock.com (JIRA)

unread,
May 4, 2018, 6:18:02 AM5/4/18
to jenkinsc...@googlegroups.com
Robin Smith updated an issue
Occasionally, forking a new branch in a git repo can cause immediate, unrelated and irreversible build failures.

Our setup is a multibranch pipeline building each branch of the project for every commit. The repo is stored in Bitbucket.

We recently created a 'release/6.0.0' branch from our master branch, and the build on that branch immediately failed with the following error:

{code}
[ERROR] COMPILATION ERROR :
18:16:23 [INFO] -------------------------------------------------------------
18:16:23 [ERROR] /root/workspace/enAM-Pipeline_release_6.0.0-YRZAEYTMSVCBGF6L6YJT7VNUKLPLU3KCUEIOE5P5NURDINYXJM4Q/openam-core/src/main/java/org/forgerock/openam/entitlement/SetupInternalNotificationSubscriptions.java:[55,73] cannot find symbol
18:16:23   symbol:   class Consumer
18:16:23   location: class org.forgerock.openam.entitlement.SetupInternalNotificationSubscriptions
18:16:23 [INFO] 1 error
{code}

The same commit built fine on master, the only change in git is the creation of this new branch, which gets a new job/branch in the multibranch pipeline to reflect that. Our builds run on fresh Docker containers (Yet Another Docker Plugin); the builds in question ran on the same
physical
host, at separate times.


The problem is not ephemeral for the new branch - all future builds of that branch will be broken, with the same issue.

Deleting the branch, removing it from the multibranch job, then creating the branch does not fix the issue

The only approach that seems to work is to create another branch directly from the 'broken' one, with another name. For example, we created 'release/6.0.0b' (directly from 'release/6.0.0') and the build for that was fine.

The only correlation I can see is with the branch name. We occasionally see this with PRs too. Sometimes the builds for a PR seem irreversibly broken. Simply opening a new PR with the same code changes fixes the problem

robin.smith@forgerock.com (JIRA)

unread,
May 4, 2018, 6:18:03 AM5/4/18
to jenkinsc...@googlegroups.com
Robin Smith updated an issue
Occasionally, forking a new branch in a git repo can cause immediate, unrelated and irreversible build failures.

Our setup is a multibranch pipeline building each branch of the project for every commit. The repo is stored in Bitbucket.

We recently created a 'release/6.0.0' branch from our master branch, and the build on that branch immediately failed with the following error:

{code}
[ERROR] COMPILATION ERROR :
18:16:23 [INFO] -------------------------------------------------------------
18:16:23 [ERROR] /root/workspace/enAM-Pipeline_release_6.0.0-YRZAEYTMSVCBGF6L6YJT7VNUKLPLU3KCUEIOE5P5NURDINYXJM4Q/openam-core/src/main/java/org/forgerock/openam/entitlement/SetupInternalNotificationSubscriptions.java:[55,73] cannot find symbol
18:16:23   symbol:   class Consumer
18:16:23   location: class org.forgerock.openam.entitlement.SetupInternalNotificationSubscriptions
18:16:23 [INFO] 1 error
{code}

The same commit built fine on master, the only change in git is the creation of this new branch, which gets a new job/branch in the multibranch pipeline to reflect that. Our builds run on fresh Docker containers (Yet Another Docker Plugin); the builds in question ran on the same physical host, at separate times.

The problem is not ephemeral for the new branch - all future builds of that branch will be broken, with the same issue.

Deleting the branch, removing it from the multibranch job, then creating the branch does not fix the issue

The only approach that seems to work is to create another branch directly from the 'broken' one, with another name. For example, we created 'release/6.0.0b' (directly from 'release/6.0.0') and the build for that was fine.

The only correlation I can see is with the branch name. We occasionally see this with PRs too - sometimes the builds for a PR seem irreversibly broken. Simply opening a new PR with the same code changes change fixes the problem

robin.smith@forgerock.com (JIRA)

unread,
May 4, 2018, 6:27:02 AM5/4/18
to jenkinsc...@googlegroups.com
Robin Smith updated an issue
Occasionally, forking a new branch in a git repo can cause immediate, unrelated and irreversible build failures.

Our setup is a multibranch pipeline building each branch of the project for every commit. The repo is stored in Bitbucket.

We recently created a 'release/6.0.0' branch from our master branch, and the build on that branch immediately failed with the following error:

{code}
[ERROR] COMPILATION ERROR :
18:16:23 [INFO] -------------------------------------------------------------
18:16:23 [ERROR] /root/workspace/enAM-Pipeline_release_6.0.0-YRZAEYTMSVCBGF6L6YJT7VNUKLPLU3KCUEIOE5P5NURDINYXJM4Q/openam-core/src/main/java/org/forgerock/openam/entitlement/SetupInternalNotificationSubscriptions.java:[55,73] cannot find symbol
18:16:23   symbol:   class Consumer
18:16:23   location: class org.forgerock.openam.entitlement.SetupInternalNotificationSubscriptions
18:16:23 [INFO] 1 error
{code}

The same commit built fine on master, the only change in git is the creation of this new branch, which gets a new job/branch in the multibranch pipeline to reflect that. Our builds run on fresh Docker containers (Yet Another Docker Plugin); the builds in question ran on the same physical host, at separate times.

The problem is not ephemeral for the new branch - all future builds of that branch will be broken, with the same issue.

Deleting the branch, removing it from the multibranch job, then re- creating the branch does not fix the issue


The only approach that seems to work is to create another branch directly from the 'broken' one, with another name. For example, we created 'release/6.0.0b' (directly from 'release/6.0.0') and the build for that was fine.

The only correlation I can see is with the branch name. We occasionally see this with PRs too - sometimes the builds for a PR seem irreversibly broken. Simply opening a new PR with the same code change fixes the problem

andrew.bayer@gmail.com (JIRA)

unread,
May 14, 2018, 11:42:02 AM5/14/18
to jenkinsc...@googlegroups.com
Andrew Bayer updated an issue
Change By: Andrew Bayer
Component/s: bitbucket-branch-source-plugin
Component/s: workflow-multibranch-plugin
Component/s: pipeline

milkiwaysabe@gmail.com (JIRA)

unread,
Jun 21, 2018, 9:18:02 PM6/21/18
to jenkinsc...@googlegroups.com
jang hyemi started work on Bug JENKINS-51133
 
Change By: jang hyemi
Status: Open In Progress

milkiwaysabe@gmail.com (JIRA)

unread,
Jun 21, 2018, 11:38:13 PM6/21/18
to jenkinsc...@googlegroups.com

vivek.pandey@gmail.com (JIRA)

unread,
Nov 16, 2018, 11:26:01 AM11/16/18
to jenkinsc...@googlegroups.com
Vivek Pandey updated an issue
Change By: Vivek Pandey
Labels: multibranch triaged-2018-11
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

vivek.pandey@gmail.com (JIRA)

unread,
Nov 16, 2018, 11:27:02 AM11/16/18
to jenkinsc...@googlegroups.com
Vivek Pandey commented on Bug JENKINS-51133
 
Re: Branch names in Multibranch jobs causing build failures

Switching back to Open from In Review since no link to PR.

vivek.pandey@gmail.com (JIRA)

unread,
Nov 16, 2018, 11:27:02 AM11/16/18
to jenkinsc...@googlegroups.com

vivek.pandey@gmail.com (JIRA)

unread,
Nov 16, 2018, 11:27:02 AM11/16/18
to jenkinsc...@googlegroups.com
Vivek Pandey stopped work on Bug JENKINS-51133
 
Change By: Vivek Pandey
Status: In Progress Open

robin.smith@forgerock.com (JIRA)

unread,
Jul 19, 2019, 5:48:02 AM7/19/19
to jenkinsc...@googlegroups.com
Robin Smith closed an issue as Fixed
 

Not seen in almost a year - closing

Change By: Robin Smith
Status: Open Closed
Resolution: Fixed
Reply all
Reply to author
Forward
0 new messages