Force PHPUnit Environment to "testing" Since Github Test Workflow is Inheriting "Local"

[allella]

Per conversation in #726 we had support for forcing PHPUnit to use testing.

The Github action that runs our tests is copying .env.ci and that's set to 'local', which appears to preempt the phpunit.xml value.

[allella]

@bogdankharchenko here's the original concern. I've copied the comment below since the link jumping seems to be doing goofy things.

I'm pretty sure the only reason I messed with it to begin with is I noticed it was failing on the GH action saying the 'local' environment didn't match its expectation of 'testing'.

The action runs cp .env.ci .env. I'm guessing that's preempting what's set for the phpunit.xml APP_ENV ?

Should we set phpunit.xml to force the environment to testing?

Our .env.ci does declare the 'local' environment and the workflow file is running cp .env.ci .env. That seems to be causing Github to run tests as 'local' instead of 'testing'

If I recall, the test_robots_txt_disallows_all_in_non_production_test was failing on Github saying that 'local' didn't match 'testing'.

Before we do anything else, it's probably worth verifying if that's the case by emitting the environment variable as part of the testing workflow to find out if Github is running tests in 'local' (via to the .env.ci copying) or 'testing' (via phpunit.xml).

Note that I changed test_robots_txt_disallows_all_in_non_production_test in #726 so it checks for 'not production' instead of specifically for 'testing'. That change allowed for running artistan test to pass locally and it makes sense because robots.txt should be Disallow in all environments besides production.

Here's test_robots_txt_disallows_all_in_non_production_test as it is now. This test would pass regardless of if Github is running in 'testing' or 'local', but that's by design as we expect to see Disallow in any env that's not production.

[oliviasculley]

I'm not sure about this change, to me needing to add something that says force="true" seems hacky but I am not as up to date with the PHP ecosystem

[allella]

@oliviasculley @bogdankharchenko the main question is if we are intentionally importing .env.ci into the workflow.

It declares local, which seems odd to me. I would have assumed 'testing'

If that's the fix, then I agree that we don't need this PR, but rather a PR to change .env.ci to testing.

[oliviasculley]

I just read a little more and I think we should definitely be modifying the .env.ci and/or the workflow to accomplish this just for the CI environment rather than the phpunit.xml which would affect all environments

[allella]

I'm pulling @irby back in as the .env.ci was created by Matt with 'local' in the original file.

I feel like he thought the phpunit.xml change was okay, but it could have been that I should have suggested a better solution, like could we "fix" the .env.ci, or should we change the Github workflows to use the .env.testing.

The .env.ci and .env.testing both use
APP_ENV=local

I'm not a testing guru, so I'm not even sure if/why we need both and if we could simply change .env.ci or .env.testing to APP_ENV=testing.

If that's the easy fix, then we'd also want to compare .env.testing and .env.ci because the former is probably out of date.

Side note, since I looked it up.

There is a lot of overriding that can happen (summary below), so I agree the PHPUnit thing feels sort of ick if we can fix it at another level.

1. GitHub Actions Environment Context: Variables defined directly in your .github/workflows/*.yml file (via the env: key at the step, job, or workflow level) take ultimate priority.
2. PHP CLI Execution: Variables passed as inline arguments right before the execution command in GitHub Actions (e.g., APP_ENV=testing php artisan test).
3. The Block in phpunit.xml: Any variables explicitly set within or tags in your phpunit.xml file.
4. Specific Environment Files: Laravel loads the corresponding environment file based on the context (e.g., .env.testing if it exists).
5. The Base .env File: The fallback for any variables not defined by the above methods.