Can't run python scripts in Jenkins

Question

I have been using Jenkins for a few years and recently bought a new Windows 10 PC. I installed Jenkins 2.89.2, Visual Studio 2017 and Python 3.6 and copied several Jenkins jobs from my previous Windows 7 PC.

The problem that I encountered was that all the python scripts in the free-style Jenkins jobs now do nothing.

I have similar command-line batch files which run these python scripts which work just fine in a command window on the new PC.

I have also checked the file associations with ftype, and ended up changing it:

ftype Python.File
Python.File="D:\Python36_64\python.exe" "%L" %*

My work-around is like this:

Example line which worked under Windows 7:

CreateBuildNumber.py <= uses PATH to find this file, then file associations to run python

Replacement line need to work under Windows 10:

python .\Scripts\CreateBuildNumber.py <= uses PATH to find python.

How can I avoid explicit paths in my scripts?

Update:

D:\project>assoc | findstr -i python
.py=Python.File
.pyc=Python.CompiledFile
.pyd=Python.Extension
.pyo=Python.CompiledFile
.pyw=Python.NoConFile
.pyz=Python.ArchiveFile
.pyzw=Python.NoConArchiveFile

echo %PATH%
D:\Python36_64;D:\Python36_64\Scripts;.\Scripts;"C:\Program Files\CppCheck";C:\windows\system32

Further Info

I removed .\Scripts from the %PATH% and re-ran the job, having also moved demo.py into .\Scripts, now instead of doing nothing there is the error:

'demo.py' is not recognized as an internal or external command, operable program or batch file.

This means that Windows IS looking for and finding python scripts, but is failing to execute them. Why would windows not take the next step and use file associations to find an executable program to run, taking the file as a parameter?

Update:

Now everything works as it should and I don't know why.

I recently started using a different job on Jenkins that I had neither run nor touched for over two years and that one just worked without modification. I have since gone back over the job in question and reverted all the changes and this one works as well.

My guess is that Windows 10 has been patched.

Answer 1

The fact that "demo.py" gives the message '...is not recognized as an internal or external command' doesn't convince me that your script is recognized as executable. If I type 'turkey.abc' into a command prompt window I get the same error, and I don't have a tool for executing '.abc' files.

I see two possibilities here:

1) In batch scripts, executable extensions sometimes must appear in an environment variable called PATHEXT.

In the Jenkins batch script, add a "set" command near the top of the script to dump the environment variables for your running script into your Jenkins build log (you can remove the set command after this is debugged). Run the build. Look not only for the definition of PATH, but also at PATHEXT. Is ".py" one of the extensions listed there?

I have experienced this problem with Perl scripts. However, I'm wimping out on claiming this definitely since in testing on my Windows 10 home PC I am successfully executing .py scripts even without it being in PATHEXT, so it's something to try but it may not be this.

2) Another possibility is that the environment in which your service is running is different than the environment you get when you open a command prompt on your desktop (because the Jenkins service runs as a different user than the one you log in as.)

Adding "set" to your Jenkins batch commands will help debugging this too, since it will show you the environment your Jenkins script is running in. Then you can examine PATH to see if your script folder is being found.

It is also possible that the file associations for Python were installed for your user only, not for all users (i.e., in HKEY_CURRENT_USER in the registry instead of HKEY_LOCAL_MACHINE). That is harder to dump into your Jenkins log - the 'reg' command would do it, but it will take you a number of tries to get everything you need. You might be able to figure it out by just examining the registry. Search for ".py" - if it occurs in HKEY_LOCAL_MACHINE that is not it; if it occurs in HKEY_CURRENT_USER that is at least part of the problem.