What's evident by the sample app above is that the config_env is still set to whatever MIX_ENV is set to, even though the test task itself is running in the appropriate environment. As I mentioned earlier, this could be solved by just running MIX_ENV=ci mix test. It would however be nice to configure a Mix application in such a way that you could specify what the default environments for dev and test should be, so you would not need to explicitly set MIX_ENV correctly whenever you interact with mix itself. On Saturday, October 1, 2022 at 12:50:18 PM UTC+2 Kevin Hovsäter wrote:
> Sure thing. Here you go. https://github.com/hovsater/custom_envs > > Feel free to reach out if anything is unclear. What we're trying to > achieve is basically change the default environment from `dev` to `local`. > And the default test environment from `test` to `ci`. > > Thanks, > Kevin > > On Saturday, October 1, 2022 at 11:37:41 AM UTC+2 José Valim wrote: > >> 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-co...@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/8c7e5f24-c119-45ea-88f5-cae3045f98bbn%40googlegroups.com.
