I'm trying to create a new workflow file where I create an environment variable and use that variable in the value of some other environment variables, but it's not recognising it.
on:
workflow_dispatch:
env:
dev_environment: "my-environment"
working_dir_classic: "repo/${{ env.dev_environment }}/services/classic-service/"
working_dir_cron: "repo/${{ env.dev_environment }}/services/my-cron-service/"
Can anyone help?
Above is what I have currently, but I'm unsure what needs fixing.
I want have two different sets of API keys for development and production and I want to use them automatically depending on whether the app is run locally or on heroku.
For nodejs apps, I do the following:
if (process.env.NODE_ENV === 'production') {
// ./prod contains the production keys
module.exports = require('./prod');
} else {
// ./dev contains the development keys
module.exports = require('./dev');
}
How to do something similar in a Clojure Leiningen app? What would the process.env.NODE_ENV analogue be, and how to implement it?
Clojure runs on JVM, so you could use java System class. Assuming you have set APP_ENVIRONMENT variable in bash.
(if (= "production"
(or (System/getenv "APP_ENVIRONMENT")
"development"))
(start/production)
(start/development))
I would say the cleanest solution would be to use the environ library together with the lein-environ plugin.
With these you store development version of API keys in env vars in the leiningen dev profile and on production pass them as actual environment variables. E.g. you can have the following in your project.clj:
(defproject ...
...
:profiles {:dev {:env {:my-api-key "whatever-dev" } } }
...)
On the production environment you could simply set an environment variable MY_API_KEY to "whatever-prod".
In your code you will access the key like this:
(require '[environ.core :refer [env]])
(env :my-api-key) ;; would yield "whatever-dev" on dev and "whatever-prod" on prod environment
In particular, this allows you not to store the production keys under source control.
environ provides a couple more options - in particular with env files, which may also fit your needs. Do check its capabilities.
If you also need access to environment variables in your CLJS (on frontend), you can't simply access environment variables there indeed (because there's no such thing as environment anymore - the code runs on the client).
Still, if you just wish to drop the values into the resulting js during compilation, you can use environ + a macro for that. You will write a macro in a clj file that just returns the env var and then refer it in your cljs file. During compilation the appropriate value will be injected.
In a clj file:
(ns yourns.environment
(:require [environ.core :refer [env]]))
(defmacro my-api-key []
(env :my-api-key))
In cljs:
(ns yourns.core
(:require-macros [yourns.environment :refer [my-api-key]))
(my-api-key) ;; will return the appropriate value
Note, however, again that the variable value will be injected in compile time and can't be changed later.
Please see here for a complete code example.
I am doing some automatic testing on Circleci, with different enviromental variables: I need one port for my local testing and a different one for Circleci.
How can I make Cypress do that? I tried making cypress.env.circle, but that does not seem to work
The cypress docs explain 5 ways to set variables.
To use one port locally and one on CircleCI I would:
Add a default port to cypress.json under the env section for local use so you don't have to think about it, and anyone else contributing will have a working version.
Set an environment variable in CircleCI named cypress_VAR_NAME which will override default in cypress.json
cypress.json example
{
"env": {
"the_port": 5000
}
}
CircleCI variable would then be cypress_the_port and you would read it in your specs as parseInt(Cypress.env('the_port')) (assuming your spec needs an integer for port)
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.
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.