Thanks for the quick reply.

Right, I think that would be a possibility. So I would have MIX_ENV set to 
"local" by default, and then explicitly set MIX_ENV to "ci" when invoking 
the test task? I assume that would be done through an alias?

> Another option is to relax the check we have inside "mix test" and only 
raise if you are accidentally trying to run tests inside the "dev" 
environment. Then you could change the preferred_cli_env env for the test 
task directly in your mix.exs.

I'm not sure that would help as we still need to set MIX_ENV to "local" to 
not accidentally invoke "dev" (dev means something different in our case). 
And since MIX_ENV is set, preferred_cli_env isn't respected when invoking 
mix test.

On Saturday, October 1, 2022 at 10:29:34 AM UTC+2 José Valim wrote:

> Perhaps a simpler fix is to add a "ci" Mix task to your projects that:
>
> 1. sets MIX_ENV to "ci" if not set
> 2. invokes "mix test"
>
> Another option is to relax the check we have inside "mix test" and only 
> raise if you are accidentally trying to run tests inside the "dev" 
> environment. Then you could change the preferred_cli_env env for the test 
> task directly in your mix.exs.
>
> On Sat, Oct 1, 2022 at 10:05 AM Kevin Sjöberg <ma...@kevinsjoberg.com> 
> wrote:
>
>> I'm currently working with a client that have hard requirements on what 
>> the default environments should be across all their products. For instance, 
>> `local` is the default environment. `ci` is the default environment for 
>> running tests and `dev` is used as a development staging environment.
>>
>> Mix supports the `preferred_cli_env` option, which I can declare on a 
>> project level. This is nice because it allows me to specify the preferred 
>> environment for the test task. Unfortunately, there's no way of specifying 
>> the default environment. It's currently hard-coded to `dev` unless 
>> `MIX_ENV` is set. The problem with having `MIX_ENV` set is that it simply 
>> makes `preferred_cli_env` void as the environment variable always takes 
>> precedence, so I'm left with having to specify `MIX_ENV` explicitly when 
>> running tests anyway.
>>
>> I propose adding a new option, `default_env`, to the Mix project 
>> configuration. If set, it will be reported by `Mix.env` unless `MIX_ENV` is 
>> also present.
>>
>> I'd love to hear some thoughts before I pursue this any further.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elixir-lang-co...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/9029fb90-362d-4a1f-be30-6a8b3bd5f074n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/elixir-lang-core/9029fb90-362d-4a1f-be30-6a8b3bd5f074n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/7b49f422-aae2-4c75-9224-b7b88c7479b1n%40googlegroups.com.

Reply via email to