A choice prompt should be done with command CHOICE and not with set /P:
:SelectBuildOption
%SystemRoot%\System32\choice.exe /C 123 /N /M "Select the build option:"
if errorlevel 3 goto SELECT_APP_H
if errorlevel 2 goto SELECT_APP_M
if errorlevel 1 goto SELECT_APP_L
goto SelectBuildOption
Please read my answer on How to stop Windows command interpreter from quitting batch file execution on an incorrect user input? It explains in full details the usage of set /P and the usage of CHOICE and explains also the advantages and disadvantages of both solutions for prompting a user for something.
There can be used the following code above the label SelectBuildOption in the batch file prod_release.bat if the batch file is executed by Jenkins with an argument like 1 for build as defined by SELECT_APP_L or 2 for a build as defined by SELECT_APP_M or 3 for a build as defined by SELECT_APP_H.
if "%~1" == "1" goto SELECT_APP_L
if "%~1" == "2" goto SELECT_APP_M
if "%~1" == "3" goto SELECT_APP_H
It would be of course also possible to use other, more meaningful strings than 1 and 2 and 3 for the optional build option like:
if /I "%~1" == "APP_L" goto SELECT_APP_L
if /I "%~1" == "APP_M" goto SELECT_APP_M
if /I "%~1" == "APP_H" goto SELECT_APP_H
With that code the batch file can be called by Jenkins with APP_L or APP_M or APP_H (case-insensitive) without or with being enclosed in ".
The code below the three IF conditions which is the code below the label SelectBuildOption is executed by cmd.exe if none of the three conditions is true because of batch file is called without any argument or the first argument is not equal with one of the three compared strings.
Run call /? in a command prompt to get output the usage help of the command CALL explaining how to reference batch file arguments.
I recommend to read also my answer on Symbol equivalent to NEQ, LSS, GTR, etc. in Windows batch files. It explains in full details how a string comparison is done by the internal command IF of the Windows Command Processor cmd.exe.
If the Jenkins job defines an environment variable for the build option to use, then just replace %~1 by %VariableName% on the three IF command lines and the batch file works also for usage by Jenkins with build option defined by the environment variable while the batch file can be still used for manual execution.
Example with batch file supporting optionally an environment variable BuildOption defined outside of the batch file by the parent process:
if not defined BuildOption goto SelectBuildOption
if /I "%BuildOption%" == "APP_L" goto SELECT_APP_L
if /I "%BuildOption%" == "APP_M" goto SELECT_APP_M
if /I "%BuildOption%" == "APP_H" goto SELECT_APP_H
It is common practice that scripts used for build processes support optionally either one or more arguments to control the build process or one or more environment variables for automated builds while prompting the user of the script for the necessary options controlling the build process on using the script without the optional argument(s) or without the optional environment variable(s).
So I strongly recommend to contact the author of the batch file and ask to enhance the batch file prod_release.bat as suggested above for easy usage in a fully automated build process. The execution behavior for manual usage does not change with thesse modifications which are important for the fully automated build by Jenkins.
Another possibility would be to output the answer for the prompt and redirect this output from stdout of cmd.exe to stdin of the batch file.
Example:
(echo 1)|prod_release.bat
This command line lets cmd.exe redirect the string with the bytes 0x31 0x0D 0x0A (1 as ASCII character + carriage return + line-feed) to standard input stream of the batch file which is read by first set /P or choice in the batch file from the input stream and therefore results in an automatic answer of the first prompt with (hopefully) an acceptable choice.
But such an approach is very uncommon for scripts used in build processes. A small modification of the called script file like running an executable or command reading first from the input stream could result with this workaround solution in a wrong execution of the script and results therefore again in a not working automated build process. This workaround solution is for that reason really awful in comparison to making the enhancement of the script to support optional arguments or optional environment variables to define the necessary build options by the parent process instead of always prompting a user for the necessary build options.
A good coded script used for a build process supports optional arguments or optional environment variables defined outside of the script to control the options for the build process and prompts for these options if the script is executed without the argument(s) or without the environment variable(s) defined by the parent process, i.e. when the script is executed by a user.
