System.getEnv does not update between different runs #257
Comments
Baccata
added a commit
to Baccata/mill
that referenced
this issue
Mar 29, 2018
Since Mill now executes in a long-lived JVM, the builds do not have a chance to use environment variables as inputs. This propagates the environment variables from the client all the way down to the context available to the tasks as a `Map[String, String]` so that they can be used as inputs should the user choose to do so. com-lihaoyi#257
Baccata
added a commit
to Baccata/mill
that referenced
this issue
Mar 29, 2018
Since Mill now executes in a long-lived JVM, the builds do not have a chance to use environment variables as inputs. This propagates the environment variables from the client all the way down to the context available to the tasks as a `Map[String, String]` so that they can be used as inputs should the user choose to do so. com-lihaoyi#257
2 tasks
Baccata
added a commit
to Baccata/mill
that referenced
this issue
Apr 5, 2018
* Moved the `System.getenv` side effect to the end of the world * Adds a test to make sure that the `Map[String, String]` gets propagated correctly * Adds a `Ctx.Env` trait for consistency com-lihaoyi#257
Baccata
added a commit
to Baccata/mill
that referenced
this issue
Apr 5, 2018
Adds documentation about the Ctx.Env API to indicate that the user should not use `System.getenv` com-lihaoyi#257
Baccata
added a commit
to Baccata/mill
that referenced
this issue
Apr 5, 2018
Adds documentation about the Ctx.Env API to indicate that the user should not use `System.getenv` com-lihaoyi#257
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
This is most likely a downside of keeping a daemon jvm, but it makes it impossible to use environment variables as inputs.
Maybe the mill launcher should pass the full environment to the program as a hidden parameter, which would allow for mill to provide a default
Map[String, String]input ?The text was updated successfully, but these errors were encountered: