I want that my jenkins job will use env variables from a properties file. is that possible, and how?
Thanks, Ohad.
EDIT: I want environment variables to be resolved when checkout from svn, so that few projects will have the same revision. I am trying to use a solution suggested here.
There are a couple of plugins used for this type of thing. You might want to take a look at the following two. I have feeling the one your looking for is the second one.
Setenv
Envfile
If you want to get all manual about it you can also do this.
Manage Jenkins -> Configure System -> Global Options -> Environment variables
Goodluck!
Related
I am currently trying to get my Jenkins (version 2.35) Jobs for AEM (6.2) author/publishers up and running. In this setup I have Dev, Staging and Production environments. To avoid version controlling my credentials in my pom.xml I have made the use of environment variables in maven (version 3.3.9).
<properties>
<aem.host>localhost:4502</aem.host>
<aem.protocol>http</aem.protocol>
<aem.user>${env.AEM_AUTHOR_USER}</aem.user>
<aem.password>${env.AEM_AUTHOR_PASSWORD}</aem.password>
</properties>
On my local environment I have tested setting those environment variables to the correct and then incorrect values and it behaves as one would think it would.
The thing here is that when I build the Dev Author job on my Jenkins server, it seems to succeed whether the environment variables are set to the correct values or not. It is so weird and at this point I have no clue to what is going on. I am setting the environment variables on the Jenkins server via a simple.
source ~/path/to/file
Where ~/path/to/file would look something like the following:
AEM_AUTHOR_USER="admin"
AEM_AUTHOR_PASSWORD="admin"
Also I should mention that previously to using environment variables in maven I had the AEM credentials directly in the pom.xml just for Dev jobs.
I'm wondering if Jenkins has cached the maven properties thus the credentials and re-setting the environment variables has no effect. I should also mention I have tried re-creating the workspace on each new build to see if it would clear some caching system but no dice.
Is Jenkins or Maven caching my maven properties somewhere that my environment variables are being ignored ?
Has anyone ran into the issue I am describing ?
Should I be using the EnvInject Plugin Jenkins plugin ?
Any help is welcomed.
Thanks,
Nicola
In the case of my Develop Jobs it seems that Jenkins uses some sort of caching system that I wasn't able to clear. Even after deleting the workspace or deleting the cache folder in
/home/jenkins/.jenkins/cache
Anyways after trying a lot of things to attempt regaining control over the value of the AEM credentials set in my pom.xml I figured out how to control the values of the pom.xml environment variables which solved my problems. The way I did that was to install the EnvInject Plugin after which I was able to configure my maven environment variables individually on all my jobs. Everything works great now.
I'm trying to execute a Gradle command-line task -setupDecompWorkspace to set up Minecraft Forge, but the task gets stuck on decompileMC. I've tried the first solution from this issue, but it didn't work. The second solution suggest setting the GRADLE_OPTS environment variable to -Xmx2G. I don't exactly know how to do this. After searching online for a couple of hours I am still found with no answer. Even the official Gradle documentation doesn't help. Do I need to declare the variable in the gradle.properties file, enter it as a command-line argument or something completely different?
-Xmx2G is a JVM command line parameter, if you want to set it as a Gradle property just add it to the gradle.properties file in your project root:
org.gradle.jvmargs=-Xmx2G
You can also find some more useful information here: https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_configuration_properties
I'm using Gitlab CI to deploy TYPO3 projects onto a target server and I'm trying to remove the PackageStates.php from the git repository and generate it on the target server with EXT:typo3_console instead.
But I need to set the TYPO3_ACTIVE_FRAMEWORK_EXTENSIONS environment variable in order to have the necessary system extensions loaded.
How do I set this ENV variable?
What's a good way to store these information in my project to have it available in the deployment process? I could use Gitlab variables but I feel like this information should be included in the git repository.
You don't need to set and use the env variable if you don't want to. You can just require the TYPO3 core extensions you need in any package of your project and typo3_console will take care to populate the environment variable for you as needed during composer install time.
If you want to, you can however still override this env var from command line for individual calls.
EDIT: This feature has been integrated in typo3_console 3.3.0
I know I can't set environment variable directly from Gradle, but is there some other solution?. I need to do this:
do some stuff..
set 4 environment variables (their values depend on some settings)
run some ant scripts (that depend on environment variables)
I thought of creating a file (.setenvironment) with all the settings I need, and then source it from Gradle (source .setenvironment), but I fear that I wouldn't be able to reset the variables if something goes wrong (and I need to set "JAVA_HOME", for instance, which is also important for the build scripts themself).
You can't set environment variables from java and other JVM languages. The only way of doing it is via ProcessBuilder.
You can also set the variables before gradle is run.
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.