I am trying to set up my first real gradle/Circle-CI project. But… I’m getting this error that I can’t figure out. Google isn’t much help…
FAILURE: Build failed with an exception.
* Where:
Build file '/home/ubuntu/BlueHuskyStudios/Blue-Base/build.gradle' line: 2
* What went wrong:
A problem occurred evaluating root project 'Blue-Base'.
> Could not find method id() for arguments [org.jetbrains.kotlin.jvm] on root project 'Blue-Base'.
It also gives this suggestion, but I don’t know how to follow it:
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
This all works just fine on my machine, so I’m guessing there’s a Gradle version mismatch? I’m on 4.10, but I can’t tell how to view/change CircleCI’s.
I’d suggest getting an SSH session on your red build and running the command it suggests. You can even edit files (e.g. with Nano) and do compile/debug there if required.
Remember that SSH eats your build minutes though, so remember to disconnect and then cancel the build in the UI.
This is saying to add the --stacktrace option when you execute the gradle command. Could you update your config.yml to include that option to help with debugging this?
replace
- run: if [ -a ./gradlew ]; then gradlew dependencies; else gradle dependencies; fi
with
- run: if [ -a ./gradlew ]; then gradlew dependencies --stacktrace; else gradle dependencies --stacktrace; fi
Thanks for y’all’s suggestions! I reran it with @levlaz’s suggested edit and… well there’s not much more info there:
#!/bin/bash --login
if [ -a ./gradlew ]; then gradlew dependencies --stacktrace; else gradle dependencies --stacktrace; fi
FAILURE: Build failed with an exception.
* Where:
Build file '/home/ubuntu/BlueHuskyStudios/Blue-Base/build.gradle' line: 2
* What went wrong:
A problem occurred evaluating root project 'Blue-Base'.
> Could not find method id() for arguments [org.jetbrains.kotlin.jvm] on root project 'Blue-Base'.
* Try:
Run with --info or --debug option to get more log output.
* Exception is:
org.gradle.api.GradleScriptException: A problem occurred evaluating root project 'Blue-Base'.
at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:54)
at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:143)
at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:38)
at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:25)
at org.gradle.configuration.project.ConfigureActionsProjectEvaluator.evaluate(ConfigureActionsProjectEvaluator.java:34)
at org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:55)
at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:507)
at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:82)
at org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:31)
at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:142)
at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:113)
at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:81)
at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:64)
at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:33)
at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:24)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:35)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:50)
at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:171)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:201)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:174)
at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:170)
at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:139)
at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
at org.gradle.launcher.Main.doAction(Main.java:46)
at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
at org.gradle.launcher.Main.main(Main.java:37)
at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:50)
at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:32)
at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
Caused by: org.gradle.api.internal.MissingMethodException: Could not find method id() for arguments [org.jetbrains.kotlin.jvm] on root project 'Blue-Base'.
at org.gradle.api.internal.AbstractDynamicObject.methodMissingException(AbstractDynamicObject.java:68)
at org.gradle.api.internal.AbstractDynamicObject.invokeMethod(AbstractDynamicObject.java:56)
at org.gradle.api.internal.CompositeDynamicObject.invokeMethod(CompositeDynamicObject.java:172)
at org.gradle.groovy.scripts.BasicScript.methodMissing(BasicScript.java:79)
at build_3lrlpcbsu7kii6202kqjtrls40$_run_closure1.doCall(/home/ubuntu/BlueHuskyStudios/Blue-Base/build.gradle:2)
at org.gradle.api.internal.ClosureBackedAction.execute(ClosureBackedAction.java:58)
at org.gradle.util.ConfigureUtil.configure(ConfigureUtil.java:130)
at org.gradle.util.ConfigureUtil.configure(ConfigureUtil.java:91)
at org.gradle.util.ConfigureUtil$configure.callStatic(Unknown Source)
at build_3lrlpcbsu7kii6202kqjtrls40.run(/home/ubuntu/BlueHuskyStudios/Blue-Base/build.gradle)
at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:52)
... 30 more
BUILD FAILED
Total time: 7.858 secs
Exited with code 1
I’m also not sure how @halfer’s suggestion of SSHing into it might fix anything, because I wouldn’t know how to use that to fix this. It just seems like something with CircleCI’s gradle isn’t set up like gradle is on my computer
Now I’ve been referred to in the third person, I feel like I’m interrupting
The SSH approach is simple: it originates from the approach of “how would I fix this if the error was on my local machine?”. By virtue of editing files and re-running the console command, you can work with the issue directly, rather than having to edit, commit, push, and trigger (which would work, but is much slower).
I’m unfamiliar with Java, but it looks like MissingMethodException is the core error. It might be worth checking the Gradle bug tracker in case this is a frequent item (a web search of Could not find method id() for arguments Kotlin produces a lot of results, but I don’t know how many are relevant).
Thank you for the suggestion, @halfer. I’m sure SSHing into CircleCI works for you, but I prefer a GUI environment; I can’t make my way around VI/Nano/Emacs/whatever to save my life. Plus, if this were a problem on my local machine, this thread right here would be how I try to solve the problem.
I sympathise Ben, but there is no GUI. Using the console, especially on remote machines, is bread 'n butter in a day of using Linux.
Nano is a cut-down editor and is fiendishly simple to use (the other ones are, it is often said, fiendishly complicated).
Sure, I understand that, and I won’t dissuade you from asking about general Gradle problems here. My general approach (both that I take for myself and that I recommend to others) is that not all problems on a CI platform are a CI problem. In other words, problems on CI can be related to a config/code/environmental issue, rather than a CI platform bug.
With that in mind, you could ask the question on Stack Overflow (etc) if you wished, since it strikes me it could be a general Gradle problem that could happen on any platform. We don’t have many helpers here, and some threads can go unanswered for several days.
@BenLeggiero one thing I noticed is that you are using the auto-generated template for Java and it is using the older “one size fits all” machine image. This thing is massive and is prone to issues, especially if you are using newer versions of various things.
@BenLeggiero try this config – it is working for me:
# This configuration was automatically generated from a CircleCI 1.0 config.
# It should include any build commands you had along with commands that CircleCI
# inferred from your project structure. We strongly recommend you read all the
# comments in this file to understand the structure of CircleCI 2.0, as the idiom
# for configuration has changed substantially in 2.0 to allow arbitrary jobs rather
# than the prescribed lifecycle of 1.0. In general, we recommend using this generated
# configuration as a reference rather than using it in production, though in most
# cases it should duplicate the execution of your original 1.0 config.
version: 2
jobs:
build:
working_directory: ~/BlueHuskyStudios/Blue-Base
parallelism: 1
# CircleCI 2.0 does not support environment variables that refer to each other the same way as 1.0 did.
# If any of these refer to each other, rewrite them so that they don't or see https://circleci.com/docs/2.0/env-vars/#interpolating-environment-variables-to-set-other-environment-variables .
environment:
TERM: dumb
CIRCLE_ARTIFACTS: /tmp/circleci-artifacts
CIRCLE_TEST_REPORTS: /tmp/circleci-test-results
# In CircleCI 1.0 we used a pre-configured image with a large number of languages and other packages.
# In CircleCI 2.0 you can now specify your own image, or use one of our pre-configured images.
# The following configuration line tells CircleCI to use the specified docker image as the runtime environment for you job.
# We have selected a pre-built image that mirrors the build environment we use on
# the 1.0 platform, but we recommend you choose an image more tailored to the needs
# of each job. For more information on choosing an image (or alternatively using a
# VM instead of a container) see https://circleci.com/docs/2.0/executor-types/
# To see the list of pre-built images that CircleCI provides for most common languages see
# https://circleci.com/docs/2.0/circleci-images/
docker:
- image: circleci/openjdk:8-jdk-node-browsers
steps:
# Machine Setup
# If you break your build into multiple jobs with workflows, you will probably want to do the parts of this that are relevant in each
# The following `checkout` command checks out your code to your working directory. In 1.0 we did this implicitly. In 2.0 you can choose where in the course of a job your code should be checked out.
- checkout
# Prepare for artifact and test results collection equivalent to how it was done on 1.0.
# In many cases you can simplify this from what is generated here.
# 'See docs on artifact collection here https://circleci.com/docs/2.0/artifacts/'
- run: mkdir -p $CIRCLE_ARTIFACTS $CIRCLE_TEST_REPORTS
# Dependencies
# This would typically go in either a build or a build-and-test job when using workflows
# Restore the dependency cache
- restore_cache:
keys:
# This branch if available
- v1-dep-{{ .Branch }}-
# Default branch if not
- v1-dep-master-
# Any branch if there are none on the default branch - this should be unnecessary if you have your default branch configured correctly
- v1-dep-
# The following line was run implicitly in your 1.0 builds based on what CircleCI inferred about the structure of your project. In 2.0 you need to be explicit about which commands should be run. In some cases you can discard inferred commands if they are not relevant to your project.
- run: gradle dependencies
# Save dependency cache
- save_cache:
key: v1-dep-{{ .Branch }}-{{ epoch }}
paths:
# This is a broad list of cache paths to include many possible development environments
# You can probably delete some of these entries
- vendor/bundle
- ~/virtualenvs
- ~/.m2
- ~/.ivy2
- ~/.bundle
- ~/.go_workspace
- ~/.gradle
- ~/.cache/bower
# Test
# This would typically be a build job when using workflows, possibly combined with build
# The following line was run implicitly in your 1.0 builds based on what CircleCI inferred about the structure of your project. In 2.0 you need to be explicit about which commands should be run. In some cases you can discard inferred commands if they are not relevant to your project.
- run: gradle test
# Teardown
# If you break your build into multiple jobs with workflows, you will probably want to do the parts of this that are relevant in each
# Save test results
- store_test_results:
path: /tmp/circleci-test-results
# Save artifacts
- store_artifacts:
path: /tmp/circleci-artifacts
- store_artifacts:
path: /tmp/circleci-test-results
Happy hacking.