Weird problem when running from Docker Hub
jponge opened this issue · 17 comments
I have a very weird problem with the plugin when run on Docker Hub (and only there).
Builds of jponge/golo-lang all fail, except those corresponding to Git tags: https://hub.docker.com/r/jponge/golo-lang/builds/
It looks like the plugin can't find commits, but I can't understand why.
Even more surprisingly it just works fine when building a Docker image locally.
Any idea?
Hi Julien,
Is it possible to have access to the details of the error? I cannot see any stack trace or similar detail. I had a look at your code at jponge/golo-lang and didn't find anything abnormal.
The only hypothesis I can advance is that the code is checked out with a detached head. I'm not sure the current version of the plugin supports this - in this case, I wouldn't have access to the branch itself, making several version fields unable to have a value.
Thanks,
Damien.
I also thought that it could be that the build checks out a shallow copy of the GitHub repository (without history) - this would make the versioning plugin failing to find the last tag. I'll try to support those two cases:
- detached head
- shallow history
I'll have to decide what to put in the version fields then. Any idea?
Hi Damien,
I'm afraid you can't get anything better than the bottom of https://hub.docker.com/r/jponge/golo-lang/builds/bikxqeixy78xa95feswhgdk/
I've done a quick check locally by putting my local repo into a detached head state, but that didn't make any change...
That could indeed be a shallow history checkout, but that isn't clear if this is what Docker Hub does.
Regarding fields, I think branch shall reflect (detached) or something like this.
The versioning plugin relies on history to get the last tag. If the repository has been checked in a shallow mode, then I won't be able to get it. Then what version should I use, difficult to answer this :(
When you build a tag, the problem disappears naturally, even in shallow mode.
I've not a lot of time nowadays, but I'll try to do as you suggest and at least mention that we're using a detached head or are in shallow mode.
FYI, the whole decision process is in GitInfoService in case you're interested in doing a contribution ;)
I can try having a look, but I'm short on time as well, it's a scarce
resource :-)
On 12/10/16 10:05, Damien Coraboeuf wrote:
FYI, the whole decision process is in ´GitInfoService` in case you're
interested in doing a contribution ;)—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#35 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABlafErJelx8YLn_iQIoB1SQRw-q119ks5qzJTDgaJpZM4KToPV.
No problem. Just don't expect a quick fix - maybe in a couple of weeks.
Hi Julien,
For the detached head, I chose to use HEAD as the branch and related fields. This is what JGit will return as a default, so I think it's OK.
In this case, if the detached commit is for example, abcd134, the display and full versions would be HEAD-abcd134.
What do you think?
Waiting for your answer, I'll work on the shallow case.
Best regards,
Damien.
About testing the shallow clone (which might be the root cause of your initial issue), the current JGit version doesn't seem to support the shallow clone option: https://bugs.eclipse.org/bugs/show_bug.cgi?id=475615
I'll dig a bit deeper though.
Damien.
Using a local uncommitted unit test using the git command directly, I'm able to create a shallow repository and to reproduce at least one problem. This might be enough to find a solution to your issue.
Hi Damien, the detached commit output that you propose is great!
Thanks
The detached head would not have raised an error. In the absence of any more detail about the error when building for Docker Hub, I assume the branch is checked out in a shallow mode. It would actually make sense. In this case, having a tag would return a result and if not, would fail.
I'll try to make this not fail now.
Hi Julien,
There is version 2.5.0 of the plugin containing a fix for a shallow repository.
Can you please test this? The integration tests tell it's OK but as I said, I don't know if I have fixed your error.
Thanks,
Damien.
Ok, I'll check when the plugin is available, I've edited the version in our build.gradle but it doesn't seem to be public yet.
It takes indeed a bit of time before the Gradle plugins are synched from Bintray to the Gradle plugin repository.