http://coldfusion.com logo
Join Slack
Powered by
I have a question about running a server inside a ...
# box-products
b
I have a question about running a server inside a Docker container in a GitLab CI workflow. Details within.
Copy code
$ box server start directory=/builds/premier/core/ --verbose
  √ | Starting Server
    |------------------------------
    | start server in - /app/
    | server name - app
    | server config file - /app//server.json
If I specify the directory, why does CommandBox start the server in /app even when I tell it to start elsewhere?
b
Chances are you have a server defined already in the container and multi-server is disabled
Run
Copy code
config show server.singleServerMode
That defaults to true in the CommandBox docker images
b
GitLab doesn't have the capability to (easily) clone my project elsewhere, so putting the code in to /app is going to be a battle
I'll try 
config set server.singleServerMode=false
in my CI tasks and see if that gets me what I need
I'm using the 
ortussolutions/commandbox:adobe2016-alpine
image in case that matters
Documenting all this for later in case I need to write up a post about it
Before starting my server in the container there's already a stopped server in /app that I can't use.
Copy code
$ box server list
 Processing (1) servers, please wait...
 app (stopped)
   <http://0.0.0.0:8080>
   CF Engine: adobe 2016.0.17+325979
   Webroot: /app/
   Last Started: 31-Jan-2022 21:25:19
Alright, great. The tests fail! But at least they run.
b
@bockensm If you want a simple image to use in Gitlab that will let you start random servers anywhere, I would recommend Pete Freitag's 
foundeo/minibox
image
Unlike the Ortus image, which is highly opinionated and designed for a single thing, mininox is just a generic and VERY small image with CommandBox that doesn't have any of the restrictions the Ortus image has
I'm using the 
ortussolutions/commandbox:adobe2016-alpine
Right, so stop using a prewarmed image as well. There's literally no reason to use it and it's just going to cause you problems.
The Ortus images make a number of assumptions as soon as you use them • There will be one server • it will never change version • it will never change the web root • You can it automatically started as the entry point of the container as soon as it boots and when you use a pre-warmed image, there's even more assumptions made • you want whatever specific version of Adobe or Lucee was in the prewarmed server • you don't try to override or change the version • You're stuck with the default web root of 
/app
and the existing server home "locked in" as part of the prewarm process
I'd guess nearly every single one of those assumptions don't apply to your use case
So, if you just want a base image to run your CI stuff in which has CommandBox ready to go so you can spin up ad-hoc servers like you would locally, I'd reach for minibox-- or better yet, 
foundeo/cfml-ci-tools
image Pete has which is basically minibox plus a bunch of super useful stuff ready to go • fixinator • cfml-compiler • commandbox-codechecker • commandbox-cflint • commandbox-cfformat • commandbox-dotenv • commandbox-cfconfig • commandbox-docbox • commandbox-semantic-release It's basically everything you need to do your CI tasks but with zero of the opinionated assumptions baked into the Ortus images
b
cfml-ci-tools seems like it makes more sense in my case
I tried minibox but I had some errors. I think I'm getting the same with cfml-ci-tools with the GitLab CI runner: (@foundeo). 
box list
is the only script I'm running
Copy code
$ box list
 javax.script.ScriptException: lucee.runtime.exp.MissingIncludeException: Page /__commandbox_root/.CommandBox/cfml/system/Bootstrap.cfm [/builds/premier/core/root/.CommandBox/cfml/system/Bootstrap.cfm] not found
 	at lucee.runtime.PageSourceImpl.loadPage(Unknown Source)
 	at lucee.runtime.PageContextImpl._doInclude(Unknown Source)
 	at lucee.runtime.PageContextImpl._doInclude(Unknown Source)
 	at lucee.runtime.PageContextImpl.doInclude(Unknown Source)
 	at 1hakaskpj4qmq.call(Unknown Source)
 	at lucee.runtime.compiler.Renderer.tag(Unknown Source)
 	at lucee.runtime.compiler.Renderer.script(Unknown Source)
 	at lucee.runtime.jsr223.ScriptEngineImpl.eval(Unknown Source)
 	at lucee.runtime.jsr223.ScriptEngineImpl.eval(Unknown Source)
 	at cliloader.LoaderCLIMain.execute(LoaderCLIMain.java:330)
 	at cliloader.LoaderCLIMain.execute(LoaderCLIMain.java:155)
 	at cliloader.LoaderCLIMain.main(LoaderCLIMain.java:582)
 Caused by: lucee.runtime.exp.MissingIncludeException: Page /__commandbox_root/.CommandBox/cfml/system/Bootstrap.cfm [/builds/premier/core/root/.CommandBox/cfml/system/Bootstrap.cfm] not found
 	... 12 more
 Cause:
 lucee.runtime.exp.MissingIncludeException: Page /__commandbox_root/.CommandBox/cfml/system/Bootstrap.cfm [/builds/premier/core/root/.CommandBox/cfml/system/Bootstrap.cfm] not found
 	at lucee.runtime.PageSourceImpl.loadPage(Unknown Source)
 	at lucee.runtime.PageContextImpl._doInclude(Unknown Source)
 	at lucee.runtime.PageContextImpl._doInclude(Unknown Source)
 	at lucee.runtime.PageContextImpl.doInclude(Unknown Source)
 	at 1hakaskpj4qmq.call(Unknown Source)
 	at lucee.runtime.compiler.Renderer.tag(Unknown Source)
 	at lucee.runtime.compiler.Renderer.script(Unknown Source)
 	at lucee.runtime.jsr223.ScriptEngineImpl.eval(Unknown Source)
 	at lucee.runtime.jsr223.ScriptEngineImpl.eval(Unknown Source)
 	at cliloader.LoaderCLIMain.execute(LoaderCLIMain.java:330)
 	at cliloader.LoaderCLIMain.execute(LoaderCLIMain.java:155)
 	at cliloader.LoaderCLIMain.main(LoaderCLIMain.java:582)
my 
.gitlab-ci.yml
is as such:
Copy code
stages:
  - test

Testbox:
  image: foundeo/cfml-ci-tools
  stage: test
  script:
    - box list
b
Meh, that's the stupid Lucee mapping bug I think
Just need to figure out which folderin your current directory is confusing Lucee
is 
/builds
at the root of the file system or is there a builds folder in the current working directory box is being run from
b
it's a root folder. GitLab runs everything out of that by default.
b
What is the working directory the 
box list
gets run from?
Usually when people get this error, it's because they have a 
users
folder in their current working dir which confuses Lucee if CommandBox is under 
/users/foo/
But I'm not sure what the folders look like in your case
b
Copy code
$ ls /builds
 premier
 $ pwd
 /builds/premier/core
premier/core is the repo that's running CI, so GitLab clones it to /builds and I end up with /builds/premier/core as the working directory
I can't get in much detail about what's in the working directory as it's the entire app structure, but there is no users folder there.
b
forget users
that was just an example of what people normally hit
b
ah, thought it was literal
b
in your case, I assume it's a builds folder
b
ooooooooo
I've been here before
b
What matters here is • what folder is the command running in? • what folders are in this folder?
b
I'm getting some flashbacks
b
Lucee usually pukes here when there's a folder in the current working directory with the same name as the FIRST folder in the absolute path to the CommandBox home
b
I have a folder called "root" in the working directory and I'll bet you that's what's tripping it up. I know I've come across this before.
yep, that was it. removing the "root" folder allows the list commands to work.
It's kids bedtime, so I've gotta go. Thanks for your help!
b
freaking lucee bugs
I reported this years ago
I think the first one, but I KNOW the second one comes up all the time in minixbox when I'm playing around
LDEV-2893 makes it freaking impossible to run the Commandbox repl from your drive root (which is often times the default working directory in a docker container)
you'll also notice Michas "fix" for 1728 in the comments was to add a stupid setting that required me to have an Application.cfc making it TOTALLY WORTHLESS in JSR-223
grumble grumble 😠
But basically, I'm pretty sure 
/builds/premier/core/root/.CommandBox/cfml/system/Bootstrap.cfm
doesn't exist. The correct path should have been
Copy code
/root/.CommandBox/cfml/system/Bootstrap.cfm
but your working directory of the process running box was likely
Copy code
/builds/premier/core/
which becomes Lucee's "webroot" and default 
/
mapping. I assume that directory has a folder in it called 
root
so when Lucee looks at the relative path 
/root/...
it "finds" the root folder it believes to be in its "webroot" (the working dir of the java process) and uses it instead of the actual 
/root
folder at the base of your file system
Windows has no such ambiguity, and Lucee has no setting I'm aware of to force it to use one over the other. And any attempts I've ever taken to override Lucee's 
/
mapping have ended in flames (and unfixed JIRA tickets).
I didn't used to have this issue prior to the JSR-223 rewrite and Lucee 5 as the old school way of running Lucee used to allow me to set my own "webroot" or 
/
mapping, but Lucee's JSR-223 implementation forces it to the the working dir of the java process.
b
I believe your assertion about the root subdirectory getting mapped to /root is spot on
b
Hmm, I think I may have actually found the stupid code that sets the web root in JSR-223
Copy code
final File root = new File("."); // working directory that the java command was called from

				final ServletContextImpl servletContext = new ServletContextImpl(root, attributes, initParams, 1, 0);
I'll see if I can get that to read from a system property by default. If so, it would be fantastic to be able to force the context root (web root, basically) to the drive root
I've wasted so many hours over the years trying to get Micha to fix and troubleshooting the errors it causes 😕
b
Are there some instructions somewhere for generating my own pre-warmed Docker images? I have two packages to install, then a server to start, and if I can start from a place where those packages are already installed and the engine was downloaded, I can save 2-3 minutes per job.
Open in Slack
PreviousNext
Powered by