Status: Closed (View Workflow)
Linux master server, separate Linux or Windows slave
Using the git plugin to publish a merged change to a central repository previously was successful from either the master node or a slave agent. With the 1.2.0 (and 1.3.0) version of the git plugin it is no longer able to push changes to the central repository after they have merged and are successfully built on the slave. The merge still works as expected when performed on the master node.
The stack trace reports:
Commencing build of Revision 363396d76a09a12a2f4b5d94fb4e9981e05ad4a9 (origin/proposals)
hudson.util.IOException2: remote file operation failed: /var/lib/jenkins/mwaite6-slave/workspace/merge-proposals at hudson.remoting.Channel@4a6ecaf9:fc-agile-2011
Caused by: java.io.IOException: Unable to serialize hudson.FilePath$FileCallableWrapper@7c0a37f8
... 10 more
Caused by: java.io.NotSerializableException: hudson.model.FreeStyleBuild
... 13 more
Steps to recreate the problem:
- configure a Git repository into which the Jenkins user can push changes
- create a "master" branch and a "proposals" branch on the Git repository
- define a Jenkins job which clones the Git repository with ssh protocol
- configure the Jenkins job git plugin to merge from "/proposals" and "/master" to "master-proposals"
- restrict the job to execute on any node except master node ("!master")
- define a post build action to push the resulting merge to the origin/master branch
- Submit a change to the central git repository on the "proposals" branch
- Run the Jenkins job to confirm it will combine the master and proposals branches
- Confirm the Jenkins job fails to push the combined change
= Serialization exception between master and slave.
Refer to merge-proposals.xml for the job definition I used in my tests.
- is duplicated by
JENKINS-17679 Git plugins crashes with exception for jobs using git merging features
same problem with 1.3.0:
build has failed on rebase
Downgrade to 1.1.26 has solved the problem
I see a similar problem with 1.3.0. I get a similar stack trace just by attempting to use "Merge before build" with a branch to merge to. (No post-build steps.)
The git-client-plugin 1.0.5 and git-plugin 1.3.0 still show the same problem when attempting a build from a slave agent. The same build works fine if it is restricted to the master node.
That seems to indicate that this issue is not directly related to whether the git implementation is JGit or command line Git. The git-client-plugin 1.0.4 implementation default was JGit (which showed the problem). The git-client-plugin 1.0.5 implementation default is command line Git (which also shows the problem).
Some testing with my own builds shows that the trigger/difference for causing the "java.io.NotSerializableException" is when the advanced setting "Merge before build" is checked off and filled in. Git operations without this seem to work fine. *Haven't tested extensively of course
*Edit: This confirms what David Walend commented on earlier.
Additionally, I was able to reproduce this behaviour on OSX and Linux slaves, both 64-bit.
I've started to find out where went it bad.
The affected commits are:
so this was the last stable commit:
The next few commits failed to compile.
This one compiles, but throws "kind of error", which means it fails to merge:
Could not checkout release with start point xxxx
So somewhere between:
Thanks for spending the effort to seek the failing submission. Unfortunately, I think that the actual problem change is hidden in the refactoring which abstracted the Git implementation into an interface, then provided two alternate implementations of that interface, one using the command line Git, the other using JGit. Initially, the default implementation was JGit. With git-client-plugin 1.0.5, the default implementation is now command line Git.
I think the problem was introduced by the refactoring because the problem still exists even after the default implementation was switched from JGit to command line git.
The high level history (as far as I can see), looks something like this:
- Git plugin 1.1.26 - last version known able to push a merged submission back from a slave agent
- Git plugin 1.2.0 + Git client plugin 1.0.1 through 1.0.4 - refactored to provide a Git interface, default implementation with JGit
- Git plugin 1.3.0 + Git client plugin 1.0.5 - bug fixes and switch default implementation to command line Git
Part of me makes the wild guess that this issue would be resolved if we could understand why it cannot serialize. I don't understand the architecture of the slave to master communication, but I thought it was defined by the Java classes and was implemented with Java serialization. My wild guess was that some field or fields were "lost" or "redefined" in the refactoring which break the serialization between the master and slave. However, that is truly just wild guessing on my part.
Meanwhile I think I've found the problematic part. It now works for me locally. Trying to create a patch.
That sounds great! If you'd like additional testing of your patch, I'd be happy to help over the weekend. If you submit it as a pull request to the plugin repository, I can pull it into my repository as well and build it locally for my testing.
This one breaks the feature. At last for us it breaks when it wants to merge the main with another branch. (so merge before build)
Try to revert it and test it on your system.
Let me know how it works.
I've tested it.
It works now. It can check out on a remote slave, it can merge to another repo, and after the tests it can push the merged thing to another branch.
So the commit above my previous commit did it. I reverted it. Created a pull request for that.
Since https://github.com/jenkinsci/git-plugin/pull/148 has been merged, should this not be set to Resolved? (I know no plugin release containing the fix has yet been made, but it is conventional to mark bugs closed once the fix has been committed to the master branch.)
Agreed with @jglick that since the change has been submitted, this should be resolved.
Nicolas just pushed a release of git-client-plugin 1.0.6 and git-plugin 1.4.0. The git-client-plugin release is already available on the updates site. The git-plugin release should be available soon.
After updating to 1.2.0, we are seeing the exact same error under an identical scenario.
Downgrading resolved the issue.