Got it! I just tried making an alias called "test" that points to "test.ci" 
and then I defined as task within lib/mix/tasks/test.ci.ex containing the 
following code:

defmodule Mix.Tasks.Test.Ci do
  use Mix.Task

  @preferred_cli_env :ci

  @impl Mix.Task
  def run(_args) do
    if Mix.env != @preferred_cli_env, do: Mix.env(@preferred_cli_env)
    Mix.Task.run("ecto.create", ["--quiet"])
    Mix.Task.run("ecto.migrate", ["--quiet"])
    Mix.Task.run("test")
  end
end

Unfortunately,  that didn't seem to help. The Mix.env() is correct from 
within the Test.Ci task, but I assume it's not propagated to the tasks I 
run. How would I go about solving that? I realize this have become more of 
an support issue than actual proposal so I'm fine with taking this 
somewhere else. :)
On Saturday, October 1, 2022 at 11:03:37 AM UTC+2 José Valim wrote:

> > 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?
>
> Right. Either an alias or a custom task!
>
> On Sat, Oct 1, 2022 at 10:45 AM Kevin Hovsäter <ke...@hovsater.com> wrote:
>
>> 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-co...@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
>>  
>> <https://groups.google.com/d/msgid/elixir-lang-core/7b49f422-aae2-4c75-9224-b7b88c7479b1n%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/9cfa0ec0-8dd3-4564-a37e-ce2245966983n%40googlegroups.com.

Reply via email to