I have a number of builds that work very well from the command line, from buildship, etc.
However now I am porting them to a Jenkins system. And it is producing some very strange results. I’m pretty much a total newbie to Jenkins, so this may have an easy answer. So far I haven’t found it.
I am using the Gradle Plugin for Jenkins, v.1.24 to configure my build in Jenkins. However, Jenkins (at least as I have it configured) organizes its build structure as {jenkins root}/data/jobs/{project_name}/workspace. When code is checked out of source control it is deposited in that directory, not in a directory named {project_name}.
Gradle seems to assume that the directory in which it is running names the project, and when I’m running outside of Jenkins this assumption is true. The name of the project that Gradle sees is the name of the project that was checked out from source control. Project.name is gettable but not settable. So in the Jenkins case, the archives that gradle builds are named workspace* rather than {project_name}*. It is also named workspace in the repositories it publishes into. I must be missing something very obvious but for the life of me I cannot figure out what it is.
Once again my problem appears to be have been the “‘helped’ by Jenkins experts who know nothing about Gradle” syndrome. Another instance I started messing with without their help, organizes the system as {jenkins root}/workspace/{project name}.
Can someone here tell me if the assumption in gradle that
the project name IS the name of the directory it is located in
Hmm, thanks. I’ve not used settings.gradle except to configure multi-project builds. I guess nothing precludes doing so in single project builds?
Ok, I now have two possible solutions. Yours, and another suggestion for Jenkins configuration. I think I’m going to go with the Jenkins configuration way, but it appears that it may be good practice to include this minimal settings.gradle even in single project builds.