At my job we use gradle, so on my laptop I have a ~/.gradle/init.d folder which contains the init scripts that define our enterprise-wide configuration, such as the URL of the local repository, docker publishing rules, checkstyle rules, etc.
I want to use gradle for a personal project, so I don't want to use any of these init scripts. Here are the ideas I have come up with so far:
Rename ~/.gradle to ~/.gradle-work, create ~/.gradle-personal, and then symlink ~/.gradle to -work or -personal depending on what I'm doing.
Have ~/.gradle as my personal gradle settings, and create another gradle folder ~/dev/work/.gradle with all my work init scripts. Make sure $GRADLE_HOME is set to ~/dev/work/.gradle when running gradle for any work projects.
Some variant of 2 where gradle will automatically use ~/dev/work/.gradle if it detects that the project is in the ~/dev/work/ folder.
Option 1 feels quite clumsy. Option 2 feels very tedious to have to set or unset an environment variable whenever I want to use gradle. Ideally I would like something like option 3 where I don't have to do any fiddling around whenever I change between personal or work projects. Is this possible? Or is there another solution that could solve my problem?
Related
I have a source code using which I want to test some processes through Jenkins.For that I've installed Jenkins and plugins as well. But I do not have internet access to my machine so I have my source code in a local folder instead of Git.
Please help me to configure Jenkins without git.
Thanks a ton in advance.
in the build steps, you can do something like
cd C:\users\user\Documents\Projects\
// build here
if you're in a different directory, you need to do:
cd D:\Projects
D:
// build here
But deleting the workspace option won't work now. since your artifacts will be stored in the current directory and the workspace is a different directory. you can add an additional step, in this case, to clean up things or you can change the workspace from the advanced option in the general tab.
I'd like to build certain projects without the use of of Gradle daemon. I've read that this can be done either by command-line argument --no-daemon or by changing Gradle properties under .gradle/. I need to disable it for just some of the projects I build under the root project though.
Is it possible via settings.gradle/build.gradle settings or am I better off making custom build script?
You can simply add org.gradle.daemon=false to a gradle.properties file in the project root folder.
The daemon documentation mainly talks about disabling the daemon altogether on a machine but the gradle properties documentation indicates that the location where a property / value pair is declared is irrelevant, they are sourced from different location, with overwrite rules.
I need to execute groovy script with gradle, but the thing is that these scripts are located in external directory (let's say it's Desktop). I've heard, that in previous versions of Gradle (currently working on 3.2.1) it was not possible, since it is not part of the gradle project. I wonder if it is possible now, or do I have to copy all these scripts into some folder located in gradle project, to execute it.
User story:
I found script in external directory (based on some properties passed to console) - I have absolute path to the script
Now I want to execute this script (build.gradle) without copying it into my gradle project
I'm pretty green with gradle and I hope I made my point clear.
Thanks for help and every attempt :)
Is that what you're looking for? To run the script clone the repository, navigate to 42556631/project folder and run the command:
gradle -b ../script/build.gradle clean build
yes you need to move build.gradle file into project/Build Script folder and then run it.
I can setup teamcity trigger to run tests whenever there in VCS checkin/ change.
Then I setup command line build steps to access files on system .
e.g. `custom script'
cd ~/Desktop
ls
But is there way to trigger test run if there is change in file e.g. test.txt
I want to setup trigger as 'if file changes run tests'.
Or it has to be git checkin?
You would add a new "VCS Trigger" under your project configuration and you would add a new "Trigger rules" specifying the file/directory that should trigger the build. For example: +:root=ContecIT:ContecRepairSystem/** (here I am saying monitor the VCS root "ContecIT", and watch for any files changes under the "ContecRepairSystem" directory.
I'm not aware of any "FileSystemWatcher" feature in TC for triggering builds, unfortunately. Sounds like a good idea for a new TC plugin.
I've checked (here) if perhaps there's such a plugin already. Seems not. The "Url Build Trigger" comes closest. You could try to fork and adjust it to suit your needs.
I think your use case is quite rare. Usually a TC farm comprises many TC agents, each running on a different machine. Thus, they can't monitor the same filesystem (e.g. the Desktop directory), except perhaps some shared folders...
VCS trigger configuration would monitor for any git checkin and triggers the build process
We have the following project setup: Maven, Eclipse, Subversion. Eclipse Launch configurations are in a separate docs folder next to the pom.xml. The launch configurations run something like mvn clean install -Pdev or mvn tomee:run -pl something-ear
The good thing is that a shared run configuration is picked up by the IDE and shown in the External Tools run commands. This way, every developer that checks out this project immediately has access to run the build.
We would like to have something similar using IntelliJ IDEA, but I haven't found a good equivalent. What I have considered so far:
Share run scripts
My first idea was to replace the launch configurations with run scripts. I just could not figure out how to have those run scripts run inside IntelliJ IDEA just the way a Maven goal would be executed.
Share IDEA project configuration
The IDEA project configuration (specifically .idea/runConfigurations) inside the checked out directory is not a good solution. We have (speaking one IDEA project with different IDEA modules depending on the task at hand: as a developer you might need multiple IDEA modules (and sub-modules) in the same IDEA project
An IDEA project consisting of the following modules is not something unusal
projectA/trunk
projectB/tags/1.2
projectC/branches/some-change
My preferred solution would remove all IDE-specific configuration from the repository and have some kind of run definitions either in the project folder or a folder next to the pom.xml that a developer can run from the command line or from her IDE of choice.
The optimal solution would let me define something like this in the pom:
<runConfigs>
<default>clean install</default>
<container>tomee:run -pl something-ear</container>
</runConfigs>
This configuration would then be picked up by the IDE and provided as a run or launch configuration to the developer.
Any ideas or suggestions?
Thank you very much!
My current approach is a hybrid solution:
No configuration in the separate modules
One IDEA project configuration with run configurations managed in VCS
The .idea/runConfigurations directory is versioned separately from the project sources. It contains commands with a working directory set relative to the PROJECT_DIR:
<MavenRunnerParameters>
…
<option name="workingDirPath" value="$PROJECT_DIR$/path/to/submodule" />
</MavenRunnerParameters>
When setting up a new project, the developer also checks out this folder and has a set of pre-configured launch configurations for all projects. The downsides are
All launch configurations are managed centrally instead of with the module
The IDEA project directory has a fixed location relative to the modules. If you set up another project, you will have to change the run configurations
The setup does not clearly state how changes to the launch configurations are shared with other developers