Jenkins allows you to parameterize builds, but I can't figure out how to actually make use of it:
Say I would normally kick my Ant build off from the command-line like so:
ant -buildfile /path/to/my/build.xml -DpackageType=jar package
This would invoke the build.xml's package target, and make a property named packageType available to it, with a value of jar.
I'm assuming that in the screenshot above, the Name field is where I would specify packageType, but what about the value?
If Jenkins wants me to specify a Default Value for the property, then where do I specify the value that my project is using? For instance, I might want a Default Value of war, but have this Jenkins job pass in a value of jar (to override the default).
Also, what does Jenkins mean by "...allows the user to save typing the actual value." Which user? Where would you type the value anyways?
Thanks in advance!
Whenever the user configures a parameterised build in Jenkins, the parameter name is taken as an environment variable
The user can make use of such parameters using the environment variable.
For example, in your case if packageType is the parameter you want to pass,
then specify the name as packageType and value as war
You can use it in the script you required as %packageType% (for Batch) or $packageType (for shell)
After configuring the job, whenever you click the build now button, Jenkins prompts for the parameter
When you are using file Parameter, the uploaded file will be placed into the working directory
Related
I am trying to pass env variables locally with strictly a command line command. At deploy, these variables get passed into the docker container, but when running locally, they are not present and need to be set locally.
They need to be removed before committing though because they are access keys so i dont want them exposed in the repo. That is why running tests locally (without an IDE) would require a command that passes these variables.
I have already tried this:
./gradlew clean build -Dspring.profiles.active=local -DMY_ENV_VAR1=xxxxxx -DMY_ENV_VAR2=xxxxxx
and it doesnt seem to be working. i cant find the docs for the build command's options, but i thought this was how you pass them. what am i doing wrong here? or is it not possible?
Another reason for environment variables not working is the gradle daemon.
Run this to kill any old daemons:
./gradlew --stop
Then try again. Lost far too much time on that.
For passing env variables
MY_ENV_VAR1=xxxxxx MY_ENV_VAR2=xxxxxx ./gradlew bootRun
For arguments/overriding properties values
./gradlew bootRun --args='--spring.profiles.active=local --db.url=something --anotherprop=fafdf'
For both passing env variable and overriding properties values.
MY_ENV_VAR1=xxxxxx MY_ENV_VAR2=xxxxxx ./gradlew bootRun --args='--spring.profiles.active=local --db.url=something --anotherprop=fafdf'
This related post worked for me: https://stackoverflow.com/a/57890208/1441210
The solution was to use the --args option of gradlew to get the environment variable to be passed to the spring boot app:
./gradlew bootRun --args='--spring.profiles.active=local'
I just put the env variable setting before calling command as the way a regular Unix shell does. Work with my Zsh.
MY_ENV_VAR1=xxxxxx MY_ENV_VAR2=xxxxxx gradlew clean test
If you want to pass values to the JVM that runs the gradle you can use the '-D' switch. I suppose you have to pass values to the gradle build file from the command line. If that's the case there are two options for that:
You can use the -P switch and specify the value there. For example:
gradle -PmySecretKey="This key is so secret" yourTask
If you are using linux or variants you can set environment variable as follows:
export ORG_GRADLE_PROJECT_mySecretKey="This key is so secret"
After this you can access the value in the gradle build file as follows (I am using kotlin dsl)
val mySecretKey: String by project
println(mySecretKey)
To answer your question, as far as I know, there's no way to set environment variables manually through Gradle. What your doing right now is just passing in regular CLI arguments/parameters to your tests.
when running locally, they are not present and need to be set locally.
running tests locally (without an IDE) would require a command that passes these variables.
I see from your snippet, you are using Spring, likely Spring Boot. And since you're already specifying the profile as local, why not define these variables in a profile specific configuration? Example:
application.yml -- base configuration
my-config-value: ${MY_ENV_VAR}
application-local.yml -- local profile configuration that overrides the base
my-config-value: some-dummy-value-for-local-development
I have this cucumber runner class:
#RunWith(Cucumber.class)
#CucumberOptions(plugin = {"pretty", "html:target/cucumber"},
features="classpath:features",
tags= {"#concrete"})
public class RunCuke {
}
This is the code available in git repository. While developing my own features, I want to use the same class but want to pass my own tags for it to run. But I don't want to modify this class (passing my own tag, say, #outline instead of #concrete), because this is a nuisance while committing code because each time I want to commit, I have to revert this file back to what is in the code repo (ie back to #concrete). Only way I think of is to pass the command line argument to this class.
So I am using this command line argument (program argument in the eclipse IDE):
-Dcucumber.options=”–tags #outline”
Unfortunately it is not working. It is not overriding what is there in #CucumberOptions.
How do I make it work?
You need to select 'Run Configurations' and go to the specific runner config. Go to the 'Environment' tab. Add a new variable 'cucumber.options' and set it to '--tag #outline'. You might need to switch the 'Append environment to native environment' and 'Replace native environment with specified environment', though I have found the default of 'append' works perfectly. Apply and Run.
In a Jenkins job I'm doing a couple of actions that reside in the pre-step build, such as executing a shell script.
With the use of the Jenkins plugin "EnvInject" I want to inject environment variables into my maven build (Unit tests) so that those can be used inside my Java unit tests.
Inside the shell script im doing something similar as:
echo "ip=$IP" >> unit-test.properties
While building Jenkins outputs the following:
[EnvInject] - Injecting environment variables from a build step.
[EnvInject] - Injecting as environment variables the properties file path 'unit-test.properties'
[EnvInject] - Variables injected successfully.
But the "ip" variable is not available inside my Java code (unit test). When I do a full print of both System.getProperties() and System.getenv() I do not see the "ip" enlisted.
Do I need to perform any special actions for maven to pass the variable to my Java code? Is something else wrong?
I'm pretty much stuck from this point onward, I do want to inject a key=value from a pre-step into my Java code.
My solution:
Create a "Build a free-style software project".
Jenkins > New Item > Build a free-style software project
Add 1st step: Execute shell # Build, and echo key=value pairs to a .properties file
Add 2nd step: Inject environment variables, use the .properties file as defined in step 2
Add 3rd step: Invoke top-level Maven targets
All custom environment variables are accessible with the key as defined in step #2.
This was the only way I found to inject environment variables from shell to java.
I had a similar requirement in my project, except my project was Maven. To use a variable value from jenkins to my java code, I used -DargLine="-DEnv=$Environment" inside "Build->Advanced->JVM Options". From my java code, I fetched the value of "Env" using System.getProperty(). FYI "Environment" is my Jenkins Variable, and "Env" is variable which is storing the value passed from jenkins into its variable(Environment) and fetched in java code using System.getProperty().
I am using junit's TemporaryFolder to test part of my application that deals with the filesystem. Is it possible to set the junit variable java.io.tmpdir to an Environment variable in the run configuration?
Based on our long-lasting discussion I now understand that you ask this:
How to configure JUnit so it uses a specific folder for creating the temporary files.
(If I get your question properly, please edit it accordingly and change the title.)
JUnit 4.11+
The easiest way is to use the new constructor TemporaryFolder(File parentFolder). This is the preferred way.
JUnit < 4.11
You are aware that the org.junit.rules.TemporaryFolder uses the the system property java.io.tmpdir. Actually, when you look at the source code, it uses internally the File.createTempFile(prefix, suffix) method which uses this system property.
You will find exhaustive information here: Environment variable to control java.io.tmpdir?.
More generally about system properties and environment variables: Java system properties and environment variables
However, you should notice this sentence from the Java-doc:
A different value may be given to this system property when the Java
virtual machine is invoked, but programmatic changes to this property
are not guaranteed to have any effect upon the temporary directory
used by this method.
If you want to be sure you have the temporary folder always under your control, you may create your own version of org.junit.rules.TemporaryFolder - it's not so difficult, you just use the File.createTempFile(prefix, suffix, directory) with explicitly assigned the 3rd parameter directory.
I'm using Teamcity to build with an Ant runner.
I'm trying to pass the current build counter into the "Additional Ant command line parameters" using the following
-lib %teamcity.build.checkoutDir%/MI/CustomAntTasks/jars/CustomAntTasks.jar -Dlabel={0}
The value -Dlabel={0} is being passed into the Ant script as the literal value {0} and not the current value of the build counter.
Any ideas on how I can correctly pass through the build counter (not the build number)?
I believe that it is accessible via the build-in parameter, i.e. you don't need to try to pass it in.
${build.number}
There are other values too: Predefined Build Parameters