It appears that Jenkins is using the environment variable $JENKINS_HOME for 2 different purposes, and for each purpose it will get a different value.
Purpose#1: First, there is the JENKINS_HOME that is a directory on the local file system that stores files that Jenkins creates. Jenkins uses this directory for disk space to perform builds and keep archive. So a sample value might be:
export JENKINS_HOME=/var/jenkins
That purpose is described here:
https://wiki.jenkins-ci.org/display/JENKINS/Tomcat
https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins
Purpose#2:
There is another instance where Jenkins used the JENKINS_HOME environment variable, and that is for monitoring external jobs. But this time JENKINS_HOME is a URL, like such:
export JENKINS_HOME=http://user:pw#myserver.acme.org/path/to/jenkins/
That purpose is described here:
https://wiki.jenkins-ci.org/display/JENKINS/Monitoring+external+jobs
So it seems odd that Jenkins would use the same environment variable, yet its value will change depending on the purpose. I would think that the external job would use another name for the environment variable, like JENKINS_URL. I suppose as a workaround I can just set the environment variable in the Servlet container (Tomcat for me) instead of on the operating system, so there is no conflict. Still though, the fact that this conflict for the variable exists in the first place seems strange. Is there something I'm missing?
That is pretty confusing, but the second purpose is for monitoring Jenkins jobs in an external process, not within Jenkins itself; so it's not Jenkins that is using the $JENKINS_HOME value in this case and there is no conflict. They could have picked a better name for the variable, though.
In most other cases, the Jenkins master URL is referred to as JENKINS_URL - see the Jenkins CLI documentation for example.
Related
I'm wondering if it's possible to feed arguments, or environment variables into a Dockerfile used by AppEngine (flex environment).
I'd like to use this command:
COPY ${STAGE}/keycloak-files/realm-config/* /opt/jboss/keycloak/realm-config/
"STAGE" variable would allow to select the origin (I have a "staging" and "production" directory, containing different configurations).
I've got two different app.yml files, one for each environment, but from what I read online, environment variables are not exposed to the Dockerfile at build time.
People suggest to pass arguments to accomplish the task. But how would that be possible with appengine, where we don't execute the docker build command directly?
As #DamPlz said there is not a straight way to pass env variables from the app.yaml to the Dockerfile during the deployment phase . Here are some workarounds that I could think of:
One option could be to create the variable in the Dockerfile directly and if you want to change it each time at runtime you can use a placeholder value and have a script update the value of the variable before running “gcloud app deploy”.
On the other hand you could use build triggers in Google Cloud Registry to modify it in the Docker image using user-defined substitutions.
I tried to find meaning of CI inside Github Actions documentation, but I can not find detailed explanation.
Except this
CI Always set to true.
it's the environment variable defined by convention in many CI servers like github action, Gitlab, Travis etc. Its value is always set to true when builds run in those servers.
Many tools check whether that variable is set to true and adjust their configuration and output to be suitable for CI environment. E.g. some tools are interactive by default, but if CI=true, it will skip user prompt and use default values/passed in arguments. Another example is pipenv that has special configuration when CI=true: https://github.com/pypa/pipenv/blob/207f2f565d2c4493bd8cdfb55a9b565aa58984fc/pipenv/environments.py#L27
i have a script that should run on both linux and windows agents.
this script reads a config file sitting on a network drive.
it gets worse - we have 2 different jenkins masters - one on docker ubuntu, and one on master. they run different jobs but with the same script.
so now -
using script.readFile is out of the question because the file is outside of workspace.
using groovy File(path).text is also problematic because the path (the mounts) is different on windows/linux (the jenkins masters).
There is a shared env var across all machines to get the right mount. when using groovy File, this doesn't work "${SOME_ENV_VAR}/file" it doesn't translate the env var
is there a way to use jenkins pipeline to read a file outside workspace? this would be the best solution.
or some other solution you can think of?
Thanks
using script.readFile is out of the question because the file is outside of workspace.
Not really. Assuming you are referring to the Jenkins step readFile you still can use it. It just takes a whole lot of dots
def config = readFile "../../../../mnt/config/my_config.txt
You'd have to figure out the exact amount of dots yourself
We have a Code Composer Studio (Eclipse) project that uses CMAKE to generate makefiles and build. The project compiles as expected when the project is manually imported onto the Jenkins slave (Win10 x64) and executed from the command line but fails when the build is handled by Jenkins. The failure always follows the same pattern: a singular letter is dropped from the path of an object file. For example, [Repo directory]/Cockpit_Scaling_and_Exceedance_data.dir becomes [Repo direcory]/Cockpit_Scaling_and_Exceedance_ata.dir and linking fails because it cannot find the referenced object file.
I made sure that there are no differences between the account environment variables and the system environment variables and have also configured the Jenkins Service to use the admin account on the slave instead of SYSTEM in order to get rid of as many differences between Jenkins and the command line as possible.
The project will build successfully using one of our other Jenkins slaves (also Win10 x64), so we know that it's not a Windows 10 issue or a problem with our Jenkins configuration. Since I can't find any differences between the configuration of the two slave machines, I was hoping that someone might be able to suggest somewhere to look for this path issue.
I never found out why the paths to object files were being mangled, but I did get the project to build successfully on the slave via Jenkins. All I did was change all of my system environment variables into user environment variables. I copy-pasted, so I know that the variables themselves did not change.
I have no idea why this corrected this issue as I had inserted a whoami call at the beginning of the build to confirm that Jenkins is indeed running as a user and not System. I guess from this point on all of my environment variables will be specific to a user and not SYSTEM...
EDIT: The problem has returned. I have made no further progress in tracking down the cause behind this issue, but I have found that I do not see this symptom when running the scripts in a bash environment instead of a Windows command prompt. Fortunately for me the scripts have all been written in such a way that they can be run in both environments, so I have had my coworkers use bash instead for them.
I'm using Jenkins and deploy plugin, with which I'm deploying to tomcat server. How can I pass parameters from properties file to this deploy plugin?
for example I want to pass my property app.server.url to Tomcat URL field.
I tried to pass $app.server.url also %app.server.url%, but that doesn't work.
I am assuming you have a properties file in the format app.server.url=somevalue
You then can inject these properties into the Jenkins environment using EnvInjec Plugin. Use Inject environment variables for your job build step, and just specify your file path (leave the content field blank). After that, you can reference it like this $app.server.url for *nix, or %app.server.url% for Windows. However this only works on the shell level. On the plugin properties level, a lot of plugins are expecting properties only in *nix-style format.
The further problem is that *nix-style variables do not allow dots .. So $app.server.url is not valid on *nix. I do not know if it will work on plugin-level on Windows though.
So after setting up EnvInject plugin, try the following two:
Try using $app.server.url in your deploy plugin.
Else change the property file to something like app_server_url=somevalue, and then try $app_server_url in deploy plugin.