Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 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
  • Jan 20 2020 12:39
    rud review_requested #157
  • Jan 07 2020 15:20
    rud commented #157
  • Nov 20 2019 09:24
    rud commented #157
Dave Syer
@dsyer
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
I hate gradle sometimes
Do you think we could make this use case more mainstream in the plugin? That would help idiots like me.
Dave Syer
@dsyer
It works for me now (on Linux)
Not sure how it affects MacOS users
Matthias Grüter
@mattgruter
yeah, the configuration<>execution build lifecycle stuff is quite confusing in gradle IMO. many bugs lurking there... :-)
Dave Syer
@dsyer
It works now for me anyway, thank you.
Matthias Grüter
@mattgruter
why doesn't dependsOn: jar not work?
Dave Syer
@dsyer
Because the jar that is executable is not built by the gradle "jar" task
It is built by "bootRepackage" (so we could depend on that I guess)
Matthias Grüter
@mattgruter
That would be better, because the task build depends on tests and other findbugs, etc.
Dave Syer
@dsyer
I would expect to want to run tests etc before pushing a container image
It seems like the "last step" in a CI build to me
Matthias Grüter
@mattgruter
True. However, I tend to see buildDocker as a "assembly" step. build then ties together assembly and tests tasks.
Dave Syer
@dsyer
I see.
In which case we will need a custom task here whatever you do in the plugin
Matthias Grüter
@mattgruter
That's mostly a question of taste though. So dependsOn: build is definately ok, especially in a tutorial (short & conscise to read!)
But yeah in general, we should make your use-case more straight-forward with the plugin.
Dave Syer
@dsyer
because the plugin will never know that its default task should depend on something from another plugin that it doesn't require already
Matthias Grüter
@mattgruter
the plugin only creates a default task if the application plugin is used as well.
otherwise it doesn't create a task on its own
Dave Syer
@dsyer
I see. Well, somewhat accidentally, and for historical reasons, the "spring-boot" plugin also adds the "application" plugin
So that's always there in this use case
Matthias Grüter
@mattgruter
we recently started using spring-boot at work here so we'll be adding some more convenience into the plugin one way or the other. can't tell you when though... :-)
Dave Syer
@dsyer
Cool
Matthias Grüter
@mattgruter
in that case the route via the automatic distDocker is definately the most straight-forward and convenient. but then you won't reuse the Dockerfile from the maven example...
Greg L. Turnquist
@gregturn
Good morning. Glad to see this being polished up by people more gradle savy than me. I'll test the mods on my Mac when I get home.
Matthias Grüter
@mattgruter

hint: if you add

EXPOSE 8080

to your Dockerfile you can start containers with the -P/--publish-all flag.

Dave Syer
@dsyer
I know. But I don't know enough to know why it matters yet. It gets published to a random port.
I think for this tutorial it's not necessary anyway