Pass environment variables to child process kicked off by rsyslog omprog module - rsyslog

I have defined a program to handle logs via the omprog module in the rsyslog file as follows:
module(load="omprog")
if $programname == 'myprogram' and getenv('ENV_FOO') == 'foo_value' then {
action(type="omprog" binary="/pathto/my_log_handler.py")
}
I have verified that rsyslog inherits the environment variable ENV_FOO and kicks off the binary but the child process running my_log_handler.py does not seem to inherit the environment variables. I have tested that including the following snippet in my_log_handler.py correctly prints 'foo_value' when run from the shell but prints nothing when triggered by rsyslog's omprog module.
print(os.environ['ENV_FOO'])
Is there a way to have the binary triggered by rsyslog's omprog module inherit the environment variables of rsyslog?

This was added in rsyslog v8.38 (i.e., from that version on, the environment is passed to the child process).

Related

Use of variables (bash script) in the mail body in jenkins

I currently have the following script:
var = foo
And the configuration of the email (Editable Email Publisher) I have it like this:
configuration Email Publisher
Reading in other questions, someone said that it worked for him using this:
${ENV, var="var"}
However, it does not work for me, can you help me please?
When you run a script that add environment variable the lifetime of this variable is only until the script ends.
You have plugin Environment Injector (was EnvInject Plugin) that using this plugin you can inject variable to all the job life time.
So if you want to add variable in the build section and to use it in the post build section you need to inject the variable.

Can Jenkins pipeline use variables in agent stage?

Problem
I'm using Jenkins pipeline and testing python with tox.
This combination explodes when tox creates a python virtualenv with a pip
whose shebang line exceeds the hard coded system imposed maximum of 127 characters.
To set a shorter workspace location,I want to add:
agent {
node {
label 'debian-slave'
customWorkspace "workspace/${env.GIT_BRANCH}"
}
}
but env.GIT_BRANCH is not yet defined. environment has not yet been calculated when the agent block runs.
How can I add the branch number or something similar to the workdir definition?
I don't want to lose the per-branch unique workspaces.
What Jenkins variables exist at the "agent" stage?

Is there a standard/prefered method for debug logging in a custom Ansible module.

I would like to add debug logging to my custom Ansible module such that when the -vvv option is supplied to the ansible-playbook command I see the log messages but otherwise do not. I don't want the results of the module to be affected by this logging. In other words, I don't want to write the log messages to stdout or stderr directly.
Modules normally are executed remotely, so there actually is no way to directly output anything.
You can return additional data in your module in the exit_json call.
if module._verbosity >= 3:
module.exit_json(changed=True, debug="wooha!")
else:
module.exit_json(changed=True)
module._verbosity corresponds to the verbosity level (-v = 1, -vvv = 3) and is available since Ansible 2.1.
Source: Ansible Devel-list and github
Ansible module are hard to debug because:
modules are normally executed remotely
modules are executed by python subprocess (so we can not use pdb to debug)
So, you can debug the Ansible module in this way:
Make the module execute locally. This can be implemented either by setting the hosts to localhost or by using Ansible local_action module.
Write/Logging the variables you want to debug into a specific file. You can do this by using Python q library.

TeamCity - how to access environment variable in gradle

I have specified environment variable named DIR in my build agent. It is visible in my parameters/environment variables section of my Build Agent properties. I want to access this variable from gradle. I don't know how. I tried many things like:
if (project.hasProperty("teamcity")) {
println teamcity
println teamcity["teamcity.build.properties.file"]
def properties = file(teamcity["teamcity.build.properties.file"])
println properties.DIR
println DIR
println env.DIR
}
My teamcity file looks like:
{teamcity.buildType.id=Taxi5Mobile_BuildDev, build.vcs.number.Taxi5Mobile_Taxi5devVCS=a23e58c8ff92, teamcity.version=8.1.1 (build 29939), teamcity.buildConfName=Build-dev, teamcity.agent.dotnet.agent_url=http://localhost:9090/RPC2, teamcity.build.id=111, agent.ownPort=9090, agent.name=MacAgent, build.number=82, teamcity.runner.properties.file=/Users/surecase/Desktop/buildAgent/temp/buildTmp/teamcity.runner3909938768619827374.properties, teamcity.build.changedFiles.file=/Users/surecase/Desktop/buildAgent/temp/buildTmp/changedFiles8064633368222257261.txt, teamcity.agent.cpuBenchmark=552, teamcity.build.workingDir=/Users/surecase/Desktop/buildAgent/work/88410410f80bbc04/Mobile/Android, agent.home.dir=/Users/surecase/Desktop/buildAgent, teamcity.auth.userId=TeamCityBuildId=111, teamcity.build.checkoutDir=/Users/surecase/Desktop/buildAgent/work/88410410f80bbc04, teamcity.configuration.properties.file=/Users/surecase/Desktop/buildAgent/temp/buildTmp/teamcity.config8874044708331653991.properties, build.vcs.number=a23e58c8ff92, teamcity.tests.recentlyFailedTests.file=/Users/surecase/Desktop/buildAgent/temp/buildTmp/testsToRunFirst6286498944890258669.txt, teamcity.projectName=Taxi5Mobile, agent.work.dir=/Users/surecase/Desktop/buildAgent/work, teamcity.build.tempDir=/Users/surecase/Desktop/buildAgent/temp/buildTmp, build.vcs.number.1=a23e58c8ff92, teamcity.auth.password=8dYVHDftOmXenz9cJjnCyctBrF5NKq7G, java.io.tmpdir=/Users/surecase/Desktop/buildAgent/temp/buildTmp, teamcity.build.properties.file=/Users/surecase/Desktop/buildAgent/temp/buildTmp/teamcity.build174113942945941853.properties, teamcity.agent.dotnet.build_id=111}
There are some files which contains properties but I don't know how to access them.
Any ideas?
Environment variables can be read using the standard Java API:
def dir = System.getenv("DIR")
It might make sense to use a name that's a little less ambiguous than DIR.

Access to build environment variables from a groovy script in a Jenkins build step (Windows)

I'm using Scriptler plugin, so I can run a groovy script as a build step. My Jenkins slaves are running on windows in service mode. With scriptler, I don't need to use windows batch scripts.
But I have trouble to get the environment variables in a build step... This is working:
System.getenv("BASE")
Where BASE is part of the env-vars on jenkins startup. However, I would like to get
%JOB_NAME%
If I'm adding an "Execute Windows batch command" build step:
echo %JOB_NAME%
It works.
If I'm adding a scriptler script as a build step with the same settings:
println "JOB_NAME: " + System.getenv("JOB_NAME")
I'm getting:
JOB_NAME: null
So how can I reach the injected environment variables from a groovy script as a build step?
build and listener objects are presenting during system groovy execution. You can do this:
def myVar = build.getEnvironment(listener).get('myVar')
You might be able to get them like this:
def thr = Thread.currentThread()
def build = thr?.executable
def envVarsMap = build.parent.builds[0].properties.get("envVars")
On jenkins 2.x, with groovy plugin 2.0, running SystemGroovyScript I managed to get to build variables, as below:
def build = this.getProperty('binding').getVariable('build')
def listener = this.getProperty('binding').getVariable('listener')
def env = build.getEnvironment(listener)
println env.MY_VARIABLE
If you are using goovy from file, simple System.getenv('MY_VARIABLE') is sufficient
The Scriptler Groovy script doesn't seem to get all the environment variables of the build. But what you can do is force them in as parameters to the script:
When you add the Scriptler build step into your job, select the option "Define script parameters"
Add a parameter for each environment variable you want to pass in. For example "Name: JOB_NAME", "Value: $JOB_NAME". The value will get expanded from the Jenkins build environment using '$envName' type variables, most fields in the job configuration settings support this sort of expansion from my experience.
In your script, you should have a variable with the same name as the parameter, so you can access the parameters with something like:
println "JOB_NAME = $JOB_NAME"
I haven't used Sciptler myself apart from some experimentation, but your question posed an interesting problem. I hope this helps!
The only way I could get this to work (on Linux) was to follow this advice:
https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+System+Groovy+script
import hudson.model.*
// get current thread / Executor and current build
def thr = Thread.currentThread()
def build = thr?.executable
// if you want the parameter by name ...
def hardcoded_param = "FOOBAR"
def resolver = build.buildVariableResolver
def hardcoded_param_value = resolver.resolve(hardcoded_param)
println "param ${hardcoded_param} value : ${hardcoded_param_value}"
This is on Jenkins 1.624 running on CentOS 6.7
Jenkins 2.x has the global variables. env is one of them from any script...
println env.JOB_NAME
More at https://build.intuit.com/services-config/pipeline-syntax/globals#env
One thing to note, if you are using a freestyle job, you won't be able to access build parameters or the Jenkins JVM's environment UNLESS you are using System Groovy Script build steps. I spent hours googling and researching before gathering enough clues to figure that out.
In System Groovy Script (Jenkins 2.89), I was able to use the environmental variable to disable another Jenkins job
import jenkins.*
import jenkins.model.*
def env = binding.build.environment
Jenkins.instance.getItemByFullName(env.job_name).setDisabled(false)
I also added a conditional step so as to either enable or disable another Jenkins job.
Thanks #Allan Lewis, your comment was helpful.

Resources