|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I've been experiencing this issue as well. I found that it occurs with my build-pipeline. Initially, a clone is made from an Hg repository. This then kicks off a build of the source. If successful, I archive the workspace and then I trigger another job (to run lint). This downstream job uses the saved successful workspace.
I've noticed that when I manually trigger builds within Jenkins, at that point, the email gets screwed up. This occurs with a fresh (1.514) Jenkins build with only the Mercurial and Clone Workspace plugins installed. This occurs whether I do it on the initial build job or the downstream lint job. I'd been doing this (triggering builds manually) to test job configuration. My current workaround is to make a small comment change in my source, commit and push. Both jobs have email user who broke the build as a post-build step.
I didn't experience this bug when experimenting with build configurations using a project on a subversion repository.
To fix the phantom invalid user which Jenkins then recognizes for future SCM changes, I have to delete history of all builds that involve that user (if the build was successful, all jobs builds that it triggered), then restart Jenkins. At this point, the invalid user disappears and I can proceed. The other option is to just clone the jobs, then delete the old ones and rename them back. The downside of both approaches is that you lose a bit (or a lot) of build history.