Differentiating deployment ENV in properties file using Jenkins - jenkins

So i have a Python script which does grant access (whitelist) users in websphere.
I have integrated this with Jenkins and a properties file in GIT that has list of users.
When I execute the jenkins job which runs on a slave machine as restricted in the setup.
What i now need to do is to differentiate the deployment env from non-prod and prod.

whitelists / passwords for prod Systems should not be stored as part of the repo but somewhere else on the target machine / prod System or even as a manual input to the target location if you do not deploy that frequently.
This being said, you can use conditional pipeline steps. The block after the when keyword will be executed only if the expression evaluates to true: Examples: env.TARGET_SYSTEM = 'prod' or GIT_BRANCH.startsWith("PROD")
You can have a block for non-prod systems where you copy the whitelist file to the apps target dir, and an other one for prod ones where you just check for the existence of the file (if it does not exist you can request a manual interaction and send out an email to copy the file here and there)
In case for you it is totally fine to have production data as part of the repo then simply use good old filename convention:
sh "cp whitelist.${params.TARGET_SYSTEM}.properties /my/target/dir"
where filenames are like: whitelist.non-prod.properties and whitelist.prod.properties . TARGET_SYSTEM is a parameter of the job

Related

VSTS secrets as environment variables

In the VSTS build, I set various variables (Edit build -> Variables tab), some I set as secret (click the lock), some I don't.
In the build, I run a command prompt task to run set -- e.g. show me all the environment variables. Those marked as secret aren't present.
How do I get VSTS secrets into environment variables?
Secret variables are:
Encrypted at rest with a 2048-bit RSA key.
Not returned back to the client. They are automatically masked out of
any log output from the build or release.
Not decrypted into environment variables. So scripts and programs run
by your build steps are not given access by default.
Decrypted for access by your build steps. So you can use them in
password arguments and also pass them explicitly into a script or a
program from your build step (for example as $(password)).
So, Secure variables need to be passed in to tasks as inputs. Check this case: How to add secret variable as task environment variable in VSTS

Jenkins build pipeline providing env vars for different environments

I have a public git repository that has a Jenkinsfile. The Jenkinsfile needs to be able to build three environments: dev, staging and production.
There's a set of variables that need to be set for each environment - some of these are sensitive and I wouldn't want to put them in the public repo. Some examples:
S3_BUCKET_URL
API_ENDPOINT
API_USERNAME
API_PASSWORD
etc.
In an ideal world I'd like a build parameter, e.g. BUILD_ENV that has the options: 'dev', 'staging' and 'prod' and some logic that sets the relevant vars dependent on env selection.
I've looked at the credentials pluglins, but they don't handle multiple envs and the UI seems awkward. Plus the env vars are accessible centrally, whereas we need them to be directly tied to the build job.
I've also looked at the env inject plugin, which works for setting properties, but there doesn't appear to be a way to make it vary those properties based on a chosen build parameter.
Is there a way to achieve this with the build pipeline? Surely there must be a plugin that already provides this capability?

Jenkins Multijob - pass project name parameter from Build_job1 to Deploy_job2

on a multi job I have two phases:
PhaseA running Build_job1, with a project name Build_job1, pulling stuff from git to dir: /var/lib/jenkins/workspace/Build_job1
PhaseB running Deploy_job2, that rsyncs /var/lib/jenkins/workspace/Build_job1/* to a bunch of servers.
For internal reasons I need to replicate the multijob, the build job and the deploy job to different environments (PROD, QA, Staging). I each case, the deploy job rsync will need to copy files from a different build directory (Build_QA, Build_Prod, Build_whatever etc.).
As Jenkins creates the dir per project name, I need the rsync command in the deploy job to get the project name as a parameter that is passed down from the build job.
help?
Are you wanting to pass down the current job's project name down to its children? If so, you can pass down this information via a Jenkins Set Environment Variables call "JOB_NAME" in conjunction with a predefined job parameter. For example, something like:
Param1=${JOB_NAME}
If the Multijob job name is "QA", you can pass that down to both the build and deploy phase jobs via a predefined parameter and then construct the final "Build_QA" path by doing something like "Build_${Param1}" or "Build_%Param1%".

Using parameterized credentials in Jenkins

Say I've got dev, qa, and stable server environments for some web app, with corresponding git branches. Each environment should be continuously integrated. Each of these environments has a separate username/password pair used to publish the app. I would like to make a Jenkins multiconfiguration (matrix) job to publish to all of these environments. The publishing almost certainly must be done with a shell script.
My failed attempt consisted of using the Jenkins Credentials and Credentials Binding plugins. Credentials Binding provides a way to inject credentials as environment variables using a parameter. However, setting this parameter dynamically (i.e., something like if ENV == dev: CREDS = CREDS_dev) doesn't appear to be possible. Build scripts happen afterwards, and even using the Environment Script plugin doesn't work.
Is there any way for this to happen?
Had similar situation and used groovy script with parameterized build (https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin). In my case I had a choice parameter defined as "DEPLOY" and had different values, like "Test", "Release", then in the following groovy script (Evaluated Groovy script):
if ("Test".equals(DEPLOY)) {def map = [DEPLOY_URL: "http://someurl", DEPLOY_STORAGE: "testaccount"]; return map }
You should be able to specify your credentials in here or copy env variables. After that you can access these variables in windows batch command using:
echo %DEPLOY_URL%
echo %DEPLOY_STORAGE%
I also had another choice parameter defined "Deploy.Branch", with values of "dev" and "master". And used it as a parameter to Branches to Build, the value was set to (if you want to dynamically specify branch based on parameters):
*/${Deploy.Branch}
Hope this helps.
Here's what I ended up doing. It's kind of a workaround for what I would argue is a flawed design or missing use case in Jenkins.
Redid my creds so they have standard IDs (this is in the Advanced part and you can't set it after creation)
Matrix job runs a trivial script to figure out what env maps to what creds ID, then triggers...
The main job that does the deployment

Jenkins Persistent Editable Global Variable

I'm looking for a plugin/approach that lets me set and read a persistent global variable for use between jobs.
The scenario is that I have CI job that runs tests on various branches of the codebase and I want to associate a build number that corresponds to the last stable build of the release branch. i.e.
Build No Branch Result GolbalSharedThingVal
5 release Success 1.5
6 dev Fail 1.5
7 dev Success 1.7
8 release Unstable 1.7
9 release Success 1.9
10 release Fail 1.9
Then in my deployment job I want to annotate the build with the version using a groovy post build action:
manager.addShortText(" ${manager.build.env.get('GolbalSharedThingVal')}")
Does anyone have any advice about what GolbalSharedThingVal could be?
Many Thanks,
Vackar
EnvInject plugin is the plugin for anything related to environment variables.
Don't know about setting a persistent global variable (that goes against the design principles of Jenkins), but you could have the job export a value to a properties file, and other jobs read the value from the properties file at initialization and expose it as environment variable to other build steps.
Of course the property file would have to be centrally located on Jenkins master somewhere
If you make sure that the different jobs/stages run on the same agent, you can use a file as a persistent storage. In a declarative pipeline this could look like
stage('myStage') {
steps {
echo 'in myStage'
sh '''
# get value from file into environment variable
export PERSISTENTVAR=`cat $HOME/persistent_var_file`
# do some stuff here to e.g. change $PERSISTENTVAR
# save env variable into file for later use
echo $PERSISTENTVAR > $HOME/persistent_var_file
'''
}
}

Resources