NPE on pushing changes to GitHub with GH_TOKEN

[szpak]

An alternative way to push changes to GitHub (useful especially from CI server) is the usage of personal access token. Unfortunately it fails with NPE from jgit.

Caused by: java.lang.NullPointerException
    at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:476)
    at org.eclipse.jgit.transport.TransportHttp.openPush(TransportHttp.java:396)
    at org.eclipse.jgit.transport.PushProcess.execute(PushProcess.java:154)
    at org.eclipse.jgit.transport.Transport.push(Transport.java:1173)
    at org.eclipse.jgit.api.PushCommand.call(PushCommand.java:156)
    at org.eclipse.jgit.api.PushCommand.call(PushCommand.java:79)
    at java_util_concurrent_Callable$call.call(Unknown Source)
    at pl.allegro.tech.build.axion.release.infrastructure.git.GitRepository.push(GitRepository.groovy:80)
    at pl.allegro.tech.build.axion.release.domain.scm.ScmRepository$push$5.call(Unknown Source)
    at pl.allegro.tech.build.axion.release.domain.Releaser.release(Releaser.groovy:42)
    at pl.allegro.tech.build.axion.release.domain.Releaser$release.call(Unknown Source)
    at pl.allegro.tech.build.axion.release.ReleaseTask.release(ReleaseTask.groovy:40)
(...)

I debugged it briefly and GH returns 401 on the first connection try and in the second attempt it does not have a credential provider which causes NPE. In jgit master they modified code and more verbose TransportException would be probably throw.

I din't dig into that, but the connection URI is:

https://my-very-long-token@github.com/foo/bar.git/info/refs?service=git-receive-pack

which returns 401 (Unathorized). After change it (in debuger) to just https://my-very-long-token@github.com/foo/bar.git/ it returns 200, but later fails on NotSupportedException: remote does not support smart HTTP push.

Steps to reproduce:

1. Checkout any project with Axion configured from GH.
2. Change remote url to url = https://${YOUR_GH_TOKEN}@github.com/you/your-project.git
3. Call ./gradlew release.

Btw, manual push with mentioned configuration works fine. Tested with Axion 0.9.9.

[adamdubiel]

My testing branch has support for CredentialsProvider - username + passwd via console (which is pain in gradle..). I will take a look at proper config of CredentialsProvider using GH, there might be some jgit magic involved.

[szpak]

I tried to it with GrGit directly and it seems GrGit itself doesn't support passing credentials via the URL (pushing with jgit directly was too complicated for me and I gave up :) ). I wasn't able to find your testing branch with username/password support, but it would be good that you provide way to pass username and password in the configuration closure - to set it programmatically (from environment variables).

Btw, if you would like to add something more before 1.0.0 maybe it would be good to release 0.9.10 earlier?
Btw2, VersionConfig becomes larger and larger. Maybe (as it is still before 1.0.0) it would be good to move git/repository configuration into a subelement?

[adamdubiel]

Providing passwords via config closures and interactive mode as just one set of closures is a nice idea, i will implement it. I didnt have time to polish interactive mode last week, but i will push the branch to remote. I could use some more testing on this one - think you could help me out? I can't tell if it will behave nicely on different kinds of terminals.

[szpak]

Some time ago I did simple asking about passphase for PGP key in my plugin, but it requires to run in non demon mode. In the meantime I have seen a solution which works also from daemon (I can try to find it again). I don't know if it could be automatic tested in the reliable way.

Btw, yesterday when I was working on NPE with jgit I discovered that GrGit has quite nice support for authorization. It supports SSH agent, pyagent from Putty (unfortunately no Gnome keyring) and interactive asking in a platform specific way (on Linux there is a small Swing window). I haven't tested, but maybe when X server is not available a question on the console is used? Maybe it could be reused in some way?

[adamdubiel]

I think i will get involved in grgit devlopment more, because it feels like were doing stuff that could be used by more people if it was exposed in library like grgit. I will leave this open past 1.0.0.

Or maybe there's place for some general-purpose java jgit wrapper library, because it's a pity grgit is so groovy/gradle centric. Can't say i have much time for this kind of involvement though :P

[adamdubiel]

I came to revisit this issue, as i had some need for Basic Auth/GitHub tokens :) I did not like passing GH Token via system variables (Grgit way), so i made own, simple implementation consistent with already present ssh keys supports. Usage is simple and straightforward:

./gradlew release -Prelease.customUsername=<myGithubCode>

Just be sure to checkout repository as https://github.com/..., without any codes inside. Documentation is also present.

[szpak]

Sounds ok. Secure variables are masked in Travis and in addition probably release.customPassword could be also set within a build script (like dryRun).

[szpak]

Btw, you have a wrong milestone for that issues - 1.0.1.

[adamdubiel]

Exactly, it can be set in runtime (see the docs).