-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Branch git 2.2.0 #39
base: master
Are you sure you want to change the base?
Branch git 2.2.0 #39
Conversation
checkout calls changeLogResult with a null-changelog, but changeLogResult handles this as an error and returns false. This false is delivered directly to Hudson which is aborting the build if it was started without any commit. We had to ways to fix this: Let checkout always return true on now changes or change changeLogResult to always return true. I preferred the latter because the intended call of changeLogResult seems like deleting the changeLogFile.
The problematic call in checkout: |
I'm sorry, I won't be able to work on the next pull release for another couple days. Currently I am working on the SVN plugin and we're preparing for another small release for hudson. I will take a look at this next week. Do you have a test unit for this also? |
Guten Tag, Steven Christou,
Thanks, as we have our fix know, we can wait.
No, because I was unsure what the intended behaviour really should be Mit freundlichen Grüßen, Thorsten Schöning Thorsten Schöning | IT Development ART+COM AG | Kleiststr. 23-26 | 10787 Berlin | Deutschland HRB 68308 | Amtsgericht Charlottenburg |
Hmm, I just branched the git plugin and found no compilation or unit test failures. What tests were failing on your branch specifically? |
Guten Tag, Steven Christou,
Hello, I'm new to maven and maybe made a mistake on setup, so here's what I T E S T SRunning hudson.plugins.git.BranchSpecEqualsHashCodeTest Results : Failed tests: Tests in error: Tests run: 128, Failures: 13, Errors: 1, Skipped: 0 [INFO] ------------------------------------------------------------------------ Mit freundlichen Grüßen, Thorsten Schöning Thorsten Schöning | IT Development ART+COM AG | Kleiststr. 23-26 | 10787 Berlin | Deutschland HRB 68308 | Amtsgericht Charlottenburg |
I will try your modifications on my local branch to see if changes you made would break those junits. It could be the version of git you are using. You wouldn't happen to know the version of git that you are running would you?
|
Guten Tag, Steven Christou,
Good point, I didn't thought of that. I have MsysGit 1.7.8, Cygwin Msys my version: Running hudson.plugins.git.GitSCMTest Msys your HEAD: no failures Cygwin my version: Running hudson.plugins.git.GitPublisherTest Cygwin your HEAD: Running hudson.plugins.git.GitExcludeIncludeTest Mit freundlichen Grüßen, Thorsten Schöning Thorsten Schöning | IT Development ART+COM AG | Kleiststr. 23-26 | 10787 Berlin | Deutschland HRB 68308 | Amtsgericht Charlottenburg |
What decision take on this pull request? |
[FIXES JENKINS-10131] (for simple cases) Poll changes without workspace using git ls-remote
Hello,
during update of our company Hudson to the 2.2 branch we found a problem with manually starting a build for a project based on a git repo when no commits were made. It seems that the current version 2.2.0 of your plugin calls changeLogResult in GitSCM.checkout with a null-changelog which changeLogResult seem to handle as an error. changeLogResult returns false, which is directly delivered to Hudson which is aborting the manually started build. From my point of view it looks like you wanted to call changeLogResult to delete the current changeLogFile, else it wouldn't make sense to call the method at all with null, because it will always return false. This doesn't seem to be a practical behaviour because building manually without any committed changes to a repo should be possible. I therefore changed changeLogResult to the intended behaviour, else it would be neccessary to not call changeLogResult in checkout on no changes at all, but always return true in this case.
The second commit is just a rename of gerRevisionToBuild because this looks like a typo.