use git submodules for bats-* instead of globally installed brew packages

[hanoii]

In working on ddev/ddev-drupal-contrib#85 I wanted to use bats-support and bats-assert.

I started wondering how to use them.

I am on mac and with brew info kaos/shell/bats-assert

I get

To load the bats-assert lib in your bats test:

    load '/opt/homebrew/lib/bats-support/load.bash'
    load '/opt/homebrew/lib/bats-assert/load.bash'

Ok there. Because this action uses homebrew for linux as well, I'd assume this might work, however, it is still a bit dependent on the system, and a bit cryptic, so I was thinking on a potentially better alternative:

Use git submodules: https://bats-core.readthedocs.io/en/stable/tutorial.html#quick-installation

I am not 100% sure of the implications, but I think very little, from what I gather:

• the documentation for setting up tests on https://github.com/ddev/ddev-addon-template needs to be updated, namely one would have to manually run git submodules init
• This action needs to add submodules: true to the checkout action
• In order to provide backwards compatibility, bats should still be installed globally by this action, but maybe check for a bats-core submodule somehow, this can be as simple as adding ./tests/bats/bin to the path or something more complex using git submodule commands or parsing of .gitmodules

Thoughts?

[rfay]

I haven't ever seen anything but pain from git submodules, but have been avoiding them for a long time. If this would mean adding these as submodules of the project under test, I really really wouldn't like it.

[hanoii]

If this would mean adding these as submodules of the project under test, I really really wouldn't like it.

That exactly what this means.

I am not a fan of git submodules either, and also avoid it at all costs, but this being just for tests, I figured it wasn't too bad.

I can also maybe rely on BATS_LIB_PATH and bats_load_library. But in that case, this action should also set it, and this also will mean adjusting docs.

[hanoii]

I like the fact that this can be locally and would make this action pretty independent.

[hanoii]

BATS_LIB_PATH=/opt/homebrew/lib bats -x --show-output-of-passing-tests --verbose-run tests/full.bats

this works with

bats_load_library 'bats-support'
bats_load_library 'bats-assert'

[hanoii]

I can add that to test_command but I think the action should probably set it.

AND.. I still think we should add submodules: true to the checkout action. or at least provide a configuration option so if one decide to do this, we can

[hanoii]

Although I think this makes it harder to document and onboard others for running tests locally

[hanoii]

Just saw disable_checkout_action, I think I can just manage with that, will give submodules a try 🤷🏻

[hanoii]

See https://github.com/ddev/ddev-drupal-contrib/actions/runs/11296006345/job/31419956642?pr=85

This exemplifies the potential issues:

/home/linuxbrew/.linuxbrew/lib is what need to use on the action instead of /opt/homebrew/lib locally

[rfay]

This is super easy:

  TEST_BREW_PREFIX="$(brew --prefix)"
  load "${TEST_BREW_PREFIX}/lib/bats-support/load.bash"
  load "${TEST_BREW_PREFIX}/lib/bats-assert/load.bash"
  load "${TEST_BREW_PREFIX}/lib/bats-file/load.bash"

[hanoii]

what if someone didn't setup bats with homebrew? I guess unlikely

[hanoii]

You'll know more than me how unlikely that can be, thoughts?

[rfay]

It's not unlikely for local. It's easy on macOS, easy on Linux amd64. Impossible on Linux arm64. But the other instructions are still there in https://github.com/ztombol/bats-docs?tab=readme-ov-file#installation

Maybe npm is the best way?

I've always been hoping to become more of an expert and more of a fan of bats and these assert libraries, but they still frustrate me also.

[hanoii]

I still believe for this particular use case, gitsubmodules is the way to go, I will give it a try and see if the maintainer likes it and let you test drive it.

[hanoii]

I don't like having to relay for npm just for running tests

[hanoii]

This worked though: ddev/ddev-drupal-contrib@b2ba34c