Allow Dot (".") in property name
surajvel opened this issue · comments
I am configuring the deployment of a java spring based project in Heroku. The naming convention of the properties in our existing project is "x.y.z". Ex: integration.postmark.url. Currently the plugin is throwing error: unable to parse the properties which has a "." in the name. I have cloned the repo and updated the regex to allow it (attached file). I have linked the plugin in local with updated code and it is working.
Is it possible to include the change in next version?
Hey there! . is not a valid character for bash variable names, so the plugin correctly refuses to parse that line.
I did some testing and heroku was able to set a.b and I could write a java program that printed it out.
That being said, even if it works, it makes the most sense to stick to the standards as far as config parsing goes. Is it possible to use integration_postmark_url instead? A little less java-looking, but since it's a string it shouldn't matter as far as functionality goes?
As Spring Tool Suite supports auto-filling of property names with "." convention and shows errors if the property is unavailable, if I change it to "_" I would be losing these features. Also some of the property names are defined by the spring library and can't be changed.
On a different note, do you have any plans to support yaml configuration?
To be clear, you're talking about variables read by System.getenv() from the environment, right? Just want to make sure we're on the same page. This has nothing to do with what exists in your properties file. Does echo $integration.postmark.url work in your terminal?
Also, no plans for yaml. This is meant to work with tools like dotenv and similar.
I am taking about the environment specific properties, not environment variables. Let me explain more on what I am trying to do:
I have DEV, QA, UAT environments for my project. There are few properties like integration urls, credentials, threadpool size etc. which are different for each environment. Currently these properties are added to slug and I am building the slug for each environment separately. I want to change that to creating one slug for dev and promoting to higher env using Heroku pipeline. For this I am planning to move the environment specific properties as config vars.
Although linux does not support setting . in environment variables, but I believe Heroku Config Vars does not seem to have that limit. I am thinking the alternative to adding these properties to config vars would be to add them in database or load them from an external location.
Hope this adds context and let me know your take on this.
Thanks for explaining, I think I follow.
I don't think changing the default behavior to something unsupported is a good move (I'd still like malformed lines to be flagged as such) but I can hide expanded functionality behind a -e flag. Then there could be a much wider range of accepted characters that have varying degrees of being supported. With that, you could run heroku config:push -e and it would work as you expect.
Would that fix your problem?
Default behaviour showing error on unsupported characters makes sense. Yes, -e flag accepting other characters will solve my problem.
sweet! I've released v1.4.0, which includes the -e flag. Your CLI should auto update. Let me know if there's anything else you need.