Can you upload a very small mix new repo to GitHub with what you tried pls?
:)
On Sat, Oct 1, 2022 at 11:08 AM Kevin Hovsäter <ke...@hovsater.com> wrote:
> 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
> <https://groups.google.com/d/msgid/elixir-lang-core/9cfa0ec0-8dd3-4564-a37e-ce2245966983n%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/CAGnRm4LpBYXPV0QLzB1_GpN4HpawK-kUG0WiSdQns_3DN9o0uw%40mail.gmail.com.
