Authentication failing when attempting origin push when run inside a jenkins job #145
Comments
bedge
changed the title
|
Are you getting a stacktrace or is it just not completing the actions you expect? The output doesn't seem to match up with the way your task is coded (missing some printlns that I would have expected to see). Can you confirm that this is the full output from the code you posted? |
|
Apologies, that was form a run pre-debug statements. Here's the latest run from the same code. |
|
To answer your other question, I'm wondering why the push is not working when run from jenkins. The branch is created in the local repo, but is not propagated to the server. |
|
This sounds like it's the same as #137, though you're using a custom task instead of Since you're suppressing the exception, I can't tell exactly what the issue. Would you mind modifying your task to print/throw the exception and post the resulting stacktrace? |
|
Apologies for the delay. Had to wait until next release cycle. Here's the output, running Is it as simple as it looks and it's just an ssh key mismatch between the client and server? gitbranch.gradle:74 is: |
|
There are some reports of UnknownHostKey issues in ajoberstar/grgit#82. I think it should use your normal known_hosts file, but that issue indicates that it doesn't for some people. |
|
It is not always convenient to add the fingerprint to known_hosts (for example if you build server is expendable and tho only constant is its URL). There is a workaround exists: |
|
I'll consider this a |
|
For some reason these comments aren't appearing in the issue history, so I haven't looked into the hostkey check yet, but plan to do so when I get On Thu, Feb 18, 2016 at 1:30 PM Bruce Edge notifications@github.com wrote:
|
|
Thanks Andrew. It is odd that only this push one action appears to use different authentication than every other grgit action I’m doing. -Bruce From: Andrew Oberstar notifications@github.com For some reason these comments aren't appearing in the issue history, so I haven't looked into the hostkey check yet, but plan to do so when I get On Thu, Feb 18, 2016 at 1:30 PM Bruce Edge notifications@github.com wrote:
— |
|
Is there something in the logs indicating that the other operations are On Thu, Feb 18, 2016 at 7:37 PM Bruce Edge notifications@github.com wrote:
|
|
Hmm, good point on the push aspect being different. All other operations are on the local repo. The push is the only one that forces an operation on the remote. I'm not using any explicit authentication, and I just use: to get a repo instance. Do I need to specify authentication options for remote repo operations? The link you mentioned, for AuthConfig, states: To me this implies that hard-coded, ssh-agent, and pagent have all been tried and failed before it resorts to putting up a dialog box for interactive credentials. The git credentials are ssh based and github does have the public key tied to the account. IOW all git shell operations do not require a prompt. I've gone back to catching the error around the push and simply doing a 'git push' from the shell after the task completes. |
|
Yes, the logic is basically as follows, and any of the options can be disabled:
Are you using either of the agent based approaches? Or is there something else caching your credentials when you use the Git CLI? |
|
I'm using ssh based URLs for the repos, eg: and my public key is registered with github, as this works on OSX & Linux identically. |
|
Maybe try setting this system property to specify exactly which key to use:
|
|
@ajoberstar @bedge I may have stumbled upon a work-around for this issue. Perhaps you already know about this, but when I encountered this problem, it was because my known_hosts file had an ECDSA key in it while jsch wants an RSA key. I had to delete the ECDSA key from known_hosts and add the RSA key. Here are a couple stackoverflow answers that helped me understand: http://stackoverflow.com/a/15314924 http://stackoverflow.com/a/34478483 |
|
That's good to know. I wonder if the newer versions of JSch (grgit currently uses 0.1.49), which mention ecdsa, might fix this. |
|
As a summary, it's basically because the default auth for github is not working. |
I have a problem where my createReleaseBranch task works when I run it locally, but fails when run from a jenkins CI job.
Here's the output, note that createReleaseTag works fine, but my createReleaseBranch does not:
I'm hooking into this plugin in my own gradle script using:
where createReleaseBranch is:
I want to create a branch from develop called release/XXX and push it to the origin.
Is there something I'm missing here?
The text was updated successfully, but these errors were encountered: