The good news is that after the rebuild and downloading a new docker image,
things seem to be working fine now. I guess it's possible the image was not
properly downloaded but there was no indication of problems at the time.
Thanks for the shoulder to cry on.
On Wednesday, November 21, 2018 at
The answer to that is no. SSH only. I rebuilt the docker image badly (last
time I listen to the Internet on this one) - so I'm starting from scratch.
On Thursday, November 15, 2018 at 10:10:45 PM UTC-5, Mark Waite wrote:
>
> My working bitbucket.org multibranch Pipeline configurations include:
>
My working bitbucket.org multibranch Pipeline configurations include:
- Bitbucket branch source (username / password authentication)
- Git branch source using https (username / password authentication)
- Git branch source using ssh (ed25519 private key with passphrase)
Will your corporat
I have 2 idle executors on every node, so that's not it. The hang is
definitely waiting on a response from git fetch or git ls-remote depending
on the situation. Version of git on the Ubuntu VM is 2.13, so that's not
particularly recent, but sufficient for the function being executed. I
cannot
My passing tests were run from a master running in Docker with agents
running a mix of various operating systems including Windows, Linux
(CentOS, Debian, Ubuntu), and FreeBSD.
Mark Waite
On Thu, Nov 15, 2018 at 3:21 PM Randall Becker
wrote:
> I will continue to investigate. I am wondering whet
I’ll take a stab...How many executors do you have on the master and agent? You
may be hanging waiting for an executor to be available to run the pipeline. I
think I made this mistake once, had too few executors.
Meg
--
You received this message because you are subscribed to the Google Groups
I will continue to investigate. I am wondering whether there might be
something associated with running Jenkins in docker with Controller/Agent
structure.
On Thursday, November 15, 2018 at 5:18:31 PM UTC-5, Mark Waite wrote:
>
> I created a multibranch Pipeline with bitbucket.org as the source u
I created a multibranch Pipeline with bitbucket.org as the source using Git
as the branch source with a passphrase protected ed25519 private key. It
scans and builds as expected.
I can't duplicate the problem that you're describing. Before you spend the
time to submit a bug report, you may want
I created a multibranch pipeline with bitbucket.org as the source using the
Bitbucket Branch Source plugin. That plugin prompted for a username /
password rather than a private key. It won't accept a private key. I
believe it uses REST APII calls to reduce the overhead of checking for new
branch
There is also similar hang at fetch when the Jenkinsfile SCM is used. It
does appear that the credentials may not be supplied properly but there is
no indication that this is the case. I'm dropping back to Simple Pipelines
without SCM, sadly. This rather makes the whole point rather moot. Where
Hi Mark,
Yes, using a private key. This is a bitbucket.org site, which by my own
company's policy prevents me from using a passphrase-less credential. The
same key-pair is used elsewhere in other jobs in the same Jenkins without
problems. The job is a multibranch job, not a simple pipeline. A s
I assume from your description that you're using a private key with a
passphrase as the credential in the Pipeline job definition. I'm also
assuming it is a simple Pipeline job rather than a multibranch Pipeline.
Does the same behavior happen if you use a private key which does not have
a passphr
The original post showed the entire list of refs. No issue requiring a
timeout above 3 seconds actually. 10 minutes will make no difference. When
run from Jenkins from a shell command, the result comes back in seconds. I
don't think this is a performance issue. It is seeming to be a problem in
also, check the value of the TIMEOUT property, execute this code in the
Jenkins script console, the default value is 10 minutes, you can increase
it by setting the property in your command line
System.getProperty(org.jenkinsci.plugins.gitclient.Git.class.getName() +
".timeOut")
If you have ton
The interrupted exception resulted from my stopping the job instead of
waiting 10 minutes for the timeout failure. I am not on a shared
filesystem. Rather, this is inside a docker image running entirely on SSDs.
Speed is way above 100Mbps. As I said, no issue when using a freestyle
project and
Are you using a shared network filesystem for your JENKINS_HOME? it seems
like takes too long to save data, I guess your filesystem is too slow,
check if your filesystem speed is lower than100MB/s, if so, it is too slow
and you have performance issues on Jenkins.
```
java.lang.InterruptedExcep
16 matches
Mail list logo
