We are in the process of setting up a Jenkins CI server to handle all of our WebDriver tests. Ideally, I would like to have choice build parameters for our QA team to select the server to test (production, etc.) for each build. We have a properties file in place to handle this, so we only need to make changes to that file. Are there any plugins out there that can do what we are looking for?
You could just use a shell build step
echo $MY_BUILD_VAR > $WORKSPACE/somefile
sometimes a plugin is more than you need! (though EnvInject would help if you have a mixture of OSes to support (i.e. *nix and windows) as Windows runs batch files and *nix goes with shell... though the windows version is trivially different
echo %MY_BUILD_VAR% > %WORKSPACE%\somefile
Yes, EnvInject Plugin can read environment from a property file and make it available to the build.
Related
I recently created an automated process to run multi-step Maven builds for my organization. They now are looking to have the entire process automated using Jenkins. I have been able to successfully create branches, builds, change versions, etc., using Maven commands but I am having difficulty committing the version changes (1.0.1-Snapshot to 1.0.1-E1 for example) with Jenkins. I have tried using basic commands like:
SVN commit "Comments"
However, Jenkins does not seem to know what to do with these command lines in the "Execute Windows Batch File" Post Build option. I simply receive build failures caused by the batch file for "unknown reasons." I see the help desk I am working with has installed the Subversion plugin, but perhaps something else is missing. I know that when I use the command prompt locally I need to use something like this:
"C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe"
/command:commit /path: /url:
However, Jenkins is hosted by a third party and I do not have direct access to the servers so I would not be able to implement that kind of path data. So I am now looking to see if I can run this, somehow, purely through Jenkins as my client requests.
Anyone have any success with SVN Commit to update version changes through Jenkins?
Thanks!
-Cameron
Why did you decide to run TortoiseProc via Jenkins? TortoiseProc is not the right tool for this task, use svn.exe client.
TortoiseProc can be used for TortoiseSVN's GUI automation, but this case is completely different to running Jenkins.
I have a Jenkins job that uses a script to build my project. On the following line, the script fails mvn -e -X -Dgit='$git' release:prepare.
Because I want to search for the cause of this, I want to go to the Jenkins server and run mvn -e -X -Dgit='$git' release:prepare from the command line, to see if it works.
Does Jenkins store the projects' source code somewhere, such that I can go to that folder and call Maven?
If yes, then where?
Yes, It Stores the project files for the job by default at
/var/lib/jenkins/workspace/{your-job-name}
This is where jenkins suppose the project files to be present or it pulls it from a source before start working/building from it.
Quote from Andrew M.:
"Hudson/Jenkins doesn't quite work that way. It stores configurations and job information in /var/lib/jenkins by default (if you're using the .deb package). If you want to setup persistence for a specific application, that's something you'll want to handle yourself - Hudson is a continuous integration server, not a test framework.
Check out the Wiki article on Continuous Integration for an overview of what to expect."
From this Question on serverfault.
This worked for me:
/var/jenkins/workspace/JobNameExample
but, if your build machine (node) is a different than the one where Jenkins is running (manager), You need specify it:
/var/jenkins/workspace/JobNameExample/label/NodeName
Where you can define label too:
jenkins stores its workspace files currently in /var/jenkins_home/workspace/project_name
I am running from docker though!
Along the lines of this answer (which works for me, BTW) and the javadocs, I tried
gradle.startParameter.consoleOutput = org.gradle.api.logging.configuration.ConsoleOutput.Rich
in my ~/.gradle/init.gradle. However, I still need --console=rich to get color output. Why?
Tested with Gradle 2.14.1 and 3.2.1.
Terminal is cygwin urxvt with TERM variable set to rxvt-unicode-256color.
Since Gradle 4.3 you can use org.gradle.console property in gradle.properties:
org.gradle.console=rich
A new console verbose mode will print outcomes of all tasks (like UP-TO-DATE) like Gradle 3.5 and earlier did. You can set this via --console=verbose or by a new Gradle property org.gradle.console=(plain rich verbose).
I am not sure if you can force the rich console from a gradle script, as the detection happens likely before the script is interpreted.
NativeServices class provides the integration with the console. If you look at the source code, there are two messages possibly printed in log:
Native-platform terminal integration is not available. Continuing with fallback.
Unable to load from native-platform backed ConsoleDetector. Continuing with fallback.
The latter might give you more information why. Try running the gradle script with --debug. You will likely find out that you are missing a native library that is either not available in cygwin or it is, but is not on library path.
I believe it works when you specify the rich console from the command line, because gradle forces the colours even though the console doesn't indicate it supports them.
Does it work if you don't use the cygwin console in Windows native command line or maybe GitBash?
There is a workaround how you can make this work. You can create an alias in cygwin that will always add the --console=rich.
If you are using gradle wrapper, you can edit the gradlew script and add the command line parameter. To make it automated, you can change the wrapper task to alter your script in the doLast part.
Create a file called gradle.properties inside your ~/.gradle/ folder.
Inside gradle.properties, add the line org.gradle.console=rich.
Each builds will run under --console=rich automatically because the new gradle.properties will be merged with the gradle.properties of your project.
If your project's gradle.properties contains the same tag as the local file, your project's will be used overriding the local file's
If you are on Linux/Mac set
alias gradle='gradle --console rich'
in your ~/.bashrc.
In Gradle Wrapper, add the following line:
org.gradle.console=rich
to ./gradle.properties in the root folder, where the gradlew script is located.
I have a shell script that runs lcov (test coverage) on an iOS project that I have Hudson. Hudson's copy of this project is derived from a Git repository. The way that I have set up now is that whenever the repo is updated or if someone manually builds the project in Hudson, Hudson would automatically run the app, and then run my shell script after the build is done. lcov can only be run after the app is not only built, but automatically run with some functional test tools. So, I cannot run the shell script as part of the build process, through XCode. It must be run after the app finishes building and running.
However, I would like to use this project in multiple Hudson jobs. Unfortunately, in each Hudson job, the iOS project is named differently. I would like to refer to the build path with some sort of environmental variable, but I don't know how to. Does anyone have any tips as to how to find that?
If I understand you correctly this is really a Hudson question. You can set "global variables" in your Hudson config and then invoke shell scripts, batch files, ant builds etc. You can also set them dynamically on each invocation of your Hudson job. Not sure exactly how to help you in your specific environment without more info.
I'd like to write some Subversion (SVN) hook scripts in Groovy. The SVN server will be running on windows, and according to the SVN book:
you would need to supply a program whose basename is the name of the hook and whose extension is one of the special extensions recognized by Windows for executable programs, such as .exe for programs and .bat for batch files.
Apart from installing Groovy on the local machine, setting the GROOVY HOME env var, and adding %GROOVY_HOME%\bin to the PATH, what else do I need to do before SVN can execute Groovy hook scripts?
Thanks,
Don
You should make sure your groovy scripts are associated to grooovy with the correct parameters, in order for Windows to execute them with their options when double-clicking them.
Notice you must set that association in a way that allow groovy script to be run with parameters.
Anyway, seems like a good page on that very subject could help : Debugging Subversion Repository Hooks in Windows
If you're not doing it as Riduidel recommends, you have to create a batch file calling groovy, for a precommit hook, it would be called pre-commit.bat and will be called with the parameters
[1] REPOS-PATH (the path to this repository)
[2] TXN-NAME (the name of the txn about to be committed)
These have to be passed to your groovy script...