Jenkins Remote access API Example | Jenkins Tutorial

Jenkins Remote access API Example
Jenkins provides machine-consumable remote access API to its functionalities. Currently it comes in three flavors:
JSON with JSONP support
Remote access API is offered in a REST-like style. That is, there is no single entry point for all features, and instead they are available under the “…/api/” URL where “…” portion is the data that it acts on.
For example, if your Jenkins installation sits at, visiting will show just the top-level API features available – primarily a listing of the configured jobs for this Jenkins instance.
Or if you want to access information about a particular build, e.g., then go to and you’ll see the list of functionalities for that build.
Remote API can be used to do things like these:
Retrieve information from Jenkins for programmatic consumption.
trigger a new build
create/copy jobs
Jobs with parameters, Also see Parameterized Build.
Simple example – sending “String Parameters”:
curl -X POST JENKINS_URL/job/JOB_NAME/build \
  –data token=TOKEN \
  –data-urlencode json='{“parameter”: [{“name”:”id”, “value”:”123″}, {“name”:”verbosity”, “value”:”high”}]}’
Check Jenkins Job Status via REST API
job_status=`curl https://jenkins/view/job/other-job/lastBuild/api/json | grep “\”result\”:\”SUCCESS\””`
if [ -n "$job_status" ] then     # Run your script commands here else   echo "BUILD FAILURE: Other build is unsuccessful or status could not be obtained."   exit 1 fi
How to restart Jenkins manually?
To restart Jenkins manually, you can use either of the following commands:
(jenkins_url)/safeRestart – Allows all running jobs to complete. New jobs will remain in the queue to run after the restart is complete.
(jenkins_url)/restart – Forces a restart without waiting for builds to complete.
Tagged : / / / / / / /

Work on remote Subversion repositories locally with Git


Work on remote Subversion repositories locally with Git

Version control is great stuff, and being able to combine different version control mechanisms is even better. Subversion is a very popular version control system and a lot of repositories (public or otherwise) use Subversion to manage files. Git is another popular one, but what happens if you are working on a project where Subversion is used but Git is your preferred version control system?

With the git-svn plugin, you can have the best of both worlds. You can convert a Subversion repository to Git, use Git tools, then push the changes back to Subversion.

To begin, you will need the git-svn plugin installed. Most likely, if your distribution of choice provides Git, it will also provide git-svn. On Fedora, install it using:

# yum install git-svn

Then use git-svn to check out your Subversion repository into Git format:

% mkdir -p ~/git/code

$ cd ~/git/code

% git svn init

Initialized empty Git repository in /home/user/git/code/.git/

% git svn fetch

This may take a while on large repositories

r267 = 079b7c1cff49187d1aabc4b16f316102088fdc0d (refs/remotes/git-svn)

W: +empty_dir: trunk

r268 = 3f1944530a092c811c55720bd9322b8c150a535b (refs/remotes/git-svn)

r351 = e2af3c12e5ed174d23ffc5917f03a6136f8ebb6b (refs/remotes/git-svn)

Checked out HEAD: r351

At this point, the Subversion repository located at has now been checked out in Git format. On individual files and directories, you can use the git log command as you would the svn log command in order to get history information on the item in question. With git, you will also see the Subversion commit that corresponds to the log entry, for instance:

commit 23f705cd87e1e9c6dd841ca88a14d808e0c4292a

Author: user@HOST.COM

Date:   Sat Mar 20 18:25:38 2010 +0000

correct logic on the buildrequires extractor, add stats on BuildRequires to showdbstats output

git-svn-id: 7a5473d1-2304-0410-9229-96f37a904fa4

With the above, you can see that user@HOST.COM did the commit, see the log message, and the Subversion revision (r350).

To work with these files, make changes as normal. git diff works like svn diff does, to see the changes made. To commit changes, use git commit like you would use svn:

% git commit -m “some minor change” file

[master 2454be1] some minor change

1 files changed, 2 insertions(+), 0 deletions(-)

To update your local copy from Subversion, instead of using svn update use git svn rebase. This will merge in any changes found in the Subversion repository.

When committing files using git commit, you are committing your changes to the Git repository. None of these changes are pushed to the Subversion repository until you specifically tell Git to do so. This is done with the git svn dcommit command, which then takes each commit made to Git and pushes them to Subversion as individual commits, which will retain all of your history and log comments:

% git svn dcommit

Committing to …

M      trunk/rqp

Committed r352

M      trunk/rqp

r352 = 0557314a580c4390ff646380baa3aa33d1f6a5cd (refs/remotes/git-svn)

No changes between current HEAD and refs/remotes/git-svn

Resetting to the latest refs/remotes/git-svn

Unstaged changes after reset:

M      trunk/rqp

M      trunk/rqp

Committed r353

M      trunk/rqp

r353 = 249e97283ad28126bf84ccaffb32873e12d15b7b (refs/remotes/git-svn)

No changes between current HEAD and refs/remotes/git-svn

Resetting to the latest refs/remotes/git-svn

Now, if you were to look at the changed file(s) in Subversion (via another Subversion working copy or something like ViewVC), you will see the individual commits. Above, there were two changes made to the trunk/rqp file, each committed locally to Git. The “dcommit” command pushed those changes as individual commits to the Subversion repository. In this way you can do all local development with Git and when you have something you want to commit to the Subversion repository, you can push all of the relevant changes at once, retaining each separate commit.

Using the git-svn plugin makes it extremely easy to use Git locally with a remote Subversion repository. If you are in a project or organization that, for whatever reason, does not want to convert to Git, you can continue to work with that Subversion repository, without the restriction of using Subversion yourself.

Tagged : / / / / / / / / / / / / / / / / / / /

How to run Remote Desktop Console by using command line?

How to run Remote Desktop Console using command line
If you may want to run Desktop Console from a batch file, for example RDC over VPN, you can use mstsc /v:servername /console command.


Creates connections to terminal servers or other remote computers, edits an existing Remote Desktop Connection (.rdp) configuration file, and migrates legacy connection files that were created with Client Connection Manager to new .rdp connection files.


mstsc.exe {ConnectionFile | /v:ServerName[:Port]} [/console] [/f] [/w:Width /h:Height]
mstsc.exe /edit”ConnectionFile”
mstsc.exe /migrate


Specifies the name of an .rdp file for the connection.
Specifies the remote computer and, optionally, the port number to which you want to connect.

Connects to the console session of the specified Windows Server 2003 family operating system.

Starts Remote Desktop connection in full-screen mode.

/w:Width /h:Height
Specifies the dimensions of the Remote Desktop screen.

Opens the specified .rdp file for editing.

Migrates legacy connection files that were created with Client Connection Manager to new .rdp connection files.

* You must be an administrator on the server to which you are connecting to create a remote console connection.
* default.rdp is stored for each user as a hidden file in My Documents. User created .rdp files are stored by default in My Documents but can be moved anywhere.

To connect to the console session of a server, type:
mstsc /console

To open a file called filename.rdp for editing, type:
mstsc /edit filename.rdp

Tagged : / / / / / / / / / / / / / / / / / / / /