Since that message comes from the server side, I think you may need to talk
with the people providing your git server.
You might create a job or two which retain their full history and only
perform polling and cloning with no build step.
Another step might be to create a separate script running o
TESTING if my post is reaching the group or not.
#Keep getting a msg saying messages have been deleted
On Tuesday, September 13, 2016 at 1:20:12 PM UTC-5, Mark Waite wrote:
>
> Are you sure that you executed the same commands when trying to duplicate
> the problem? The message seems to be f
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 at
>
> Yes, i am sure that i used the same command for duplicating. I can see the
> commit just fine via: *git show #{SHA}*
>
Moreover, the job executes successfully when started manually. And it
involves cloning the repo.
On Tuesday, September 13, 2016 at 1:20:12 PM UTC-5, Mark Waite wrote:
>
>
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 that you executed the sam
Are you sure that you executed the same commands when trying to duplicate
the problem? The message seems to be from your server and seems to say
that a specific sha1 cannot be found in the remote repository.
Is there any server maintenance on your TFS server at the time you see the
issue?
Mark W
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.
M
It also seems related to this
https://issues.jenkins-ci.org/browse/JENKINS-36249
But without the UI, how do I change the plugin being used?
On Wednesday, August 10, 2016 at 4:15:00 PM UTC-7, Tecno Brain wrote:
>
> I am getting a similar problem:
>
> I get this error:
> SEVERE: found cycle
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 righ
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 Th
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 original problem whic
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 Mark.
>
>
> On Friday
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 document
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
net.uaznia.lukanus.hudson.plugins.gitparamet
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 . Y
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 d
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
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 wit
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 c
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 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
an
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
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 fro
24 matches
Mail list logo
