Senthilkumar Palanisamy I think I've been able to duplicate the problem, with some further guessing.
The list of tags and branches in the parameterized plugin pick list includes "ssh not found" if I attempt my git parameter plugin based job on a Windows agent and run it twice. So long as I run the job on a Linux agent (any Linux agent, not just limited to the master agent), then it is well behaved. Once I've executed on a Windows agent, it reports "ssh not found" and refuses to show the list of branches/tags.
In my case, I used a URL of the form ssh://hostname:port/path/to/repo.git, though it fails the same way when I use a URL of the form user@hostname:/path/to/repo.git.
Note that all those failures require a Windows machine. They don't seem to happen until a Windows machine is involved. I have a multi-configuration job which uses the same technique to copy files to all my machines (Windows and Linux) and it works correctly. I assume it works correctly because the initial evaluation of the git parameters happens on a Linux machine. When I switch and force that initial evaluation of git parameters to a Windows machine, then the multi-configuration job shows the same failure.
I believe this will need further investigation by the maintainer of the git parameter plugin. The issue may ultimately be in the git client plugin, but I would rather have the git parameter plugin maintainer (or you) perform that investigation.
Alternatives to avoid the problem include:
- Use a string or a list of choices rather than a git parameter to select the branch name
- Run the job on a Linux machine
- Make the job a multi-configuration job that starts on a linux machine, then defines the name of the windows agent to execute the job