Closed loonychewy closed 5 years ago
rmpestano
commented
6 years ago It is probably related to #46, if you or @KLBonn want to hack I would accept proposed solution in #46 or an additional parameter to skip clean up. Just sent a PR and I can review and or guide you. There is a "running this plugin locally" section on README so you can test your changes.
loonychewy
commented
6 years ago Thanks for your reply, @rmpestano. I might give the proposed solution a try just to see if it works, will let you know again if I get to it.
Edit: I probably can't set this issue as duplicate cos I don't have write access. https://help.github.com/articles/about-duplicate-issues-and-pull-requests/ Please feel free to do it for me.
loonychewy
commented
6 years ago I tried the suggested solution here https://github.com/jenkinsci/last-changes-plugin/issues/46#issuecomment-395797467 , but it did not fix the problem. One more point to add is that this issue only occurs for me when I'm using LAST_SUCCESSFUL_BUILD, and there are no commits to the git repo from the last jenkins build and the current one.
Also, I noticed in LastChangesPublisher.java, line 281, the parameters for the resultMessage for "from revision" is lastChanges.getCurrentRevision, and "to revision" is lastChanges.getPreviousRevision, when it should be the other way round, am I wrong?
rmpestano
commented
6 years ago Hi @loonychewy,
I probably can't set this issue as duplicate cos I don't have write access.
Don't worry about that.
Also, I noticed in LastChangesPublisher.java, line 281, the parameters for the resultMessage for "from revision" is lastChanges.getCurrentRevision, and "to revision" is lastChanges.getPreviousRevision, when it should be the other way round, am I wrong?
sincerely I don't know if the "FROM" revision should be before or after, what's important is that we're diffing two revisions. Makes sense?
Do you need any help on fixing the issue? anything on code that you didn't understand?
loonychewy
commented
6 years ago Yes please, some help would be greatly appreciated because I'm not too familiar with git and jenkins. I'm suspecting something in GitLastChange.java or the classes it is using is still holding on to the file in the .git folder when we try to delete the folder.
As for the from and to revision, it might confuse those who are reading the log output, at least it seems so to me...
fm0195
commented
5 years ago Hello, I am facing the same issue as above. Can a try-catch block be used to print a warning instead of trowing an exception when deleting the copied files?
```
try {
vcsTargetDir.deleteRecursive();//delete copied dir on master
} catch(Exception e) {
listener.error("WARN: Could not delete copied files to master.");
}Hi @fm0195 , can you try with last-changes version below? This zip contains the fix from this PR #63, just unzip and upload/install the plugin on your jenkins instalation:
If we confirm it solves the problem I'll release a new version with the fix.
cutik
commented
5 years ago Hi @fm0195 , can you try with last-changes version below? This zip contains the fix from this PR #63, just unzip and upload/install the plugin on your jenkins instalation:
If we confirm it solves the problem I'll release a new version with the fix.
@rmpestano I can confirm that version from archive solves the issue, thanks for the solution!
rmpestano
commented
5 years ago v2.7.0 was released containing the fix.
Thank you guys.
Hi,
I'm trying to get the latest commit id from my git repo, if new commits are made since the last time the pipeline job was executed. Here's my scriptable pipeline script. (My git repo is checked-out to a subfolder "MY_REPO" of the jenkins workspace.)
But I get an exception at the end of the job execution, where it says it can't delete a file in the .git folder. I checked using ProcessExplorer, the file is still being locked by Jenkins process itself. I'm running the WAR version of jenkins using "java -jar jenkins.war". (Edit:) I'm using the pipeline (non-multibranch) type of Jenkins project However, if I use "PREVIOUS_REVISION" instead of "LAST_SUCCESSFUL_BUILD", I do not get this exception. My guess is that this plugin is still holding on to the file in .git folder when it is calling vcsTargetDir.deleteRecursive()? Or did I do something incorrectly here? The full exception stack is below: