Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 07 05:03
    lcardozo-tl commented #160
  • May 28 17:31
    smilebat96 opened #161
  • May 05 20:56
    dushshantha commented #160
  • Oct 05 2021 15:45
    schowdiah commented #65
  • Sep 16 2021 09:57
    kxalex commented #160
  • Sep 16 2021 09:56
    kxalex commented #160
  • Sep 10 2021 12:07
    robyp1 commented #65
  • Sep 10 2021 12:06
    robyp1 commented #65
  • Jul 14 2021 09:17
    jcfandino closed #116
  • Jul 07 2021 12:48
    rud closed #157
  • Jul 06 2021 12:47
    rud commented #157
  • Jun 11 2021 10:50
    mpetuska commented #159
  • May 31 2021 17:44
    asasisekar edited #160
  • May 31 2021 17:43
    asasisekar opened #160
  • May 29 2021 07:38
    Abhi1401 commented #90
  • May 29 2021 07:37
    Abhi1401 commented #29
  • May 29 2021 07:35
    Abhi1401 commented #90
  • Jan 19 2021 14:38
    jc9464 opened #159
  • Aug 20 2020 11:48
    mgerhardy opened #158
  • Feb 21 2020 15:42
    philbrock commented #135
Dave Syer
@dsyer
Or else get you to comment on how we did it wrong so far
Matthias Grüter
@mattgruter
Great! we're working on a new dockerfile DSL. I'm about to merge the changes hopefully during the Easter holiday. The idea is to be able dockerfile instructions in the build.gradle more naturally. Something as follows:
dockerfile {
   ADD file /
   RUN ...
   CMD ["foo"]
   ...
}
Matthias Grüter
@mattgruter
I've been close to a new 1.3 release of the plugin for some time now but never got around to actually do the final finish. When are you officially publishing your guide? Version 1.3 will simplify a few things: nicer Dockerfile syntax (see above), availability of the plugin through the plugin protal and other changes.
Dave Syer
@dsyer
I think we prefer to use an external Dockerfile. is that a bad idea?
Matthias Grüter
@mattgruter
No, that works as well. We have some improvements on the dev branch (also scheduled for 1.3) that will help with external Dockerfiles above all a fix for Transmode/gradle-docker#29
Dave Syer
@dsyer
But the original Dockerfile might be in src/main/docker
Matthias Grüter
@mattgruter
I'll try to look through your guide during the weekend.
Dave Syer
@dsyer
It would have no built artifacts in its context at all in other words
You don't want Dockerfile in the root of your project, otherwise loads of rubbish could end up in the container
Matthias Grüter
@mattgruter
ok, then Transmode/gradle-docker#29 doesn't affect you
Dave Syer
@dsyer
It does, sort of
In the sense that we would like a better solution than we have
We are more or less forced to copy the build artifacts using imperative Groovy into the Dockerfile's context
I think the approach in the maven plugin is sound (the one from Spotify )
They let you declare in the plugin config which "resources" (or artifacts) to make available to the Dockerfile
Matthias Grüter
@mattgruter
Great, I'll look at how they solved it.
Dave Syer
@dsyer
We use it in the guide
Matthias Grüter
@mattgruter
The new dockerfile stuff would allow you to use an external dockerfile and the augment it in the build.gradle with ADD/COPY instructions there and the plugin will take care of the rest. Not sure if that would help you though.,
Dave Syer
@dsyer
That might be useful in general
Specifically for this guide we want to have the same Dockerfile work for Maven and Gradle (I know it's slightly artificial, but we always try and support both)
In the Maven plugin as soon as you use an external Dockerfile everything else is ignored
So maybe I prefer your approach slightly, but we still have to work around one or the other
Matthias Grüter
@mattgruter
Ok, I see. Looking at the guide right now.
So you're copying your jar file into the docker stageDir (build/docker) manually.
Dave Syer
@dsyer
Yes
And that also means we have to define a custom task
Matthias Grüter
@mattgruter

Wouldn't something like:

copy {
    from jar
    into stageDir
}

work?

Dave Syer
@dsyer
and that it has to be deferred with "<<"
I'm not a gradler. Happy to take edits.
Where does that go?
Inside the task definition?
Matthias Grüter
@mattgruter
Yes, instead of the new File(stageDir, jar.archiveName).bytes = jar.archivePath.bytes
Dave Syer
@dsyer
Trying it...
Dave Syer
@dsyer
I don't think that worked
the image it builds has the same ID as docker/java
Actually that's a problem with the "<<" (cc @gregturn)
Matthias Grüter
@mattgruter
Exactly. The dockerfile, applicationName and push properties have to be defined in the configuration phase of the build not the execution phase (with the "<<" you push everything into the execution phase)
Dave Syer
@dsyer
Yeah. I'm unhacking that now.
Then the copy{} works, thanks
Matthias Grüter
@mattgruter
This should work:
task buildDocker(type: Docker, dependsOn: jar) {
  push = false
  applicationName = jar.baseName
  dockerfile = file('src/main/docker/Dockerfile')
  doFirst {
    copy {
      from jar
      into stageDir
    }
  } 
}
Dave Syer
@dsyer
@gregturn thought he found a problem that meant he had to defer to execution
It works for me though
Actually that doesn't
You have to "dependsOn: build"
(which I assumed would be the default - haven't tried that yet)
How come I have to explicitly create a java.io.File() for the dockerfile BTW?
Yeah you need "dependsOn: build"
but the copy actually doesn't work
doFirst
Missed that