Allow to config the context with a file in the current path

[c33s]

as i have multiple customers on hetzer servers which all have their own account i would love to have a file like .hcloud where i can specify the current context. so switching between directories will automatically switch context for hcloud (never work in production context while thinking to work in the development context)

having the following directory tree:

project dir
├───acme
│       .hcloud (contains: `context: acme_production`)
│
├───acme_development
│       .hcloud (contains: `context: acme_development`)
│
├───foobar
│       .hcloud (contains: 'context: foobar_production`)
│
└───foobar_development
        .hcloud (contains: `context: foobar_development`)

so swtiching to the directory acme and calling hcloud context active will show acme_production, switching to the directory foobar_development running hcloud context active there will show foobar_development.

[thcyron]

I implemented that in the autocontext branch: https://github.com/hetznercloud/cli/tree/autocontext

Just put the name of the context to activate in a file called .hcloud-context.

Please give it a shot.

[c33s]

@thcyron

Please give it a shot.

would love to try but it looks a little tricky to compile a specific branch. any hints?

[thcyron]

Clone the repo, checkout the branch, and do:

$ go build -o hcloud ./cmd/hcloud/main.go
$ ./hcloud server list

[c33s]

thanks for the build support. works like charm.

aaaawwwsome! the simple config file implementation also works if called from my cmder lua script which i use for my command prompt.

gitbranch | hetzner cloud context | terraform workspace

[divramod]

the branch you mentioned is gone, is it still somewhere around here? if yes, where can i find it? thx in advance!

[c33s]

to dig out the discussion/decision from the PR https://github.com/hetznercloud/cli/pull/162:

@thcyron:

After discussing this PR in our team, we decided to not continue with this particular implementation with a .hcloud-context file. Until another proposal is submitted, you would need to utilize the already existing HCLOUD_* environment variables.

https://github.com/hetznercloud/cli/pull/162#issuecomment-460320408

which was from my point of view a bad decision leaving me with a self compiled old version of hcloud cli. many people don't understand that environment variables are not the holy grail. they are awesome but not the solution for everything. config files are still comfortable und useful. keeping it like this is a bad DX (developer experience)

@c33s:

just had a look at direnv, it doesn't look like to have full windows support. if i don't use bash i can't do a eval "$(direnv hook bash)" so it won't run as transparent as a simple config file. often i cannot easily control which shell a process spans.

will terraform span a bash shell where it will load my profile where the direnv is loaded?
will the direnv smoothly work within a bash shell called with terraform on windows?
how will hooking behave if called from terrafrom?

sounds like a lot of overhead, config and testing for simple context switching.

having a full TOML/YAML/JSON file with a full possibilities for configuring hcloud would be awesome. it makes a really good developer expierence without killing performance. the only performance overhead is one if file_exists() check. no pain and much gain :)

@thcyron again the plea to simply include a config file from the local directory. there is nothing easier than reading a config file. your suggestion (direnv) with environment variables does not work on windows in every setting/setup and requires another tool in the chain. so please readd the feature you had already build in #162. if you use environment variables for everything its like you use a hammer for everything, for chopping trees, drill holes or for screws. sorry for my sarcasm but i often had the discussion of having a flat roof or a pitched roof with people not being open for the fact that in software architecture its not always an or most of the time its an and and you simply can have both. we need more diversity in software not only in people creating software. your way (env vars) are the right way for you and my way (config file) is the right thing for me. so please simply let us have both and make developers happy and allow us to use this awsome tool on multiple platforms in multiple environments and do not dictate that i have to use a linux os or a bash if i want to have this freature on windows.

again: diversity

@divramod i pushed the branch to my fork https://github.com/c33s/cli/tree/autocontext you also can see the changes @thcyron made in the PR #162. if i need a