Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate support for checking Flyway locations #25488

Closed
MateuszSobala opened this issue Mar 3, 2021 · 3 comments
Closed

Deprecate support for checking Flyway locations #25488

MateuszSobala opened this issue Mar 3, 2021 · 3 comments
Labels
type: enhancement A general enhancement
Milestone

Comments

@MateuszSobala
Copy link

Spring Boot version 2.4.3 (could be any which supports Flyway 6.4)

With version 6.4 flyway introduced support for wildcards in scripts locations, see https://flywaydb.org/blog/organising-your-migrations. Unfortunately the Spring location checker is not consistent with the new flyway feature.

When defining locations with wildcards, eg. spring.flyway.locations=classpath:/db/release-?.?/migration/, spring.flyway.locations=classpath:/db/release-*/migration/, Spring checks whether this location exists. In this case it certainly doesn't.

As a workaround I can set spring.flyway.check-location=false but it took me some time to discover that the issue is indeed in Spring's additional path validation. Furthermore I'd like to check the location even when using wildcards.

Sample project: https://github.com/MateuszSobala/spring_flyway-location-wildcards
Code which needs to be adjusted:

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Mar 3, 2021
@mbhave
Copy link
Contributor

mbhave commented Mar 3, 2021

I agree that it would be good to support location checking even with wildcard locations. I wonder if that is an enhancement to the flyway support and something that should go in 2.5.x or if we should treat it as a bug that needs to be fixed in 2.3.x. Flagging for team attention to see if there are any downsides to adding this support and if not, whether this should be a bug or enhancement (combined with documentation in 2.3.x and 2.4.x).

@mbhave mbhave added the for: team-attention An issue we'd like other members of the team to review label Mar 3, 2021
@wilkinsona
Copy link
Member

wilkinsona commented Mar 4, 2021

I think we may now be creating more problems than we're solving by checking Flyway's locations. In addition to the wildcard support added in 6.4, 7.0 adds support for S3 and GCS (Google Cloud Storage). To check those accurately we'd need to use the respective SDKs which feels too much to me.

With hindsight, if failing is a desirable feature when using Flyway, I think it should be implemented in Flyway rather than Spring Boot.

With Flyway 7.5.3, the following is logged when check-locations is set to false and no migration scripts are found:

2021-03-04 09:22:54.603  INFO   --- [           main] o.f.c.internal.license.VersionPrinter    : Flyway Community Edition 7.5.3 by Redgate
2021-03-04 09:22:54.733 ERROR   --- [           main] o.f.c.i.s.classpath.ClassPathScanner     : Unable to resolve location classpath:db/migration2.
2021-03-04 09:22:54.862 ERROR   --- [           main] o.f.c.i.s.classpath.ClassPathScanner     : Unable to resolve location classpath:db/missing1.
2021-03-04 09:22:54.899  INFO   --- [           main] o.f.c.i.database.base.DatabaseType       : Database: jdbc:h2:mem:5c0aaac7-a396-422e-8d2a-c02ed08a4381 (H2 1.4)
2021-03-04 09:22:54.970  INFO   --- [           main] o.f.core.internal.command.DbValidate     : Successfully validated 0 migrations (execution time 00:00.015s)
2021-03-04 09:22:54.970  WARN   --- [           main] o.f.core.internal.command.DbValidate     : No migrations found. Are your locations set up correctly?

It's a similar story with 6.4 but with warning rather than error messages for the unresolvable locations:

2021-03-04 09:33:00.829  INFO   --- [           main] o.f.c.internal.license.VersionPrinter    : Flyway Community Edition 6.4.4 by Redgate
2021-03-04 09:33:00.993  WARN   --- [           main] o.f.c.i.s.classpath.ClassPathScanner     : Unable to resolve location classpath:db/migration2. Note this warning will become an error in Flyway 7.
2021-03-04 09:33:01.131  WARN   --- [           main] o.f.c.i.s.classpath.ClassPathScanner     : Unable to resolve location classpath:db/missing1. Note this warning will become an error in Flyway 7.
2021-03-04 09:33:01.151  INFO   --- [           main] o.f.c.internal.database.DatabaseFactory  : Database: jdbc:h2:mem:a2dc708e-60ac-46b2-8e1e-6cf9db6d14bb (H2 1.4)
2021-03-04 09:33:01.216  INFO   --- [           main] o.f.core.internal.command.DbValidate     : Successfully validated 0 migrations (execution time 00:00.016s)
2021-03-04 09:33:01.217  WARN   --- [           main] o.f.core.internal.command.DbValidate     : No migrations found. Are your locations set up correctly?

Flyway switched from warnings to errors in 7.0. Our location checking has been available since Flyway support was added. The default changed from false to true in 2.0.

@wilkinsona
Copy link
Member

We seem to be in agreement that checking Flyway's locations ourselves is no longer a good idea. Let's use this issue to deprecate the current support and document the known limitations.

@wilkinsona wilkinsona changed the title Flyway wildcard locations fail on location check Deprecate support for checking Flyway locations Mar 8, 2021
@wilkinsona wilkinsona added type: enhancement A general enhancement and removed for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged labels Mar 8, 2021
@wilkinsona wilkinsona added this to the 2.5.x milestone Mar 8, 2021
dreis2211 added a commit to dreis2211/spring-boot that referenced this issue Mar 9, 2021
@wilkinsona wilkinsona modified the milestones: 2.5.x, 2.5.0-M3 Mar 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

4 participants