Our github action:

jobs:
  tests:
    name: Tests
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name : Start the servers and wait until up
        run: ./ci.sh

      - name: Checkout Repository
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Setup Java
        uses: actions/setup-java@v2
        with:
          distribution: "adopt"
          java-version: "11"

      - name: Setup CommandBox
        uses: Ortus-Solutions/setup-commandbox@main

      - name: Install dependencies
        run: box install

      - name: Start server
        run: box server start cfengine=lucee@5.3 --noSaveSettings

      - name: Run TestBox Tests
        run: box testbox run reporter=text

maybe a box.json override or something that Ortus uses we need to set?

Also, is your

UserServiceTest.cfc

extending the coldbox base integration test class?

You can also add a recursive directory listing to your build output just to confirm the file are on disk.

Yes

UserServiceTest

is extending coldbox BaseTestCase

Do you know how this path gets set during box install?

Installing to: /home/runner/work/my-emc/my-emc/coldbox

Note: double my-emc

That tells me you may be running your commands from the wrong folder

Or you have custom stuff in your

box.json

that's overriding the install paths (bullet #2)

appreciate the help

So I think I narrowed it down to GITHUB_WORKSPACE setting checkout to /home/runner/work/my-emc/my-emc (which is a standard practice apparently) Where do you recommend setting the module load prefix to account for the extra

my-emc

? As a command line option or custom box.json?

CommandBox doesn't really care what directory you're in

So long as

box install

runs from the root of the app-- wherever that may be, the installation paths are all relative.

We had wanted to get integration tests working in Github actions instead of mocks for this one so this is the last effort to do so before resorting to mocks.

Firstly,

models

is already the default scan locations for wirebox inside of a coldbox app. Secondly, there's really no need to be manually pointing scan locations to a module's files. As part of the module registration, WireBox will just automatically and recursively map the module's entire models folder so everything should "just work".

The manual mapping is also unecessary-- the module should be taking care of all that.

I think you should back up and check if the module is even getting loaded properly by ColdBox in the first place. Because if these mappings aren't existing, that tells me the module didn't load at all!

Also, a quick note on scan locations, vs mapping a directory. A scan location works the same as views, handler, or layouts, meaning it's a root path and you must provide the full relative path inside. Go, given a file at

<your-webroot>/models/foo/bar/Baz.cfc

if you are just using the default scan location of

/models

the you would need to ask wirebox for Baz like so

getInstance( 'foo.bar.Baz' )

however, if you put this line of code in your

/config/WireBox.cfc

...

mapDirectory( 'models' )

then WireBox recursively scans all subdirectories and eagerly creates mappings for every CFC it finds. Now you can just ask WireBox for this

getInstance( 'Baz' )

Now that said-- this has nothing at all to do with how cbauth should be working. When ColdBox loads a module it automatically runs

mapDirectory()

on the models folder of that module AND it provides a default suffix, which is the name of the module. So,

.../cbauth/models/AuthenticationService.cfc

creates, by convention, a default WireBox mapping called

<name-of-CFC>@<name-of-module>

which in this case is

authenticationService@cbauth