Exposing global variables to jobs

[William Hargrove]

All,

I have a question on how to best expose global variables to jobs.

I have a set of global variables defined in my project configuration file eg.

project.globals.AUTH_TOKEN=mytoken
project.globals.AUTH_KEY=mykey

In order to use those in a inline script I have to do:

export AUTH_TOKEN=@globals.AUTH_TOKEN@
export AUTH_KEY=@globals.AUTH_KEY@

That approach works for a couple of global variables, but does not scale to a larger set.

I would also like to 'just have' global variables exported to all jobs rather than having to explicitly export them in each job which will lead to a lot of boiler plate code in each job script which I would like to avoid.

Is there a better way to manage this and make global variables available in a seamless way?

Thanks in advance for any suggestions. Will.

[rac...@rundeck.com]

Hi,

You don’t need to export to use them across your jobs,

1. Create the global variable in your “project.properties”, e.g: project.globals.AUTH_TOKEN=mytoken.
2. Call/use the variable across your jobs, e.g: echo ${globals.AUTH_TOKEN} (command steps) or echo @globals.AUTH_TOKEN@ (inline scripts).

Now, if you want to create “truly global variables” (across all projects), you can add them to the framework.properties file, take a look at this.

Greetings.

​

[William Hargrove]

Hi there,

Thanks for the feedback. I'll expand on what I want to achieve. I have an in-line script such as

1. source /app/my/python/venv/bin/activate
2. export AUTH_TOKEN=@globals.AUTH_TOKEN@
3  export AUTH_KEY=@globals.AUTH_KEY@
4. python3 /app/my/python/dosomething.pl

dosomething.pl is expecting to see an environment variable called AUTH_TOKEN and AUTH_KEY. I want to set those as a global (project) variable (project.globals.AUTH_TOKEN=mytoken) but I don't want to have to explicitly export AUTH_TOKEN=@globals.AUTH_TOKEN@ (et al.) for it to been exposed in each job. There might be 20 env variables in each job and it wouldn't be acceptable to copy/paste exporting the variable from its rundeck format for each new job.

So I was anticipating there would be a way to pre-expose the global variables as AUTH_TOKEN (ie in the format expected within a script) so all the existing dosomeingelse.pl scripts wouldn't need to be changed.

I hope this makes sense? Thanks.

--
You received this message because you are subscribed to a topic in the Google Groups "rundeck-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rundeck-discuss/SyCcu1Pv09I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rundeck-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rundeck-discuss/1a7f4dcf-f7bd-4155-8227-d19acbe9f058n%40googlegroups.com.

[rac...@rundeck.com]

I see,

A good way is to call your python script from the “Script file or URL” and call the globals directly using the RD_GLOBALS_MYGLOBAL format (similar to “external bash scripts” ), clicking on the “advanced” link you can set the full python 3 path, and .ps1 as the file extension.

I made an example:

1. I created the global variable in the “project.properties” config, e.g: project.globals.AUTH_TOKEN=mytoken.

2. I used this job:

- defaultTab: nodes
  description: ''
  executionEnabled: true
  id: 18982e00-7ab7-4d89-98bc-46404b96360b
  loglevel: INFO
  name: PythonEXAMPLE
  nodeFilterEditable: false
  plugins:
    ExecutionLifecycle: null
  scheduleEnabled: true
  sequence:
    commands:
    - exec: echo ${globals.AUTH_TOKEN}
    - fileExtension: .pl
      interpreterArgsQuoted: false
      scriptInterpreter: /usr/bin/python3
      scriptfile: /Users/user/Downloads/printenv.pl
    keepgoing: false
    strategy: node-first
  uuid: 18982e00-7ab7-4d89-98bc-46404b96360b

The job calls this printenv.pl python 3 script:

import os

print(os.environ['RD_GLOBALS_AUTH_TOKEN'])

In that way, you can avoid the “export” extra step.

Regards!

​