Environment profiles, builds and version control and builds

[amr]

I hope I didn't overlook the obvious. But here goes...

Currently, jhipster promotes that all settings exist in a config file under resources and by default those are tracked in git. Some of the settings in a given application-*.yml files are machine specific, and others are specific to the type of environment (i.e. production, development, etc).

I think that the workflow that jhipster should promote (or at least support) is that machine specific settings should live in a file that:

1. Doesn't get committed to version control
2. Doesn't get bundled with any build

It's simply a file on the machine with its specific settings such as database connection parameters. Therefore, my project's README.md file would have a setup instruction that looks like: "Copy the bundled local.yml-sample as local.yml and modify its settings accordingly to match your environment". Well, you get the idea.

[jdubois]

I understand what you mean, and this is indeed an issue.
In my mind (but this is not written in the documentation!), my idea was that:

• You get the "basic" configuration in your .yml file
• You use environnement variables to override them in production/test/...

[amr]

IMHO while in the age of SaaS and PaaS, environment variables are the most technically correct, I believe they are only ever convenient in large scale deployments. For 95% of the cases, they are needlessly inconvenient to setup and manage. In jhipster, environment variables are already supported for those who need that. If you think the solution I proposed might make sense for jhipster to support by default, I'd be willing to work on a PR (wouldn't be sure to work on 1.x or master though)

[jdubois]

Note that I never used it myself, but you can also easily externalize your configuration:
http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
This is all done by Spring Boot, this is not specific to JHipster

[amr]

That's interesting, because according to the docs, an application.yml file placed in the current working directory will be loaded and will have higher precedence that files in src/main/resources/config/. When I tried that with jhipster now, the file was loaded but it had lower precedence than the files in src/main/resources/config/. I thought that's a bug in spring-boot, so I created a separate spring-boot project (using http://start.spring.io) and tried reproducing, but it actually worked as expected.

Not sure if that's only in my setup.

[mpages]

you can easly externalise conf with jvm params like : -Dspring.config.location=/data/prog/application-XXX-env.yml

[amr]

If I understand correctly that would not load the bundled configurations in src/main/resources/config/..

[jmirc]

The bundled configurations will be loaded but they will be overridden by the external properties file.

Here is the documentation from spring-boot (http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-application-property-files)

If spring.config.location contains directories (as opposed to files) they should end in /
(and will be appended with the names generated from spring.config.name before being loaded). 
The default search path classpath:,classpath:/config,file:,file:config/ is always used, irrespective of the 
value of spring.config.location. In that way you can set up default values for your application in 
application.properties (or whatever other basename you choose with spring.config.name) 
and override it at runtime with a different file, keeping the defaults.

[amr]

Thanks for the correction. I'm unable to get that working with jhipster although it works fine with a vanilla spring boot project in the manner you described.

The behavior I'm seeing is that the externalized config is loaded, but any value defined in the bundled configs take precedence.

[jdubois]

@amr so I understand this would be OK for you, if you didn't have that issue -> keep us updated if you have this working or not, I'll close this ticket and if you still have this issue can you create another ticket (because it's another problem)?

[amr]

You are right