List of available Jenkins Environment variables

Listed below is a complete set of Jenkins environment variables:

Variable	Description
BRANCH_NAME	For a multibranch project, this will be set to the name of the branch being built, for example in case you wish to deploy to production from master but not from feature branches; if corresponding to some kind of change request, the name is generally arbitrary (refer to CHANGE_ID and CHANGE_TARGET).
CHANGE_ID	For a multibranch project corresponding to some kind of change request, this will be set to the change ID, such as a pull request number, if supported; else unset
CHANGE_URL	For a multibranch project corresponding to some kind of change request, this will be set to the change URL, if supported; else unset
CHANGE_TITLE	For a multibranch project corresponding to some kind of change request, this will be set to the title of the change, if supported; else unset
CHANGE_AUTHOR	For a multibranch project corresponding to some kind of change request, this will be set to the username of the author of the proposed change, if supported; else unset
CHANGE_AUTHOR_DISPLAY_NAME	For a multibranch project corresponding to some kind of change request, this will be set to the human name of the author, if supported; else unset
CHANGE_AUTHOR_EMAIL	For a multibranch project corresponding to some kind of change request, this will be set to the email address of the author, if supported; else unset
CHANGE_TARGET	For a multibranch project corresponding to some kind of change request, this will be set to the target or base branch to which the change could be merged, if supported; else unset
BUILD_NUMBER	The current build number, such as “153”
BUILD_ID	The current build ID, identical to BUILD_NUMBER for builds created in 1.597+, but a YYYY-MM-DD_hh-mm-ss timestamp for older
BUILD_DISPLAY_NAME	The display name of the current build, which is something like “#153” by default
JOB_NAME	Name of the project of this build, such as “foo” or “foo/bar”
JOB_BASE_NAME	Short Name of the project of this build stripping off folder paths, such as “foo” for “bar/foo”
BUILD_TAG	String of “jenkins-${JOB_NAME}– ${BUILD_NUMBER}” All forward slashes (“/”) in the JOB_NAME are replaced with dashes (“-“). Convenient to put into a resource file, a jar file, etc for easier identification
EXECUTOR_NUMBER	The unique number that identifies the current executor (among executors of the same machine) that’s carrying out this build. This is the number you see in the “build executor status”, except that the number starts from 0, not 1
NODE_NAME	Name of the agent if the build is on an agent, or “master” if run on master
NODE_LABELS	Whitespace-separated list of labels that the node is assigned
WORKSPACE	The absolute path of the directory assigned to the build as a workspace
JENKINS_HOME	The absolute path of the directory assigned on the master node for Jenkins to store data
JENKINS_URL	Full URL of Jenkins, like http://server:port/jenkins/ (note: only available if Jenkins URL set in system configuration)
BUILD_URL	Full URL of this build, like http://server:port/jenkins/job/foo/15/ (Jenkins URL must be set)
JOB_URL	Full URL of this job, like http://server:port/jenkins/job/foo/ (Jenkins URL must be set)
GIT_COMMIT	The commit hash being checked out
GIT_PREVIOUS_COMMIT	The hash of the commit last built on this branch, if any.
GIT_PREVIOUS_SUCCESSFUL_COMMIT	The hash of the commit last successfully built on this branch, if any
GIT_BRANCH	The remote branch name, if any
GIT_LOCAL_BRANCH	The local branch name being checked out, if applicable
GIT_URL	The remote URL. If there are multiple, will be GIT_URL_1, GIT_URL_2, etc
GIT_COMMITTER_NAME	The configured Git committer name, if any
GIT_AUTHOR_NAME	The configured Git author name, if any
GIT_COMMITTER_EMAIL	The configured Git committer email, if any
GIT_AUTHOR_EMAIL	The configured Git author email, if any
SVN_REVISION	Subversion revision number that’s currently checked out to the workspace, such as “12345”
SVN_URL	Subversion URL that’s currently checked out to the workspace

 

Most important flows in Git

Save data in temporary memory and pull it whenever needed

1| Save data in temporary memory

git stash

2| Now pull changes from the master

git pull origin master --rebase

3| Finally pull back the value stored in temporary memory

git stash pop

Squash/Squeeze multiple commits as one

1| Check for the number of commits made in a single branch

git log

2| Mention the total number of commits to squash; say, 3

git rebase -i HEAD~3

3| Pick the top commit and squash following commits. How to do? Replace the text ‘pick’ with ‘s’ on following commit lines except the first one, and save “:wq”

4| Now, comment out all the commit names except the one you need to pick, and save “:wq”

5| Rebase the changes from master

git pull origin master --rebase

6| Fix the conflicts
7| Check for status

git status

8| If everything is perfect, then continue

git rebase --continue

9| And finally force push the commit

git push -f origin master

 

Standard Git flows to follow

Initial setup

1| Clone the target repo in local

git clone https://github.com/xyz/target_repo.git

2| Fork the target repo

3| Open terminal and rename the target repo alias, origin in local; say, upstream

git remote rename origin upstream

4| Add the previously forked remote repo in local

git remote add my-fork git@github.com:your-username/xyz.git

5| Now, rename the forked remote repo alias in local

git remote set-url my-fork git@github.com:your-username/xyz.git

6| Check remote versions

git remote -v

7| Observe both the upstream and forked alias in terminal

Rebase before every commit

1| Create a local branch, make changes to the codebase and check for the newly updated files

git status -s

2| Add all the required files for commit

git add --all

3| Create commit to the above-added files

git commit -m "your text"

4| And do git pull & rebase before pushing your changes to master. Cos, there might be additions in the original master that could cause possible conflicts with your newly modified scripts.

git pull upstream master --rebase

5| If found any conflicts, fix every conflicting file and check for status

git status -s

6| “Rebase continue” works only if all the conflicts are fixed locally

git rebase --continue

if not skip rebase

git rebase --skip

to abort rebasing,

git rebase --abort

7| Finally, force push the commit. You can even create multiple commits before push

git push -f my-fork users

8| The local changes are safely moved to your forked branch now. So, create a pull request to original master through GitHub interface. Happy Merging!!

Start with new branch

1| So far, we have seen how to ship local changes to upstream master through git rebase. And now, let’s have a plan to create separate branch locally to start with the new module. All we need is to fetch original/upstream master first,

git fetch upstream master

2| Create a local branch with the updated code from upstream master

git checkout -b new_branch_name upstream/master

3| Work on the newly created local branch and do rebase before every push

For details, Git Cheatsheet