>>
>> Mark Waite
>>
>> Mark Waite
>>
>> On Tue, Sep 13, 2016 at 10:39 AM ok999 <nirish...@gmail.com> wrote:
>>
> I have a very simple job that polls the Git SCM, and if any changes if
>>> kicks of a downstream job. For the last 1 week, the Git
M ok999 <nirish...@gmail.com >
> wrote:
>
>> I have a very simple job that polls the Git SCM, and if any changes if
>> kicks of a downstream job. For the last 1 week, the Git polling fails with
>> the below error.
>>
>> *Git Polling Log*
>> *Started on
Yes, i am sure i ran the same command. I can also find the commit SHA
using: *git show 6f4eb3c55fd98c719baf898a9352a1100fa32765*
What confusing is, when the git polling fails, i can manually kick start
the job successfully. The job includes cloning the repo.
On Tuesday, September 13, 2016
TFS server at the time you see the
> issue?
>
> Mark Waite
>
> Mark Waite
>
> On Tue, Sep 13, 2016 at 10:39 AM ok999 <nirish...@gmail.com >
> wrote:
>
>> I have a very simple job that polls the Git SCM, and if any changes if
>> kicks of a downstream job. For t
Yes, i am sure. And to add to this, 1/ this issue is intermittent. 2/ IF
the git polling fails, i executed the build using "build now" and the code
checks out fine from the SCM.
On Tuesday, September 13, 2016 at 1:20:12 PM UTC-5, Mark Waite wrote:
>
> Are you sure t
Waite
Mark Waite
On Tue, Sep 13, 2016 at 10:39 AM ok999 <nirish.ok...@gmail.com> wrote:
> I have a very simple job that polls the Git SCM, and if any changes if
> kicks of a downstream job. For the last 1 week, the Git polling fails with
> the below error.
>
> *Git Polling L
I have a very simple job that polls the Git SCM, and if any changes if
kicks of a downstream job. For the last 1 week, the Git polling fails with
the below error.
*Git Polling Log*
*Started on Sep 12, 2016 9:44:04 AM*
*Polling SCM changes on Agent1*
*Using strategy: Default*
*[poll] Last Built
The previous plugin version is usually stored in the plugins directory as
plugins/*.bak. If you copy the plugins/*.[hj]pi file to a safe location,
you can then copy the .bak file over the existing hpi or jpi file. The
next time jenkins starts, it will unpack that file and use it as the plugin.
I am getting a similar problem:
I get this error:
SEVERE: found cycle in plugin dependencies: (root=Plugin:git,
deactivating all involved) Plugin:git -> Plugin:workflow-scm-step ->
Plugin:git
Followed by several exceptions.
How do I revert to the previous versions or upgrade to the
That worked. Thanks.
On Friday, 1 July 2016 14:56:54 UTC+10, Mark Waite wrote:
>
> You need to upgrade the workflow pipeline components in addition to the
> git plugin. The git workflow SCM step really belongs inside the git
> plugin, so we moved it there as part of git plugin 2.5.0.
>
> On
You need to upgrade the workflow pipeline components in addition to the git
plugin. The git workflow SCM step really belongs inside the git plugin, so
we moved it there as part of git plugin 2.5.0.
On Thu, Jun 30, 2016 at 10:55 PM Lionel Orellana wrote:
> Not related to my
Not related to my original problem which was fixed with one of the latest
builds, there is an issue with the Git plugin.
I get the errors I mentioned before when upgrading to 2.5.0 even with
jenkins core 2.12-SNAPSHOT. Manually reverting back to Git plugin 2.4.4
works.
On Friday, 1 July 2016
You need to upgrade the workflow pipeline components in addition to the git
plugin. The git workflow SCM step really belongs inside the git plugin, so
we moved it there as part of git plugin 2.5.0.
Mark Waite
On Thu, Jun 30, 2016 at 9:40 PM Lionel Orellana wrote:
> Thanks
Thanks Mark.
On Friday, 1 July 2016 13:28:40 UTC+10, Mark Waite wrote:
>
> Looks like that might be fixed in the latest source code. Refer to
> https://github.com/jenkinsci/jenkins/commit/6d29dd4554345aed2905e8ab32da678e301736a7#diff-b2027094e76e9b99db901e8cd779e580
> .
>
> Seems to be
If I upgrade the Git plugin to 2.5.0 from 2.4.4 I get
SEVERE: found cycle in plugin dependencies: (root=Plugin:git, deactivating
all involved) Plugin:git -> Plugin:workflow-scm-step -> Plugin:git
and all hell breaks loose.
WARNING: Failed to load
Looks like that might be fixed in the latest source code. Refer to
https://github.com/jenkinsci/jenkins/commit/6d29dd4554345aed2905e8ab32da678e301736a7#diff-b2027094e76e9b99db901e8cd779e580
.
Seems to be documented as a bug in Jenkins 2.11,
https://issues.jenkins-ci.org/browse/JENKINS-36232 .
I forgot that this job tries to check all branches as well and I wonder if
that is more of the cause. The credentials are stored within the local
repository so multiple Git repos probably wouldn't cause conflicts.
However, if a single repo checks out multiple branches, it of course does a
git
I'm able to reproduce the error with my test job if I have it restricted to
the same slave that the problem job is using. It happens with the single
SCM job that has multiple branches, but I haven't been able to reproduce
with just a single branch configurations, so I'm thinking it has to do
I haven't done the detailed review of the git capabilities, but I thought
that credentials support only first arrived in git 1.7.9 (or possibly
1.7.10). Your 1.7.9 machine may have a git version which is too old for
that use model.
Does the 1.7.9 based machine checkout successfully from a single
If I run manually, the slave with 1.7.9.5 is able to fetch the changes.
Only the polling is an issue. With the problem job switched to running on a
different slave with 1.8+, I am not currently seeing the issue.
On Friday, February 13, 2015 at 12:00:10 PM UTC-5, Mark Waite wrote:
I haven't
I was kinda thinking that, any suggestions on how I could debug this? Or
does someone know where the numbered credential file is named? If it is
based on a timestamp and the SCM plug-in checks both repos with the same
credential file, I could see how that could be a problem if one deletes it
You might be able to test the theory by creating a multi-scm job which uses
10 or 20 authenticated git repositories, then run that job multiple times.
If it fails, then it is probably the file delete condition we're theorizing
might be there.
If it does not fail, then it is likely something else.
I should add I'm using Jenkins 1.554.2, Git client plug-in 1.16.1 and Git
plug-in 2.2.12. It seems like this used to work, but I'm not sure what
version of each plug-in I had.
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from
I get this result from polling sometimes. This is a multiple SCMs
configuration. I don't believe I see this with single SCM setups. I see that it
cannot find the temporary credential path, but how is that even supposed to be
created?
Started on Feb 12, 2015 9:26:36 AM
Polling SCM changes on
The message indicates that a file which the plugin expects to be on the
file system is not there. That stack trace might hint that there is a
race condition in the multiple SCM plugin / git plugin interaction.
I don't know if the file is missing because the git plugin performed some
cleanup, or
25 matches
Mail list logo