heroku / heroku-buildpack-gradle

Heroku's buildpack for Gradle applications.

Heroku buildpack: Gradle

This is a Heroku buildpack for Gradle apps. It uses Gradle to build your application and OpenJDK to run it.

Usage

1. Install the Gradle Wrapper into your project.
   • This allows control over the Gradle version and exact distribution to be used.
2. Specify the Java version to be used as per these instructions.
3. If you are not using Spring Boot or Ratpack, then follow the instructions for configuring your build.

You do not need to explicitly declare that your project should use this buildpack. The presence of a gradlew script in the root of your project will allow the fact that your app is built with Gradle to detected.

The bin directory of the installed JDK is placed on the PATH for process execution (i.e. the java command is available to start the app).

heroku-buildpack-gradle's Issues

Add java-agent to /app/.java-agent

Pull java-agent into slugs so people can use it as needed.

Cache project-level cache between builds

Project level cache (stored, by default in root project's .gradle directory) is not cached between the builds. Because of that, projects need to be always fully rebuilt irrespective if there were changes or not. Gradle has a switch (--project-cache-dir) that can be used to set this directory.

Add support for detecting gradle kotlin dsl files

Current bin/detect script only detects regular gradle files (gradlew, build.gradle and settings.gradle).
With kotlin dsl for gradle being more and more popular, it would be nice to have support for detecting build.gradle.kts and settings.gradle.kts as well.
It would require changing the bin/detect script just a little:

...
elif [ -f $1/build.gradle ]; then
  echo "Gradle" && exit 0
elif [ -f $1/settings.gradle ]; then
  echo "Gradle" && exit 0
...

to

...
elif [ -f $1/build.gradle ] || [ -f $1/build.gradle.kts ]; then
  echo "Gradle" && exit 0
elif [ -f $1/settings.gradle ] || [ -f $1/settings.gradle.kts ]; then
  echo "Gradle" && exit 0
...

Update gradle distribution to latest 1.10

Upload latest gradle 1.10 to AWS and update scripts to reflect the change.

Runtime does not have access to gradle app

If the user launches the app with a gradle task (e.g. "gradle jettyRun"), it does not work because the gradle app is in the cache dir, but never copied into the build dir. Maybe we don't want this and have the user always run their app from a main method, but I think it should be the same as what is possible with the Java/Maven buildpack (e.g. mvn jetty:run). In that buildpack, the mvn binaries and user .m2 are copied into the build dir for access by the Procfile

Invalid add-on specification. Buildpacks must inform addons as a string.

When I did a deploy using git push today (2 Apr 2014), the build was successful, but the launching of the app was rejected with the error message: "Invalid add-on specification. Buildpacks must inform addons as a string."

I had performed the same procedure successfully 7 days ago. So it is likely that some changes in the buildpack in that period broke it.

Heroku CI slow builds

Hi,

I've been having a dialogue with Heroku Support about the speed of the build in the Heroku CI tests. In general there's not much they can do there they say. So I'm asking here even though I realize it's kind of a long shot. Hoping there might be some Gradle specifics that can make it faster. :)

I notice it takes about 2:30 before anything starts happening in the build output "-----> Auto detecting buildpacks...". I also see it downloads Gradle (through gradlew) on every run. Is it the Git repo that drives the time to start? Is Gradle using more disk activity than others when building, that makes it slower?

Is there something we can do on our side to optimize the run-time? Our tests are (relatively) fast, so it's about 20% of the run-time. Even parallelizing the build on Heroku doesn't yield any extra performance because it's the surrounding stuff that takes time.

Thanks,
Anders,

Add Beta note to build output and readme

Once Cedar is GA all standard buildpacks will also be GA unless otherwise noted. Gradle is still beta so the build output and readme should state this.

Allow custom task to be used to build

Files missing from build

I have a gradle build script that creates static files and adds them to a jar file but when the buildpack runs, my application doesn't seem to have the files. When I run the build locally, everything works fine.
Here is the script:

dependencies {
  compile(project(':shared-assets'))
}

jar {
  appendix = 'client'
}

def ngDistDir = project.projectDir.absolutePath + '/dist'

task ngBuild(dependsOn: npmInstall, type: NpmTask) {
  // Incremental build support.
  inputs.dir('src/')
  inputs.files(
    '../shared-assets/semantic/dist/semantic.min.css',
    '../shared-assets/semantic/dist/semantic.min.js'
  )
  outputs.dir(ngDistDir)

  args = ['run', 'build']
}

copy.dependsOn ngBuild
copy {
  from ngDistDir
  into project.buildDir.absolutePath + '/resources/main/static'
}

Am I doing something that isn't supported?

Require gradle wrapper and use `gradlew` script as detection hueristic

Hi,

I think it would be better for everyone if the buildpack required the Gradle wrapper. All projects should use the wrapper and relying on the version provided by Heroku is fragile at best.

I'm happy to supply the PR if it's agreed that this is the way to go.

About specifying java version

The reason why I choose to use Buildpack in Gitlab is to make my project much simpler, fewer files (like dockerfile, .gitlan_ci.yaml). However, in order to specify the java version, I need to add a system.properties. That is some kind against my purpose. So I wonder is there any other way to specify a java version, such as adding project variable or anything else.

License?

Hi, could you clarify what license this code is under please?

Allow caching arbitrary directories during build

In order to facilitate at least partially incremental builds in Gradle, it would be good to cache some data between builds. One way to do that would be to utilize Gradle's Build Cache but that's a more advanced approach which requires that the tasks support caching. (I suppose build cache support could be added to this buildback at some point, as an option)

For now I propose creating a "mirror" of cached directories under $CACHE_DIR/.gradle-additional-cache-dirs by creating corresponding symlinks, if the environmental variable $GRADLE_ADDITIONAL_CACHE_DIRS is set. The variable would contain relative directories to be cached, separated by :, e.g. build:src/main/frontend/node_modules

Some caveats:

• This solution is not perfect, as, in many cases, Gradle's up-to-date checks rely on absolute paths, which are, unfortunately, different on every Heroku build. But it's still a step forward.
• No directories with : in directory name (same limitation as with, e.g. $PATH variable
• No validation whatsoever (e.g. nested directories, etc.)

Code in this commit. I can create a PR if necessary.

This also solves #19

Couldn't follow symbolic link on each deploy

The first time I create an application, everything works fine, but all subsequent deploys fail during the nodeSetup task with this error

Failed to capture fingerprint of output files for task ':nodeSetup' property 'nodeDir' during up-to-date check.
       > Could not list contents of '/tmp/build_f8eae163382a61b2896d7be434b4dc58/.gradle/nodejs/node-v8.12.0-linux-x64/bin/npm'. Couldn't follow symbolic link.

I have to create a new heroku project every time I want to deploy this. So, it only works for the first time. Even if I clear the cache using ./gradlew clean, it fails during the build because it does not clear the .gradle folder

If I SSH into the project and manually run ./gradlew build, it works without a problem. The error only happens during the heroku build process (of the buildpack)

I am using https://github.com/srs/gradle-node-plugin in order to use webpack for the frontend in the project https://github.com/zhcet-amu/zhcet-web.

I guess similar issues have been encountered by many people. This may be due to caching the directory and trying to access non-existent one on second deploy?

Personally, I don't care if anything is cached or not and rebuilding takes longer as currently, deployments don't even work. I'd love to send a PR if guided in the direction of what needs to be done here, but for now, is there any workaround I can do?

I am looking for anything that can either let me clear the cache before building starts, or customize the build command to a different gradle task, or anything else that may help

Thanks

Remove Gradle version hardcoding from buildpack

Instead of hardcoding the Gradle version in the buildpack, have the buildpack check what versions are available in S3 and dynamically choose the version.

Gradle buildpack should not specify "Java" in detection

Detection specifies "Java/Gradle", but should just specify "Gradle" because it can be used for any Gradle build, not just Java ones

Consider Adding Node and NPM Caching

Some builds use node and NPM (via the gradle-gulp-plugin), but those artifacts aren't cached during the build process. Consider adding support for node and NPM caching between builds.

ERROR: JAVA_HOME is not set and no 'java' command could be found in your PATH.

The buildpack has a conceptual problem.

Compile installs the required jdk and sets the required environment variable JAVA_HOME, then calls gradlew <buildCommand> .

Test-Compile first executes Compile and then calls gradlew resolveTestRuntime without setting JAVA_HOME so it fails with the error in the title. Unless naturally your image has a java in $PATH which might or might not be the one you wanted to use. But the script just exits, the buildpack call doesn't return an error. So the pipeline continues. I guess its not a problem if you don't have testRuntimeDependencies.

The Test step btw. doesn't do much setup either so it downloads gradlew a second time before executing the tests.

Test-Compile probably should source Compile.

Test should get the needed configuration so it doesn't download gradlew twice

Gradle dependencies are re-downloaded at runtime when using gradlew

When gradlew is used for both a build and launch processes in the Procfile, the dependencies are re-downloaded because the repository is not shared between the build and runtime launch. If the download takes more than 60 seconds, this error results:

2011-10-22T19:52:37+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2011-10-22T19:52:37+00:00 heroku[web.1]: Stopping process with SIGKILL
2011-10-22T19:52:37+00:00 heroku[web.1]: Process exited
2011-10-22T19:52:38+00:00 heroku[web.1]: State changed from starting to crashed

This might also occur with the included (non-wrapped) gradle, but the runtime doesn't even have access to this (@see issue #2). Once that is fixed, this issue can be re-evaluated to see if the scope is even larger.

In the Java/Maven buildpack, this seems to be solved by caching the repository, so probably a similar solution is needed for Gradle.

Constant R14 Memory Quota Exceeded with basic Spring Boot application

Hello,

I have a basic Spring Boot application deployed on a hobby tier Heroku instance and it's been throwing R14 Memory Quote Exceeded near constantly. The application is literally a couple REST endpoints connecting to a database.

I've been trying to track this down for a some number of hours across a few days now and don't seem much closer to a solution. I have turned on Enhanced Language Metrics and see the following

My application is started via java -Dserver.port=$PORT $JAVA_OPTS -jar build/libs/*.jar.

Based on https://devcenter.heroku.com/articles/java-memory-issues#configuring-nativememorytracking, I have JAVA_OPTS set to -Xms256m -Xmx256m -Xss512k -XX:NativeMemoryTracking=detail -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics in the config vars.

The issue https://github.com/metabase/metabase-deploy/pull/5 and metabase/metabase#3360 make me suspect I'm not the only one having trouble tuning the JVM to run below the 512 MB limit for these Heroku dynos.

Does anyone have more information or suggestions to reduce the memory footprint? It's a little unnerving to see the application consume so much memory for minimal functionality.

Thanks!

Spring Boot detection fails for several cases

Spring Boot detection code at here fails to detect several cases:

• using the verbose format of compile group: 'org.springframework.boot', name: 'spring-boot-starter-test'
• having a multi module structure and using boot dependencies only in submodules instead of root module
• not having dependencies in root and using plugins block to include spring boot plugin

Possible solution: changing regex to "^[^/].*org.springframework.boot". Removing :spring-boot handles these problems unless there was a specific reason for that part to be present. In that case above cases could be handled separately.

./gradlew stage doesnt work unless pushing to heroku HEAD:master

Ive been working on a multi project gradle application, i was ready to test it out on heroku and follow all instructions on documentation for heroku gradle applications.

Because i already had the repo i just add the remote branch to my repo and tried pushing but resulted in this:

remote: -----> Using set buildpack heroku/gradle
remote: -----> Gradle app detected
remote: -----> Installing OpenJDK 1.8... done
remote: -----> Installing Gradle Wrapper...
remote:        WARNING: Your application does not have it's own gradlew file.
remote:        We'll install one for you, but this is a deprecated feature and
remote:        in the future may not be supported.
remote: -----> Building Gradle app...
remote:        WARNING: The Gradle buildpack is currently in Beta.
remote: -----> executing ./gradlew stage
remote:        :api:compileJavaNote: Some input files use unchecked or unsafe operations.
remote:        Note: Recompile with -Xlint:unchecked for details.
remote:        

Even though all the files that need to exist for gradle to work are commited and tracked, however when i push to HEAD:master then the gradle wrapper is detected and starts my build and succeeds.

heroku CI: compilation during "test setup" and "test" fase

Hi there,

We are using heroku-buildpack-gradle with kotlin.

During a ci test run, I see that everything is compiled twice, both during the test-setup and test phase

When specifying a custom "dummy" gradle task for the test-setup fase, it runs 2.5 mins faster.

While reading the bash scripts, I got the impression that build artefacts should be cached between phases.

Any tips?

Build pack should use $CACHE_DIR/.gradle as GRADLE_USER_HOME

This will help to avoid collisions in the cache dir.