repo auth problems in Jenkins v2.46 copied from working v2.19 instance

[David Karr]

I have a working Jenkins v2.19 instance.  I have a main pipeline job that references a Jenkinsfile in a BitBucket repo, accessed through a ssh url.  The Jenkinsfile references a global shared library, also stored in BitBucket with a ssh url.

I'm working with someone who's trying to upgrade me to v2.46.  He's set up the v2.46 instance and copied over everything from the 2.19 instance, including credentials.

When I first looked at the configuration of the main job in the new instance, inside the "Pipeline" "Definition" section, underneath the "Repository URL" field, it says this:

Failed to connect to repository : java.lang.IllegalStateException: Cannot open session, connection is not authenticated.

Despite this error, it let me run a build with this specification.  Initially, the build would fail at the point where it tried to obtain the Jenkinsfile, saying this:

java.lang.IllegalStateException: Cannot open session, connection is not authenticated.

After that point, the person I'm working with did some fiddling that I'm unsure about, and now we're almost in the identical state, as it's now able to obtain the Jenkinsfile, but it fails almost immediately afterwards, trying to obtain the global shared library, with the above exception.

When we were failing to obtain the Jenkinsfile, we thought perhaps this was a "known_hosts" problem.  We looked at the file on both boxes.  Both of them had an entry for the BitBucket server we were connecting to.  Now that we're getting the Jenkinsfile, but failing to get the shared library, I'm even more confused.

Besides the main Jenkins version difference, I noted the following version differences with git-related plugins:

old:
Git client plugin 2.1.0            
Git Parameter Plug-In 0.7.0            
Git plugin 3.0.1
   
new:
Git client plugin 2.4.6        
Git Parameter Plug-In 0.8.0        
Git Pipeline for Blue Ocean 1.0.1        
Git plugin 3.3.0    

Any ideas of what might be going on here?

[James Nord]

When you are trying to copy things you will generally find you have missed something, jobs with secrets won;t work as Jenkins will no longer be able to decrypt the secret etc etc...

Given the error is around authentication I would hazard a guess that this is the cause of your woes.

did some fiddling that I'm unsure about, 

Sounds like (without knowing the full story) that he was trying to fix the fact that it was an incomplete copy.

It's best to have a separate test instance with some replica jobs that you can test your upgrade on - then just create a backup of the prod instance and upgrade that when happy with the test instance.

[David Karr]

We've made progress with this, but at least one of the changes we made that fixed this does not make any sense to me.

For background, at one point, the Jenkins admin who was setting this up for me installed both git 2.4 and "jgit" on the box.  He thought at one time that the use of "jgit" should be preferred, so he put the "jgit" tool definition first in the list of "git" tool definitions.

So, today we were at the point where we get that "Failed to connect to repository" message in the configuration page.  In the "Git executable" field, we specify "git2.4".  When we run the build, it is able to get the Jenkinsfile from BitBucket, but it fails on the next step, trying to obtain the shared library referenced from the Jenkinsfile.

We then looked at the definition of the global shared library, and we noticed that it was specifying to use the "jgit" executable.  We then changed it to the "git2.4" executable and restarted the build.  It got past the referenced to the shared library, but then it later failed an explicit "git" pipeline step with an inscrutable error.  Note that my Jenkinsfile (pipeline not declarative) explicitly gets the "git2.4" tool and puts it into the PATH (although I'm no longer sure whether this is necessary).

We then went back to the job configuration page, and it still had the "Failed to connect to repository" message.

At this point, we then went back into the tool definitions and reordered the "git" executables, swapping the order of "jgit" and "git2.4".

We then inspected the job configuration page and now the error message we have been seeing was GONE.  We then reran the job, and the git pipeline step SUCCEEDED.

I will restate the fact that the job configuration page specifically refers to the "git2.4" git executable, as does the PATH setting in the Jenkinsfile.

So, it appears that on the configuration page, even though it specifically refers to the "git2.4" executable, it was somehow using the "jgit" executable when it was first in the list, which appeared to cause the connection failure.  Similarly, the "git" pipeline step fails if "jgit" is first in the list, and succeeds if "git2.4" is first in the list, even though I specifically obtain the path to the "git2.4" executable and put it first in the PATH before executing the pipeline step.

[Mark Waite]

If you previous server was not configured to allow jgit as a valid git implementation, and the new server allows it as a valid git implementation, then it is possible that the global pipeline library git configuration has been set to use jgit as its implementation.

Check that configuration and switch it to your preferred git implementation if needed.

I'm not aware of a bug which will cause any of the current git components to ignore the selected git implementation and use a different implementation.  If you can find a way to duplicate that condition, please submit a bug.

Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/ca58b6a1-6137-490e-ae8d-5955e880825a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.