I'm attempting to configure commandbox on a Jenkin...
# box-products
r
I'm attempting to configure commandbox on a Jenkins server that is shared by many different clients. Therefore, I cannot have commandbox placed in a common area and must keep commandbox executables specific to each client for versioning reasons. This also means that I cannot have box.exe as an environment variable to be called by Jenkins as a Windows Batch script. I have the box.exe placed in a client folder and I am pointing to it in the Jenkins Windows Batch script and trying to figure out how to also have commandbox understand where the box.json file is located in order to exucute the
update --force
script within Jenkins Windows Batch. I will show an example of the issue in this thread to save public real estate.
Example of the Jenkins console output issue.
Copy code
D:\websites\client\staging\source>d:

D:\websites\client\staging\source>cd D:\websites\client\staging\commandbox 

D:\websites\client\staging\commandbox>box

   ______                                          ______
  / ____/___  ____ ___  ____ ___  ____ _____  ____/ / __ )____  _  __
 / /   / __ \/ __ `__ \/ __ `__ \/ __ `/ __ \/ __  / __  / __ \| |/_/
/ /___/ /_/ / / / / / / / / / / / /_/ / / / / /_/ / /_/ / /_/ />  <
\____/\____/_/ /_/ /_/_/ /_/ /_/\__,_/_/ /_/\__,_/_____/\____/_/|_| (R)  v5.8.0+00695

            Tomorrow will have highs in the mid 70's and a 30% chance of rain

Welcome to CommandBox!
CommandBox> [38;5;2m[1mGoodbye![0m

D:\websites\client\staging\commandbox>box cd ../source 
D:\websites\client\staging\source\

D:\websites\client\staging\commandbox>box update --force 



[38;5;15m[48;5;9mERROR (5.8.0+00695)[0m

[38;5;9m[1mD:\websites\client\staging\commandbox\ is not a package![0m

[38;5;9m[1m[0m


D:\websites\client\staging\commandbox>exit 1 
Build step 'Execute Windows batch command' marked build as failure
Finished: FAILURE
Since I cannot use environment variables, I have to specify the path to the box.exe in order to execute it, which I believe is also how box understands where the box.json file is located which is by specifying the path to box.json. If I specify the path to box.json, then the script will not be able to execute box.exe since box.exe is not located in the same place as box.json. I did attempt (example above) to run
box
on its own, hoping that it would maybe remain in its own environment, in which I can then cd the path to point to the box.json, but it can't seem to do that in this sandboxed jenkins windows command environment.
I think I found a solution and just answering in case anyone else runs into this. The following worked
Copy code
D:\websites\client\staging\commandbox\box -cliworkingdir ../source update
b
You can totally use env vars, just not global ones. You can set the path as part of each build since every build's shell script is a process that has its own env
There really isn't an issue sharing box unless you need them to have different config settings, etc
If you want to have more than one box.exe, then make sure you use a commandbix.properties file to set the commandbox home dir for each one
And you have 3 solutions for the install • Run box install in the project folder (which is based only on the working directory of the process running box... This has nothing to do with where box.exe lives!) • Run a box recipe that "cd"s to the folder, then run install • Use the working dir param you find above to force box's initial working dir
@ryan
If I specify the path to box.json, then the script will not be able to execute box.exe since box.exe is not located in the same place as box.json.
Also, that sentence makes no sense. You can simply run box install from the folder containing box.json and just use the full path to box.exe if you don't have a path env var.
r
Thanks for the info @bdw429s. The bit that doesn't make sense may not have been clarified so well, my apologies. I did originally do what I believe you are describing as a solution. However, since I am not using environment vars, and the configs and settings do need to remain separate per client, I have to
cd
to the box.exe path. In doing so, I was originally unable to figure out a way to have box.exe know where box.json lives because I'm already using the path to point to box.exe. However, the
-cliworkingdir
parameter for box.exe is exactly what I needed in order to solve it and have the executable understand where the box.json file lives in order to process it.