feat: add env vars import at application creation

[davlgd]

Fix #651

This PR adds a --env/-e option to import env vars from a file during clever create.
If no file name is declared, it uses .env by default.

[aurrelhebert]

Should we really do that? This means that env vars are stored locally. What would be the win compared to using a config provider for example?

[davlgd]

Should we really do that? This means that env vars are stored locally. What would be the win compared to using a config provider for example?

When a user creates an application or deploy an existing project needing env vars, he should create the app and then import env vars. As we can now do both in 1 step from API, it could be great to have such a feature directly from clever create (and it simplifies process for 1-click apps/tutorials).

Config provider is a Clever Cloud centric way to share env vars with an app, I'm not sure it covers the same needs.

[aurrelhebert]

I get the aim, I think that a lot of env vars could be shared to an app with a Config Provider enabling already a 1 click order for most tutorials.

However indeed it could be great to be able to add env variables directly when we order a new application. First I would see something like:

clever create --set-env='key=value'
clever create --set-env='key=value' --set-env='key42=value42' 

And from here I am not sure that we should loaded it from a file, maybe it could something like (we should discuss it I think) :

clever create --set-env-from='.env'
clever create --set-env-from='.env.json'

[davlgd]

I'm not opposed to a --set-env option, but it's a complementary approach, not an alternative. Why would we ask the user to detail all env vars in a command line if there is already a file containing them ? And a file at the root of the project is a common/standard way to do it.

BTW, --set-env-from seems a bit long to me (but you knew I'll say that 😄 )

[github-actions]

🔎 A preview has been automatically published:

• 🐧 linux 1d3976b5c07841ea7bf23dd01dd75879476284855b73dc545a1d3ca0013c87db
• 🍏 macos 54edac56e679efdc7891fd963883f1d64427de58ccc81263d5f3a70a5ef8dcae
• 🪟 win 1986270779dc7609b7f094d4829f86c945bbb1b51000b5c2de484d67e660b9b5

This preview will be deleted once this PR is closed.

[aurrelhebert]

Thanks for your feedback on this, the more I think of if, the less I am convinced. I am afraid that this would enforce a sort of bad practice (having a local env file), that could easily lead to leaking secrets.

I am more in favour to add env vars threw the CLI with --set-env and if there is too many threw a configuration provider. Maybe we could see how we can create a Configuration provider from a local file?