I run my quarkus application using:
mvn compile quarkus:dev
I have flyway also integrated in my application. Every time my application live reloads due to some changes flyway also checks for any migration done on db. How can I disable it because it increases the live reload time.
application.yaml:
quarkus:
flyway:
migrate-at-start: false
baseline-on-migrate: true
There is a property available flyway.enabled.which is true by default. To disable flyway you need to make it false.
Solution :
quarkus:
flyway:
enabled: false
migrate-at-start: false
baseline-on-migrate: true
Related
I have a Spring boot application with different environments. I have a main application.yml with a set of properties and an application-test.yml for my test environment.
Inside my application.yml, I have the following config
spring:
liquibase:
enabled: false
user: ${SPRING_DATASOURCE_USERNAME}
password: ${SPRING_DATASOURCE_PASSWORD}
change-log: classpath:db/changelog-master.yaml
And inside my application-test.yml, I have the following
spring
liquibase:
user: sa
password: password
I was expecting my test environment to use liquibase.user and liquibase.password from the application-test.yml and pick the two other sub-properties (liquibase.enabled and liquibase.change-log) from application.yml. My reasoning was that in my test environment, the Application context would pick up all the properties in application.yml and then overwrite only the subkeys defined in application-test.yml, while keeping the original values of application.yml if not explicitly overwritten.
But that does not seem to be the case; it looks as if the key liquibase in my application-test.yml overwrites all the key and subkeys of the liquibase defined in application.yml.
Therefore since in my application-test.yml, liquibase.enabled and liquibase.change-log are not defined; the test environment does not know about these values. I was expecting them to be picked up from the main application.yml instead. I tried to define them manually in my application-test.yml and my tests work fine. If I remove them, my tests fail because they use the default properties for liquibase instead of liquibase.enabled: false and liquibase.change-log: classpath:db/changelog-master.yaml
What I would like to do is the following:
In my main application.yml, have
main_key:
sub_key_1: value_1
sub_key_2: value_2
sub_key_3: value_3
And in my application-test.yml, have only
main_key:
sub_key_1: test_value_1
have my test environment pickup sub_key_2: value_2 and sub_key_3: value_3 directly from application.yml, without them being overwritten by nothing in my test environment (since they are not defined in my application-test.yml)
Is it possible to have think kind of logic : if main_key.sub_key_2 is defined in application-test.yml is defined, then use it, otherwise use the main_key.sub_key_2 defined in application.yml ?
I feel that if I don't define all the sub_keys of my main_key in my application-test.yml, it is not possible to do it.
Many thanks for your help
Actually, I think I know why it does not work.
I had an empty application.yml inside my test/resources/application.yml. So I believe spring boot picks up the test/resources/application.yml instead of the src/main/resources/application.yml when test/resources/application.yml exists.
Which explains why the properties in my src/main/resources/application.yml were not picked up at all.
The solution was simply to delete the test/resources/application.yml
info:
app:
env-active: dev
spring:
profiles:
active: ${info.app.env-active}
In my case, I want to use placeholder for setting spring.profiles.active. in my springboot application (application.yml), but when I start the project, the log is showing like blow.
The following profiles are active: dev,${info.app.env-active}
The real property is truly resolved, but the placeholder is still exists. Is that an bugs?
I made a very silly mistake in my Spring Boot app's YAML config:
---
spring:
profiles: local
...
___
spring:
profiles: foo
...
---
spring:
profiles:
active: bar
include: foo
...
I accidentally tried to use "spring.profiles.active" to set the Spring profiles in the last section. Since this does not mean anything to Spring, the last section was always applied and the foo profile was always turned on.
spring.profiles.active is essentially nonsense, yet the app ran without complaint (until the problematic configuration caused other problems).
I would like to configure Spring somehow to immediately throw an exception when it encounters a config parameter that appears internal (spring...) but is unknown to it. How do I do this?
Whatever in iex> or using mix run -e "My.code" when I run the mix project using ecto, the Ecto's Debugging Mechanism display a bunch of SQLs like below
16:42:12.870 [debug] SELECT a0.`id` FROM `account` AS a0 WHERE (a0.`account_name` = ?) ["71000000313"] (39.6ms)`
...
When I dont need the debug output anymore, How can I turn it off, I cannot find anything about how to change ecto log level stuff.
Thanks in advance.
If you want to change the Ecto (pre 2.0) log level (and only it) then you can use the log_level configuration option that can be set in your applications Ecto repository configuration.
In example:
config :my_app, MyApp.Repo,
adapter: Ecto.Adapters.Postgres,
database: "my_app",
username: "my_app",
password: "secret",
hostname: "localhost",
port: 5433,
log_level: :info
Of course beside the above you can always change the Logger configuration log level option if you want to change the overall log level (not only the Ecto log level) e.g.:
config :logger, level: :info
Update (by #Milos):
Since Ecto 2.0.0, instead of log_level: :info you need to use loggers: [{Ecto.LogEntry, :log, [:info]}].
Update (by #AndyMacKinlay):
Since Ecto 3.0.0, instead of log_level: :info you need to use log: :info.
Update (by #Simon):
Since Ecto 3.0.0, you can also completely disable logging log: false.
Your logging level is configured in your config/#{env}.exs files. If you look into config/prod.exs it most likely already has that level set to :info:
config :logger, level: :info
So if you run the app with MIX_ENV=prod iex -S mix you won't get the debug output. This means that when you build a release with something like MIX_ENV=prod mix release the resulting build won't be producing this output. Alternatively you may set level: :info or :warn for whatever environment you want by changing the appropriate config/#{env}.exs.
Ecto 3 answer to completely disabling logging would be:
config :app, App.Repo,
username: "postgres",
password: "postgres",
database: "app_dev",
log: false
To disable debug messages temporarily you can do Logger.configure(level: :warn) and then re-enable with Logger.configure(level: :debug).
https://hexdocs.pm/logger/Logger.html#Levels
Simple put loggers: [] in
config :my_app, MyApp.Repo,
adapter: Ecto.Adapters.Postgres,
database: "my_app_repo",
username: "DB_USERNAME",
password: "DB_PASSWORD",
hostname: "DB_HOST",
loggers: []
I am trying to run some acceptance tests in my Laravel application. While functional tests trigger testing environment, acceptance tests do not. Is it a bug or a feature of acceptance tests? The main problem why this is bothering me is the fact, that it is not using(+populating+cleanup) testing database, it only connects to dev database (which is used, when no other ENV is specified e.g. testing, production) and this often fails those tests when I run them multiple times.
This is my configuration:
codeception.yml
paths:
tests: app/tests
log: app/tests/_log
data: app/tests/_data
helpers: app/tests/_helpers
settings:
bootstrap: _bootstrap.php
suite_class: \PHPUnit_Framework_TestSuite
colors: true
memory_limit: 1024M
log: true
modules:
config:
Db:
dsn: 'mysql:host=localhost;dbname=testdb'
user: 'root'
password: 'root'
dump: 'app/tests/_data/dump.sql'
populate: true
cleanup: true
acceptance.suite.yml
class_name: WebGuy
modules:
enabled:
- PhpBrowser
- WebHelper
- Db
config:
PhpBrowser:
url: 'http://localhost/'
functional.suite.yml
class_name: TestGuy
modules:
enabled: [Filesystem, TestHelper, Laravel4, Db]
Thanks for your help!
"Acceptance" tests are not run in the testing environment. The reason is when Laravel is in the testing environment, it disables filters by default. So therefore the testing environment is only for unit and functional tests.
Acceptance tests should be run in another environment (like dev or a specific one to Codeception).
Because Codeception 2.x now uses Guzzle to get a page response, it is possible to detect when you are on your host machine and Codeception is doing a specific request. That way you can have a "testing" environment and also a "codeception" environment specifically for your acceptance tests.
If you are using Homestead, I do this in my start.php file to detect if Codeception is running, and specifically put it into a 'codeception' environment, otherwise I let it run my environment detection normally
if ((gethostname() === 'homestead') && (isset($_SERVER['REMOTE_ADDR'])) && ($_SERVER['REMOTE_ADDR'] === '127.0.0.1'))
{
$env = $app->detectEnvironment(['codeception' => ['homestead']]);
}
else
{
$env = $app->detectEnvironment(['dev' => ['homestead']]);
}
Then in my 'codeception' environment, I setup a SQLite file database, and run acceptance tests against that (which is faster than mySQL testing).
First, you must understand that Codeception acceptance tests do not run inside the Laravel testing environment. Rather, it uses Guzzle to make external HTTP requests. Assuming your acceptance tests run against localhost, you are running in your standard development environment. It is just like using your browser.
That said, here is how I use Codeception Acceptance tests to run against a Laravel testing environment. I run Vagrant with a LAMP stack on Ubuntu.
Edit your /etc/hosts file. Add test.localhost to the 127.0.0.1 line. Do not remove the other hosts there. If you use WAMP/MAMP/or other, it might be a similar setup.
/etc/hosts
127.0.0.1 localhost test.localhost
Setup your environment handling with Laravel. Below is code in the bootstrap/start.php file in your larval root dir. pay attention to the 'testing' line.
bootstrap/start.php
$env = $app->detectEnvironment(array(
'local' => array('your-machine-name'),
'testing' => array('test.localhost')
));
Make sure your codeception acceptance test is configured to hit the right domain/url. The code below is from my own acceptance tests for an API. Notice the url: sections have test.localhost. That is the url that Codeception will hit for the tests.
app/tests/acceptance.suite.yml
class_name: ApiGuy
modules:
enabled: [PhpBrowser, REST, ApiHelper, Db, FileSystem]
config:
PhpBrowser:
url: http://test.localhost/
REST:
url: http://test.localhost/api/v1/
Putting it all together
We edited the /etc/hosts file so that Codeception can find test.localhost. Editing your web server config to handle test.localhost is outside the scope of this answer.
We edited Laravel's bootstrap/start.php so that it knows that any requests coming into test.localhost should run in the testing environment.
We edited Codeception's acceptance.suite.yml file to tell it to run all tests against http://test.localhost
Now, assuming the above is done correctly, you should be able to run codeception run acceptance and see the output of your tests.